Ошибка в вычислениях адресов у GCC ?

Hello Yuriy.

AB>> Итого предлагается написать make на bat'е? YK> Предлагается объяснить преимущества make перед bat. YK> Одно есть: ускорение сборки больших проектов. YK> Приведи еще одно.

При использовании make не нужно писать его функциональность на bat-файлах.

AB>> ps: Возьмите вместо bat, какой-нить bash или tcsh. Или WSH AB>> (Windows Scripting Host) YK> Зачем?

Hу, на них писать удобнее, чем на bat.

Alexey

Mon Feb 07 2005 19:42, Ilya Anfimov wrote to Yuriy K:

IA> Удобный синтаксис для преобразований IA> файлов по расширениям.

Удобный? 8-0 Оно конечно, на вкус и на цвет... Мне цикл for гораздо понятней.

WBR, Yuriy.

SP> В этом заслуга rar'а, а стандартная команда "cd" это не поймет (под SP> W98). Даже не rar-а. Специально только что перегрузился в 98-ю и проверил.

// foo.c #include <stdio.h>

int main(int ac, char **av) { FILE *fp; if(ac < 3) return 1; fp = fopen(av[1], "wt"); if( !fp) { puts("A-a-a!"); return 1; } fprintf( fp, "%s", av[2]); fclose(fp); return 0; }

c:\>foo c:/temp/foo.txt Kwa!

Прекрасно создало файл foo.txt в каталоге c:/temp и записало в него что просили.

Многое виндовое встроенное просто по прямому слешу ключ ждёт, вот и не берёт его в именах файлов.

WBR,

SP> Да:

SP> - легко организуется компиляция "тонких мест" - могу в одной строке SP> записать что один из 102 файлов компилить с отличными от default SP> ключиками.(не важно где он лежит, и какой build выполняется) И что тоже можно сделать в батнике, если уж упираться в вопрос "а что такого моежт make, что не может bat". Но только задавая правила, а не действия - на мой взгляд это сделать проще.

Wbr,

MP>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>> А зачем??? MP> Элементарно - для поддержки проекта. Тьху ты, это я глюкнул. Имелось ввиду зачем для этого (разбора/поддержки) держать всё в одном файле?.

MP> Все без проблем находится в одном MP> исходнике размером меньше в 4 раза чем было и понятнее в 5 раз. Ну а я хочу сказать, что всё без проблем находится и в толпе исходников, только раньше нужно было какие-то телодвижения сделать (прикрутить к Qedit несколько макросов на горячие клавиши и grep вытащить в доступное по path место), а сейчас любой минимально-приличный программистский редактор это сам умеет.

OR>> И ещё был макрос, который хватал слово под курсором и открывл файл с OR>> таким именем - это уже для хождения по выдаче grep. MP> А я тогда искал входы в процедуры через ctrl+f в том-же qedit в исходнике MP> максимум из 3 файлов и не знал про существование таких заморочек ;) Кстати, вот как раз *тогда* make экономил время пересборки даже на мелких проектах во много раз. Особенно на дискетах :-)

OR>> Так что поиск - не аргумент, и я не пойму, зачем держать всё в одном OR>> мегабайтном файле? MP> Hе знаю - привычно как-то. А мне привычно через make. И даже если сейчас время build all занимает несколько секунд, а время make - одну - мне гораздо проще и привычнее задавать правила функционирования, чем конкретные действия.

MP> Я всю осмысленную инфо держу всегда в одном файле, И тут так - или считать, что в новый проект тащить что-то из старого (aka выделять общие между несколькими проектами куски в отдельные файлы) - это плохо и неправильно, или начинать новый проект с копирования старых исходников в отдельный каталог и кромсания их.

OR>> зависит. Если foo.obj свежее всех, то ничего не делаем. Иначе OR>> перекомпилируем его. OR>> И так 190 раз, но только для 10 файлов будет вызвана перекомпиляция. MP> Я почему-то не уверен что все это радикально ускорит работу. Сборку небольшого проекта (у меня сейчас все такие)? Ускорит радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 секунд до 2 - заметно? Да не очень.

MP> Среднепаршивый проект собирается весь за секунды, а на изучение синтаксиса MP> make MP> для создания правильных файлов в целом можно не один день жизни потратить. MP> Выгода сомнительна. Лучше купить лишний жирный процессор винт побыстрее MP> и памяти побольше ;) С одной стороны да. Скажем, по этой причине я когда-то обломился прикручивать make к pcad4.5 :-) Но факт - тогда для многолистовой схемы с изменением на одном листе через make изменения в плату вбрасывались в разы быстрее, чем через сгенерённый PCECO батник. А с другой - почему-то если зашивка процессора сокращается с 10 секунд до

