WINAVR

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 21 Oct 2005 01:51:04

DT> Hello Dmitry.

DT> Fri Oct 21 2005 01:07, Dmitry Orlov wrote to me:

DO>>>> RTL - это не куча полезного кода, а реализация операций с DO>>>> неподдерживаемыми процессором типами. И есть такая DO>>>> библиотека у любого компилятора.

DT>>> Hу это у кого как. :)

DO>> И у кого же не так, как я сказал?

DT> Да у того же BP. Или VP, у которого в каталог RTL входят DT> такие исходники:

DT> Bldrtl.pas DT> Consts.pas

Да уж, особенно должно быть полезный код в этих

unit consts;

interface

{$R consts.RES}

const SAssignError = 61440; SFCreateError = 61441;

SMCIWaveAudio = 61662; SMCIUnknownError = 61663;

implementation

end.

Накидать в каталог чего угодно дело не хитрое, но собственно rtl является system - то, без чего компилятор вообще не работает.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Alex Mogilnikov on Fri, 21 Oct 2005 01:53:58

DT> Hello Alex.

DT> Fri Oct 21 2005 02:35, Alex Mogilnikov wrote to me:

DT>>> реализации, секция инициализации). Там, где хочешь этим DT>>> модулем воспользоваться, просто пишешь

DT>>> uses DT>>> MyNiceModule;

AM>> Это если некий внешний модуль используешь в паскалевском.

DT> Hет, это всё паскалевское. :) Чтобы прилинковать что-то, DT> написанное на C или ассеблере, надо вручную указывать файл, DT> который надо линковать и список внешних процедур/функций.

Ну это и в Паскале делается в интерфейсной секции. В некоторых реализациях - это отдельный файл, ничем по сути от .h не отличающийся.

AM>> А если наоборот, паскалевский модуль надо использовать где-то AM>> еще?

Тогда ничего не остается, как возвращаться к той же принятой и в других языках структуре. Интерфейсный (.h) файл, объектник, библиотека объектников. В ТР на это забили и использовать на нем написанное в других проектах невозможно. В других реализациях пошли более разумным путем.

DT> Hапример, где? :) Ты в своих проектах много "иноязычных" DT> модулей - кроме ассемблерных - используешь?

Я использовал в паскалевских программах и ассемблерные и сишные модули. Причем много и неоднократно.

DT>>> И всё, что описано в интерфейсной секции модуля DT>>> MyNiceModule, становится видимым в использующем коде (похоже DT>>> на namespaces).

AM>> У меня и без Паскаля все делается автоматически. В Makefile я AM>> перечисляю используемые модули:

AM>> SRC = module1 module2 module3

DT> :))) Hу ты ж их руками перечисляешь и в отдельном файле. И DT> H-файлы тебе надо не забыть писать и включать куда надо.

А uses mod1, mod2, mod3, причем разные в интерфейсе и в реализации описывать не надо в ручную? И тоже надо не забыть и включать не куда попало, а куда надо.

DT> А я всю нужную для линковки информацию указываю в исходниках.

А make файл не является частью исходников?

DT> Впрочем, конечно, это вопрос вкуса: по сути-то эти методы DT> эквивалентны.

Отож.

DT>>> Причём прилинкуется только тот код, который ты DT>>> действительно используешь

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

DT> Hо ты это сделал вручную, настраивая make, линкер, читая доки, DT> получилось не сразу и так далее? :)

В каком смысле не сразу? А на других языках программы сразу пишутся, или можно без чтения документации узнать какие модули и где надо включать?

DT> А в паскалевских компиляторах это всё встроенное и часть языка.

Причем языка нестандартного. По которому все равно надо читать документацию.

AM>> А у меня некоторые проекты компилируются несколько минут.

DT> Во-вторых, паскалевские компиляторы, особенно TP/BP - очень DT> быстрые. :)

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

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Ruslan Mohniuc on Fri, 21 Oct 2005 07:19:59

DT>>> А не лучше ли функции писать? :)

RM>> Hу например конкретно это у меня - четыре софтовых RM>> мастер-порта модбасовых RM>> RS485. Отличаются только адресами, по которым их структуры RM>> живут, и железячными привязками (таймер, ноги). Если RM>> организовываю как функцию, то есть передаю в нее указатель на RM>> структуру текущего порта,

DT> Можно и просто индекс... И если отличаются только данными, то DT> какой выигрыш может дать макрос в сравнении с функцией? DT> Может, структуры данных неправильно организованы?

Да какие там структуры? Адресами регистров они отличаются. На многих восьмиразрядных архитектурах косвенное обращение обходится существенно дороже прямого, вот и причина применения макроса вместо функции.

RM>> то размер кода (а главное -время его выполнения) RM>> увеличивается в два раза-

DT> Первый раз слышу, что функция по сравнению с макросом даёт DT> увеличение размера кода. :)

А с какими архитектурами ты работал?

DT> Hо тогда уж, конечно, лучше классами пользоваться, или на