wbr,

Hello, Yuriy! You wrote to Sergey Pinigin on Mon, 07 Feb 2005 19:21:17 +0300:

SP>> - легко организуется компиляция "тонких мест" - могу в одной SP>> строке записать что один из 102 файлов компилить с отличными от SP>> default ключиками.(не важно где он лежит, и какой build SP>> выполняется)

YK> Зачем этот файл надо компилить с другими настройками?

А вот именно его надо. Например, низ-зя, ни при какой погоде, включать оптимизацию. И только для него.

P.S. Если отвлечься от bat как от эмэсовского расширения и взять более другие командные процессоры (sh, 4dos, etc.), то на них действительно можно реализовать всю функциональность мейка, и его наличие в готовом виде останется единственным преимуществом, но каким!! :-)))

With best regards, Alexander Derazhne

AM>>> Hо имхо, если человек умеет пользоваться маке-ом, то и при сборке AM>>> проектов, где build all займет 2 секунды он также будет пользоваться AM>>> маке-ом а не батом, Я скорее такой. Для сложной работы всё равно make, так чего ещё батники заводить?

DO>> А вот не факт. Я в зависимости от ситуации и настроения пользуюсь и make и DO>> bat и ide.

SP> Ты будешь первым, таким разносторонним (или неустойчивым в выборе)... SP> ;-)

SP> Hачнем считать. Но справедливости ради хочу сказать, что в Altera MAX+II я работаю то по-разному в зависимости от того, что делаю.

Любое сложное (сложнее исправления нескольких строк) редактирование, любая работа без симуляции (отредактировал/зашил/полез с осциллографом) либо наоборот - с длинной симуляцией, когда всё равно долго свёрнутым болтаться будет - это MED+make+maxplus2.exe+jam-palyer+свой загрузчик flex по RS232 через набортный процессор устройства.

Всё остальное - max2win.exe

wbr,

Hello, Oleksandr!

Пон Фев 07 2005, Oleksandr Redchuk писал к Maxim Polyanskiy по поводу "Re: Ошибка в вычислениях адресов у GCC ?." MP>>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>>> А зачем??? MP>> Элементарно - для поддержки проекта. OR> Тьху ты, это я глюкнул. OR> Имелось ввиду зачем для этого (разбора/поддержки) держать всё в одном OR> файле?. Да это банально удобно. При том-же поиске ты сразу c одного нажатия видишь искомое в контексте программы, а не список из файлов где оно есть. OR> Hу а я хочу сказать, что всё без проблем находится и в толпе OR> исходников, Видно что есть, но не видно, что вокруг, а это сильно ускоряет работу. Предположим некая процедура передает неправильные параметры - чтоб найти откуда она с ними вызывается придется облазить все найденные файлы, куча лишних нажатий на кнопки, время. OR> только раньше нужно было какие-то телодвижения сделать OR> (прикрутить к Qedit несколько макросов на горячие клавиши и grep OR> вытащить в доступное по path место), а сейчас любой OR> минимально-приличный программистский редактор это сам умеет. OR> Кстати, вот как раз *тогда* make экономил время пересборки даже на OR> мелких проектах во много раз. Особенно на дискетах :-) Собираю тут фигню в C18, через make она собирается за 6 сек через build all за

1. Линкер работает чуть-ли не тормознее компиллера. В асме то-же собрается за 1 сек, нафиг make ;). MP>> Я всю осмысленную инфо держу всегда в одном файле, OR> И тут так - или считать, что в новый проект тащить что-то из старого OR> (aka выделять общие между несколькими проектами куски в отдельные OR> файлы) - это плохо и неправильно, или начинать новый проект с OR> копирования старых исходников в отдельный каталог и кромсания их. Hужные куски выдираются из старого по copy-paste. _HУЖHЫЕ КУСКИ_ а не сборище хламовых библиотек и помойки в хидерах от старого проекта скопиронного по F5 в новую дир. MP>> Я почему-то не уверен что все это радикально ускорит работу. OR> Сборку небольшого проекта (у меня сейчас все такие)? Ускорит OR> радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 OR> секунд до 2 - заметно? Да не очень. Да с 8 до 6 у меня выходит в проекте из 7 файлов. Hу с большим натягом на одном файле с 8 до 5. Даже не в 2 раза короче. OR> С одной стороны да. Скажем, по этой причине я когда-то обломился OR> прикручивать make к pcad4.5 :-) Hо факт - тогда для многолистовой OR> схемы с изменением на одном листе через make изменения в плату OR> вбрасывались в разы быстрее, чем через сгенерённый PCECO батник. А с OR> другой - почему-то если зашивка процессора сокращается с 10 секунд до OR> 5, то народ радуется, а вот растянуть сборку с 5 до 10 - так вроде бы OR> и нормально. Главное чтоб зашивка автоматом происходила после успешной сборки. Потом ты шил скажем 400 процессоров за присест? Мне приходилось... Там каждая лишняя секунда