И чем же классы лучше? Те же косвенные вызовы вместо прямых.

DT> худой конец темплейтами.

Вот этого механизма я не знаю.

DT> Макросы в C - это нуль проверки времени компиляции.

Это еще с каких дел? Компилируется-то развернутый макропроцессором код. Проблема макросов, особенно сложных (впрочем сишный макропроцессор особо сложные не умеет) в том, что обычно отсутствует механизм отладки самих макросов. Приходится писать, прогонять макропроцессор, смотреть его выход, и так далее. Пройти по шагам, посмотреть промежуточные результаты и значения переменных макропроцессора как правило нельзя.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 21 Oct 2005 07:27:00

DT>>> А компилятор на пару с линкером собирают исполняемый или DT>>> загружаемый файл - безо всяких хедеров, проектов и DT>>> зависимостей - на основании информации, присутствующей в DT>>> исходниках.

DO>> Hу сделали в Борланде make частью языка, и получили как DO>> удобство, особенно для новичка, так и негибкость. Скажем если DO>> частью проекта является сгенерированный каким-то средством DO>> исходник, описать это в make - не фиг делать, а тут надо репу DO>> чесать и тот же make использовать.

DT> H-не понял, исходник на каком языке?

Да какая разница?

DT> Если на паскале - то без проблем.

С проблемами, паскалевский встроенный make не понимает подобных вещей.

DT> Кстати, зачем генерировать исходник?

Бывает нужно сгенерировать именно исходник.

DT> Обычно генерируют данные.

Которые тоже паскалевский make не сумеет понять.

DO>> Как бонус - невозможность многоязыковых проектов. TPU - не DO>> подлинкуешь к Сишной программе (а наоборот можно, хоть и с DO>> рядом странных ограничений).

DT> Так ведь если проект на Паскале - то можно.

Только если или есть исходники или tpu той же версии

DT> А по поводу проектов на C ты же не говоришь о такой невозможности,

Потому что Сишные сорцы, хоть и не без геморроя, к паскалевским прицепить можно. А вот наоборот - только воспользоваться более нормальным компилятором с паскаля - не борландовским, с отдельным линкером и нормальной раздельной компиляцией. Я делал и то и другое.

DT> хоть туда TPU и не прилинкуешь. :)

Его вообще мало куда подлинкуешь.

DT> Кстати, а какие вообще бывают многоязыковые проекты, кроме DT> ЯВУ+ассемблер? Hу изредка ЯВУ+C...

Любые.

DT> Ограничения - да, местами странноватые. Hапример, в C-шном DT> или ассемблерном коде public можно объявить только код, а DT> данные надо объявлять обязательно в паскалевском модуле и DT> использовать, как external.

Причем если данные таки объявлены в объектнике - то все, его подлинковать уже нельзя.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Alex Mogilnikov on Fri, 21 Oct 2005 14:44:30

AM>>>> А если наоборот, паскалевский модуль надо использовать AM>>>> где-то еще?

DT>>> Hапример, где? :)

AM>> Hапример в ассемблерном.

DT> Паскалевский модуль привязывать к ассемблерному проекту? :) DT> Тонкое извращение. Обычно делают наоборот.

Потому что не наоборот ТР не позволяет никак. Ни стартап не поменять, ни от функций ДОС отвязаться. Сделать на нем embedded проект практически невозможно. Нормально же сделанные средства сочетаются в любом виде.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Alex Mogilnikov on Fri, 21 Oct 2005 14:47:10

DT>>> Hо ты это сделал вручную, настраивая make, линкер, читая DT>>> доки, получилось не сразу и так далее? :) А в паскалевских DT>>> компиляторах это всё встроенное и часть языка.

AM>> Да, конечно. Hе хочешь же ты сказать, что там ватроенный make AM>> можно не настраивать, и при этом все равно все сразу AM>> получается? :)

DT> Так я ж о том и толкую. Средства, которые в C реализуются DT> заголовками, проектами и зависимостями, здесь встроены в язык.

Сомнительное преимущество, иногда оборащивающее недостатками или как минимум негибкостью.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 21 Oct 2005 14:51:23

DT>>> Bldrtl.pas DT>>> Consts.pas

DO>> Да уж, особенно должно быть полезный код в этих

DT> Я ж могу и противоположные примеры привести, например, DT> SysUtils и VpUtils. DT> Именно что масса очень полезных функций.

Какое только они имеют к runtime library, кроме того, что в общем эклектичном духе, свойственном борландовским поделиям и их наследникам все подряд кидается в одну кучу? Отчасти это конечно и папой Виртом предопределено, который не нашел ничего лучше, чем засунуть в язык ввод-вывод, вместо того, чтобы обслуживать его стандартной библиотекой. Кстати это одна из причин, по которой на контроллерах, где нет никакой поддержки ВВ со стороны окружения программы, реализация того же паскаля просто невозможна. Это будет в лучшем случае паскаль-подобный язык. Та же кстати проблема и с динамической памятью.

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

dima