- увеличение времени на задачу. OR> /* Oleksandr Redchuk, Brovary, Ukraine */ WBR! Maxim Polyanskiy.

Tue, 08 Feb 2005 09:14:50 +0300 Sergey Pinigin wrote to Harry Zhurov:

SP> А теперь спокойно опишу тот случай, когда мне неудобны включения SP> ненужных файлов.

SP> 1. Рабочая копия проекта содержит _только_ необходимые для его сборки SP> файлы: SP> - файлы самого проекта SP> - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)

SP> 2. Во внешнем файле имеется "закрытая" дефайном ссылка на файл, SP> который не может быть использована в текущем проекте - файла нет в SP> рабочей копии проекта.

SP> Выполеняем make: SP> - вариан1: построение зависимостей выполнится _с учетом_ #ifdef - "all SP> ok"- вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет SP> правила для создания того файла который не нужен..."

Это понято. С этим не спорю. Есть такое ограничение, что любой файл, указанный в #include, должен существовать, иначе make выдаст ошибку.

SP> Снова понятно что можно не пользоваться условными включениями, но SP> иногда без этого обойтись трудно. Да и зачем себя ограничивать если SP> вопрос легко решается?

Хм, насколько легко? Я немного сталкивался как раз с этими вопросами, даже начал писать поддержку дефайнов (а также были попытки использовать сторонние компиляторы для генерации автозависимостей). Но уперся в одно фундаментальное ограничение: как объяснили батоны, единственный стопроцентно корректный путь для генерации автозависимостей - это использовать родной компилятор для оной цели, т.к. только он "знает" все дефайны. Ведь он может внутри себя определять еще энное количество дефайнов. Например, в заголовке от IAR'овского пакета есть такое:

#if !(__IAR_SYSTEMS_ICC__) && !defined(__IAR_SYSTEMS_ASM__) #error This file should only be compiled with iccavr,icca90 or aavr. #endif /* !(__IAR_SYSTEMS_ICC__ > 2) && !defined __IAR_SYSTEMS_ASM__ */

где __IAR_SYSTEMS_ICC__ и __IAR_SYSTEMS_ASM__ - макросы, определенные компилятором и ассемблером означенного пакета. Когда я пытаюсь, например, использовать GCC с ключиком -MM, чтобы сгенерить автозависимости, то получаю (и совершенно справедливо) ошибку.

Можно, конечно, все эти переменные самому руками указать, но это уже кривизна. И нет гарантии, что в следующей версии пакета все это не поменяется.

Поэтому тут, имхо, два пути.

Первый: использовать родной компилятор - наиболее корректный, но почти не портабельный и не позволяющий, как правило, обрабатывать не свои файлы - ассемблерные, например.

Второй: использовать стороннюю утилиту - приводит к некоторым ограничениям (к необходимости держать все файлы, указанные в инклюдах, в одном случае; к необходимости так или иначе определить требуемые макросы, в другом; возможно, есть и еще что-то, навскидку пока не вижу ).

Что для себя выбрать, каждый решает сам. Я выбрал стороннюю утилиту без заморачивания на макросах, необходимость иметь все файлы неудобств не доставляет. Из достоинств:

main.r43 main.d : D:\Pro\TV\LTPM\430\Src\main.cpp \ D:\CAD\IAR\IDE400\430\inc\dlib\DLib_Defaults.h \ D:\CAD\IAR\IDE400\430\inc\dlib\DLib_Product.h \ ... \ D:\CAD\IAR\IDE400\430\inc\dlib\yvals.h \

т.е. не надо вызывать никакие sed'ы для обработки вывода тулзы автогенерации.

Если есть еще какие-то достойные внимания пути решения этой проблемы, с интересом выслушаю.

Hello Maxim.

MP>>>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>>>> А зачем??? MP>>> Элементарно - для поддержки проекта.

OR>> Тьху ты, это я глюкнул. OR>> Имелось ввиду зачем для этого (разбора/поддержки) держать всё в OR>> одном файле?.

MP> Да это банально удобно. При том-же поиске ты сразу c одного нажатия MP> видишь искомое в контексте программы, а не список из файлов где оно MP> есть.

Редактоp выбеpи адекватный. У меня ctrl-Shift-Enter - выводит список фyнкций, define, typedef в текyщем файле, если надо, можно нажать галочкy project и полyчить список по пpоектy. Hо pеально по пpоектy этим pедко пользyюсь, потомy что: Ctrl-Enter на любом опpеделенном имени (бyдь то фyнкция, define, typedef) вызывает пеpемещение в место объявления, Alt-Enter - назад. Все дейстyет по пpинципy стека, то есть можешь yскакать сколь yгодно далеко по опpеделениям, а потом веpнyться назад. Пpи ноpмальной оpганизации пpоекта (а не когда все пеpеменные только глобальные) pеальная необходимость найти что-то во всех файлах пpоекта возникает, но не так часто. Скоpее всего это что-то вpоде "посмотpеть, откyда вызывается вот эта фyнкция". В этом слyчае я yже вижy имена модyлей, где есть вызов, и мне зачастyю не особо нyжно даже откpывать этот файл.

OR>> Hу а я хочу сказать, что всё без проблем находится и в толпе OR>> исходников, MP> Видно что есть, но не видно, что вокруг, а это сильно ускоряет работу.

Вокpyг, как пpавило, видно только в пpеделах 20-40 стpок, котоpые одновpеменно yмещаются на экpане. Остальной поиск делается гоpячими кнопками, и его вpемя пpактически не зависит от того, в этом же файле находится искомый фpагмент или в дpyгом.

MP> Предположим некая процедура передает неправильные параметры - чтоб MP> найти откуда она с ними вызывается

Если пpоцедypа паpаметpы пеpедает, то она не может с ними вызываться. И если ты имеешь ввидy, что вот этy пpоцедypy кто-то вызывает с непpавильными паpаметpами, то дpyгого способа пpовеpить нет, как найти по файлy(файлам) места ее вызова, тогда возможно бyдет быстpее и пpойтись только по одномy файлy поиском слова Ctrl-F, а возможно бyдет быстpее вывести в отдельное окно список найденных стpок с именем этой пpоцедypы, и пpи наличии адекватных имен пеpеменных бyдет сpазy видно, где и что напyтано. Только не надо мне говоpить, что тебе нyжно посмотpеть еще 10 стpок выше, чтобы опpеделить что там пеpедается.

MP> придется облазить все найденные файлы, куча MP> лишних нажатий на кнопки, время.

А если ты стоишь на вызове пpоцедypы и хочешь пpовеpить, а пpавлитьно ли ты yказал паpаметpы, то: В med одно нажатие гоpячими клавишами и ты в месте опpеделения фyнкции. В SlickEdit вообще по имени пpоцедypы дополнительно всплывает подсказка с паpаметpами. Hикyда ходить не надо.

OR>> отдельные файлы) - это плохо и неправильно, или начинать новый OR>> проект с копирования старых исходников в отдельный каталог и OR>> кромсания их. MP> Hужные куски выдираются из старого по copy-paste. _HУЖHЫЕ КУСКИ_ а не MP> сборище хламовых библиотек и помойки в хидерах от старого проекта MP> скопиронного по F5 в новую дир.

И потом pазные кyски из pазных пpоектов долго синхpонизиpyются pyками.

OR>> радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 OR>> секунд до 2 - заметно? Да не очень. MP> Да с 8 до 6 у меня выходит в проекте из 7 файлов. Hу с большим натягом на MP> одном файле с 8 до 5. Даже не в 2 раза короче.

Сбоpка пpоекта для mb90, pазмеp bin ~100K - навскидкy 50 секyнд. Hапpягает.

С уважением, Andy <mailto:andy coбaкa svrw.ru>

Здравствуйте.

SP> 1. Рабочая копия проекта содержит _только_ необходимые для его SP> сборки SP> файлы: SP> - файлы самого проекта SP> - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)

SP> 2. Во внешнем файле имеется "закрытая" дефайном ссылка на файл, SP> который не может быть использована в текущем проекте - файла нет в SP> рабочей копии проекта.

SP> Выполеняем make: SP> - вариан1: построение зависимостей выполнится _с_учетом_ #ifdef - SP> "all ok" SP> - вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет SP> правила для создания того файла который не нужен..."

SP> Снова понятно что можно не пользоваться условными включениями, но SP> иногда без этого обойтись трудно. Да и зачем себя ограничивать если SP> вопрос легко решается?

А в случае, если ты вдруг "откроешь" ссылку на файл, который вдруг появился в проекте, то ты рискуешь поиметь проблемы, не заметив модификаций в этом заголовке. Предлагаешь каждый раз пересобирать зависимости ?

Это точно, перепутал (дошло еше вчера по дороге домой...), а удержаться не хватило сил, извини.

А теперь спокойно опишу тот случай, когда мне неудобны включения ненужных файлов.

1. Рабочая копия проекта содержит _только_ необходимые для его сборки файлы: - файлы самого проекта - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)
2. Во внешнем файле имеется "закрытая" дефайном ссылка на файл, который не может быть использована в текущем проекте - файла нет в рабочей копии проекта.

Выполеняем make: - вариан1: построение зависимостей выполнится _с_учетом_ #ifdef - "all ok" - вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет правила для создания того файла который не нужен..."

Снова понятно что можно не пользоваться условными включениями, но иногда без этого обойтись трудно. Да и зачем себя ограничивать если вопрос легко решается?

_______ Сергей.

Hello Anton.

AA>>> á ×ÏÔ ÐÏÄÓËÁÖÉ ÍÎÅ ÐÏ ÔÁËÏÍÕ ×ÏÐpÏÓÕ. õÍÅÅÔ ÌÉ ÏÎ ÓÁÍ ÄÅÌÁÔØ AA>>> ÔÁÂÌÉÃÙ ×ÅËÔÏpÏ× ÐpÅpÙ×ÁÎÉÊ? ÷Ï ×ÓÅÈ ÐpÉÍÅpÁÈ, ËÏÔÏpÙÅ Ñ ×ÉÄÅÌ, AA>>> ÜÔÏ ÄÅÌÁÌÏÓØ ×pÕÞÎÕÀ × ÁÓÓÅÍÂÌÅpÎÏÍ ÆÁÊÌÅ. éÍÈÏ ËÁË-ÔÏ AA>>> ÎÅÜÓÔÅÔÉÞÎÏ. :) AM>> ïÂÙÞÎÏ ÔÁË É ÅÓÔØ, × ÓÔÁÒÔÁÐ.ÁÓÍ ÏÂßÑ×ÌÑÅÔÓÑ ÓÅËÃÉÑ, × ËÏÔÏÒÏÊ É AM>> ÒÁÚÍÅÝÁÀÔÓÑ ×ÅËÔÏÒÁ, ÐÏÔÏÍ ÜÔÁ ÓÅËÃÉÑ ÌÉÎËÕÅÔÑ ÐÏ ÎÕÖÎÏÍ ÁÄÒÅÓÕ. ÷ AM>> ÐÒÉÎÃÉÐÅ ÍÅÎÑ ÜÔÏ ÎÅ ÓÍÕÝÁÅÔ. ôÁËÏÊ ÐÏÄÈÏÄ ÉÓÐÏÌØÚÕÅÔÓÑ ÏÞÅÎØ ÞÁÓÔÏ. AA> öÁÌØ, Ñ ÎÁÄÅÑÌÓÑ, ×ÓÅ ÎÅ ÔÁË ÕÂÏÇÏ. :(

HÅ ÓÞÉÔÁÀ ÜÔÏ yÂÏÇÉÍ, ÔÅÍ ÂÏÌÅÅ ÞÔÏ ÔÏÞËÁ ×ÈÏÄÁ ÄÌÑ IRQ ÏÄÎÁ, ÏÓÏÂÏ ÐpÁ×ÉÔØ ÜÔÏÔ ÓÔpÁÔÁÐ ÓÍÙÓÌÁ ÎÅÔ, ÎyÖÎÏ ÔÏÌØËÏ ÏÄÉÎ pÁÚ yÓÔÁÎÏ×ÉÔØ ×ÅËÔÏp.

AA> ëÓÔÁÔÉ, × ÅÇÏ tutor'Å ÅÓÔØ ÐpÉÍÅp ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÐpÅpÙ×ÁÎÉÊ, ÔÁÍ ÅÓÔØ AA> ÚÁÂÁ×ÎÁÑ ÆÕÎËÃÉÑ ÕÓÔÁÎÏ×ËÉ ÏÂpÁÂÏÔÞÉËÁ ÐpÅpÙ×ÁÎÉÑ. ôÙ ÓÌÕÞÁÊÎÏ ÎÅ × AA> ËÕpÓÅ, ËÕÄÁ É ËÁË ÏÎÁ ÅÇÏ ÕÓÔÁÎÏ×ÌÉ×ÁÅÔ? AA> :)

AA>>> é ÞÔÏ ÄÅÌÁÅÔ "pragma vector="? AM>> ÷ÏÚÍÏÖÎÏ ÜÔÏ ÁÌØÔÅÒÎÁÔÉ×ÎÙÊ ÓÐÏÓÏ ÏÂßÑ×ÉÔØ ×ÅËÔÏÒÙ ÐÒÅÒÙ×ÁÎÉÑ × AM>> ÓÅÇÍÅÎÔ intvec. HÏ ÎÁ ÄÁÎÎÙÊ ÍÏÍÅÎÔ Ñ ÅÝÅ ÄÏ ÜÔÏÇÏ ÎÅ ÄÏÂÒÁÌÓÑ. ëÒÏÍÅ AA> ñ ÐpÏÂÏ×ÁÌ, ÎÉÞÅÇÏ ÎÅ ÍÅÎÑÅÔÓÑ, ×ÏÔ É ÓÐpÏÓÉÌ, ËÁË ÜÔÕ ÐpÁÇÍÕ AA> ÉÓÐÏÌØÚÏ×ÁÔØ.

AM>> ÔÏÇÏ Õ lpc2xxx c ËÏÔÏÒÙÍÉ Ñ ÓÅÊÞÁÓ É ÐÒÏÂÕÀ arm ÐÏ ÒÅÚÅÒ×ÎÏÍÕ AM>> ×ÅËÔÏÒÕ ÌÅÖÉÔ ÄÏÐÏÌÎÅÎÉÅ ÄÏ 0 ËÏÎÔÒÏÌØÎÏÊ ÓÕÍÍÙ ×ÓÅÈ ×ÅËÔÏÒÏ× AM>> ÐÒÅÒÙ×ÁÎÉÊ. üÔÏ ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÏÐÒÅÄÅÌÅÎÉÑ ×ÁÌÉÄÎÏÓÔÉ ÀÚÅÒÏ×ÓËÏÊ AM>> ÐÒÏÇÒÁÍÍÙ ×Ï ÆÌÜÛ ×ÓÔÒÏÅÎÎÙÍ ÂÕÔÌÏÁÄÅÒÏÍ. HÁ ÁÓÓÅÍÂÌÅÒÅ ÔÕÄÁ ÍÏÖÎÏ AM>> ÐÒÏÓÔÏ ÚÁÐÉÈÁÔØ ÆÉËÓÉÒÏ×ÁÎÎÏÅ ÚÎÁÞÅÎÉÅ, ÚÁÒÁÎÅÅ ×ÙÞÉÓÌÅÎÎÏÅ. AA> ûÕÔÉÛØ?

HÉÓËÏÌØËÏ

AA> ÷ ÔÁÂÌÉÃÅ ÐpÅpÙ×ÁÎÉÊ ÌÅÖÁÔ ÐÅpÅÈÏÄÙ ÎÁ ÁÄpÅÓÁ ÏÂpÁÂÏÔÞÉËÏ× AA> ÐpÅpÙ×ÁÎÉÊ. ëÁË ÍÏÖÎÏ ÚÁpÁÎÅÅ ×ÙÞÉÓÌÉÔØ ÉÈ ÓÕÍÍÕ, ÅÓÌÉ ÄÏ ÌÉÎËÏ×ËÉ AA> ÎÅÉÚ×ÅÓÔÎÙ ÁÄpÅÓÁ ÏÂpÁÂÏÔÞÉËÏ×?

CODE32 ; Always ARM mode after reset org 0x00 reset ldr pc, do_reset_addr org 0x04 undef_handler ldr pc, do_undefined_instruction_addr org 0x08 swi_handler ldr pc, do_software_interrupt_addr org 0x0c prefetch_handler ldr pc, do_prefetch_abort_addr org 0x10 data_handler ldr pc, do_data_abort_addr org 0x14 rsv_handler DC32 0xB8A06F58 ;// ARM-reserved vector org 0x18 irq_handler ldr pc, do_irq_addr org 0x1c fiq_handler ldr pc, do_fiq_addr

; Constant table entries (for ldr pc) will be placed at 0x20 org 0x20 do_reset_addr: DC32 ?cstartup do_undefined_instruction_addr: DC32 undef_handler do_software_interrupt_addr: DC32 swi_handler do_prefetch_abort_addr: DC32 prefetch_handler do_data_abort_addr: DC32 data_handler DC32 0x00 do_irq_addr: DC32 OS_CPU_IRQ_ISR do_fiq_addr: DC32 OS_CPU_FIQ_ISR

AA> ñ ×ÏÔ ÎÉÞÅÇÏ ÎÅ ×ÙÞÉÓÌÑÀ, ÔÁÂÌÉÃÁ ×ÅËÔÏpÏ× AA> × ÁÓÓÅÍÂÌÅpÎÏÍ ÍÏÄÕÌÅ, É ËÏÎÔpÏÌØÎÁÑ ÓÕÍÍÁ ÓÏ×ÐÁÄÁÅÔ. ÷ÉÄÉÍÏ ÌÉÎËÅp AA> ×ÙÓÞÉÔÙ×ÁÅÔ.

HÅÔ, ÜÔÏ ÄÅÌÁÅÔ ×ÓÔpÏÅÎÎÙÊ ÂyÔ-ÌÏÁÄÅp, ÎÁÓËÏÌØËÏ Ñ ÐÏÎÉÍÁÀ. ìÉÎËÅp y éáò ×ÏÏÂÝÅ yÎÉ×ÅpÓÁÌØÎÙÊ É ÅÍy ÄÅÌÁ ÎÅÔ ÄÏ ÔÏÇÏ, ÞÔÏÂÙ ÅÝÅ ÎÅÚÁÍÅÔÎÏ ÄÌÑ ×ÓÅÈ ÓÞÉÔÁÔØ ëó É ÐÉÓÁÔØ ÅÅ ÐÏ ÁÄpÅÓy × ÐÁÍÑÔÉ. ðÏÓÅÍy, ÅÓÌÉ ÔÙ ÎÁÐpÉÍÅp ÚÁÈÏÞÅÛØ ÐpÏ×ÅpÑÔØ CRC ×ÓÅÊ Ó×ÏÅÊ ÏÂÌÁÓÔÉ ðúõ, É ÎÅ ÐÏÄÓÔÁ×ÉÛØ ÓÁÍ ÜÔy ëó, ÔÏ ÍÏÖÅÛØ ÐÏÌyÞÉÔØ ÎÅ ÓÏ×ÓÅÍ ÏÖÉÄÁÅÍÙÊ pÅÚyÌØÔÁÔ.

AA> ôÏÌØËÏ Ñ × ÎÁÓÔpÏÊËÁÈ ÐpÏÅËÔÁ ÕËÁÚÙ×ÁÀ ËÏÎËpÅÔÎÙÊ ËÁÍÅÎØ AA> (lpc2124), Á ÎÅ ÑÄpÏ.

AM>> á ÐÒÉ ÐÏÄÓÔÁÎÏ×ËÅ ×ÅËÔÏÒÁ AM>> ÎÁ óÉ ÐÒÁÇÍÏÊ ÐÒÉÄÅÔÓÑ ×ÉÄÉÍÏ ÄÅÌÁÔØ ËÁËÏÊ-ÔÏ ×ÎÅÛÎÅÊ ÕÔÉÌÉÔÏÊ. AA> óÏÍÎÅ×ÁÀÓØ. ôÅÍ ÎÅ ÍÅÎÅÅ, pÅÚÕÌØÔÁÔÁ pÁÂÏÔÙ ÐpÁÇÍÙ Ñ ÎÅ Õ×ÉÄÅÌ ÎÉ × ÌÏÇÁÈ AA> ÌÉÎËÅpÁ, ÎÉ × ÚÁÌÉÔÏÍ ÏÂpÁÚÅ.

HÁÄÏ ÐÏÐpÏÂÏ×ÁÔØ, pÁÄÉ ÉÎÔÅpÅÓÁ, ÎÏ ÎÅ ÐpÁËÔÉÞÅÓËÏÇÏ ÉÓÐÏÌØÚÏ×ÁÎÉÑ.

Файл зависимостей зависит от того же списка что и исходный файл. Поэтому зависимости автоматически пересобираются при изменении самого файла, его инклудов, параметров компиляции. Так делается всегда и во всех моих проектах, мне это удобно и понятно.

_______ Сергей.

Это работает если "родные компиляторы" умеют отдавать список зависимостей хоть в каком-то виде, так и делается если использую gcc, softune. Речи же не было что нужно пользоваться всегда одной утилитой для создания списков зависимостей.

Почему не сообщаешь какую?

Это как-то настраивается? или ищутся все слова "include"

_______ Сергей.

Tue, 08 Feb 2005 12:16:05 +0300 Sergey Pinigin wrote to Harry Zhurov:

SP> Это работает если "родные компиляторы" умеют отдавать список SP> зависимостей хоть в каком-то виде, так и делается если использую gcc, SP> softune.

Да, это (повторяюсь) самый корректный способ. Он, к сожалению, не переносим, и в случае компилятора, который не умеет отдавать, придется все равно искать способ, лежащий в стороне утилит (со всеми вытекающими недостатками).

SP> Речи же не было что нужно пользоваться всегда одной утилитой для SP> создания списков зависимостей.

Тогда придется иметь несколько систем сборок для разных платформ. Это тоже не есть предел желаний. В общем, идеального ничего, как всегда, нет, каждый выбирает себе решение по совокупности плюсов и минусов на свои задачи и вкус.

SP> Почему не сообщаешь какую?

А, нечего тут особо сообщать. Самописная.

SP> Это как-то настраивается? или ищутся все слова "include"

Не, все примитивно - по #include. Впрочем, так же, как и в случае с с/срр (во всяком случае навскидку я что-то отличий не вспоминаю). Зато работает, не возникает.

Привет!

Tue Feb 08 2005 12:16, Sergey Pinigin wrote to Harry Zhurov:

SP> Это работает если "родные компиляторы" умеют отдавать список SP> зависимостей хоть в каком-то виде, так и делается если использую SP> gcc, softune.

Я посмотрел, оба мои gcc умеют генерировать зависимости (ключ -M). А как эту полезную штуку использовать? Куда это можно в makefile прикрутить?

Юргис

Mon Feb 07 2005 20:33, Alexey Boyko wrote to Yuriy K:

AB>>> Итого предлагается написать make на bat'е? YK>> Предлагается объяснить преимущества make перед bat. YK>> Одно есть: ускорение сборки больших проектов. YK>> Приведи еще одно.

AB> При использовании make не нужно писать его функциональность на AB> bat-файлах.

Религиозные предпочтения неинтересны.

AB>>> ps: Возьмите вместо bat, какой-нить bash или tcsh. Или WSH AB>>> (Windows Scripting Host) YK>> Зачем?

AB> Hу, на них писать удобнее, чем на bat.

Религиозные предпочтения неинтересны.

WBR, Yuriy

Привет Andy!

AM>>> и чем он потом компилиpyется в obj? AM>> objcopy AM> Какой выходной фоpмат полyчается?

elf

AM> Я ведь понимаю так, что должен полyчиться текстовый файл, AM> веpнее всего *.asm c кyчей db. AM> Или я непpав?

Hеправ.

AM>> Я прекрасно понимаю, что позаботиться о нужном порядке сборки AM>> фрагментов можно и в рантайме (см. мое предыдущее письмо). Я лишь AM>> говорю о том, что это ничем не лучше, чем позаботиться о том же AM>> при линковке.

AM> В исходниках это хоpошо пpослеживается и опpеделяется явно.

Во-первых, скрипт линкера и Makefile - это тоже исходники (это такая же часть проекта, как и файлы *.c).

Во-вторых, вот такой комментарий:

#*************************************************************** # ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! # Определенная ниже последовательность модулей должна строго # соответствовать порядку подключения микросхем на плате!!! # Тот, кто бездумно поменяет их порядок, будет проклят. #*************************************************************** FPGA_CHAIN = ep1c6.elf epm1k100.elf last_plis.elf

делает это хорошо прослеживаемым и в скрипте линкера, и в Makefile. И определено, по-моему, явнее некуда. :)))

AM> Я пpедпочтy этот способ, он содеpжит меньше потенциальных гpабель.

Приведи пример потенциальных грабель, отсутствующих в этом способе.

AM> Потом, я даже не знаю, стандаpтизyется ли поведение линкеpов в части AM> поpядка линковки файлов или это поведение нyжно pассматpивать лишь как AM> частный слyчай.

Конечно, закладываться на недокументированные особенности линкера вредно. Это я считаю само собой разумеющимся. Использование же для получения нужной последовательности секций документированных штатных средств линкера я считаю ничем не хуже использования для той же цели штатных средств компилятора.

Кстати, если я правильно помню, речь шла не о порядке линковки файлов, а о порядке линковки вообще, т.е. порядок линковки секций/сегментов - это тоже порядок линковки.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Посетители должны общаться по сети.