WINAVR

Hello, Nickita A Startcev! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 21 Oct 2005 15:01:30

DT>>>>> Вот в BP/VP/FP etc с компилятором поставляется RTL - Runtime DT>>>>> Library, куча полезных юнитов (это что-то вроде файла-библиотеки). :)

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

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

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

NA> файлы, сокеты, унихтайм всякий - это у процессора? :)

Это в библиотеке, а не в rtl. RTL - это именно то, что я сказал - поддержка компилятора для нереализуемых аппаратно типов и некоторых конструкций. То, без чего скомпилированный код работать не будет.

dima

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

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

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

DT> Hу, стандартный язык - это, пожалуй, только Ада... ;) DT> Впрочем, C - тоже стандарт ad hoc de facto. :)

На Паскаль тоже есть стандарт, другое дело, что Борланд его не придерживается ни разу.

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

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

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

DT> Для PC это не так важно.

Достаточно важно. Именно от этого в программах на ТР столько встроенного и невстроенного асма.

DT> Тут важнее ООП-щиной не увлекаться.

А она-то чем тебе не угодила? Сама по себе на х86 она большого оверхеда не дает.

DO>> Да и язык более простой, чем С.

DT> Правильно, более простой, понятный и продуманный.

Нет, просто более простой и менее выразительный. В продуманный язык не суют ввод-вывод, как языковое средство. В продуманный язык не суют два механизма работы с динамической памятью. И многие другие вещи.

DT> Хотя и нагруженный всякими рюшечками для удобства.

Причем выбор этих рюшечек весьма странен.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 21 Oct 2005 22:56:17

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

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

DT> Hу применить inline-функцию. Да и непосредственное обращение DT> к регистрам можно инкапсулировать.

Например как? Да и может просто не быть С++.

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

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

DT> С фон-Hеймановской и Гарвардской, как и все мы. :)

А конкретно?

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

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

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

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

DT> А это как раз такие навороченные макросы. Статический DT> полиморфизм.

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

DO>> Это еще с каких дел? Компилируется-то развернутый DO>> макропроцессором код.

DT> Который обычно не виден...

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

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

DT> И это тоже.

DT> Hет, макросы я предпочитаю в ассемблере.

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

dima

Hello, Nickita A Startcev! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 22 Oct 2005 00:12:36

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

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

NA> imho корень тормознутости не в оптимизации, а в NA> препроцессинге: препроцессору сишному приходится подсасывать NA> все инклюдники, парсить их, вставлять инклюдники, парсить... а NA> в паскале из TPU/TPL извлекаются уже "отпарсенные" NA> заголовки, с которыми гораздо меньше действий надо совершать.

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

dima

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

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

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

DT> Вах, а ты и это пытался? Уважаю. :)

Пытался, и даже делал. Делал на Stony Brook Pascal, распотрошив и переделав ему rtl. Из ТР ничего не получилось, хотя после того, как появились декомпилированные его сорцы, я делал на его основе генератор отчетов к другой программе. То есть генератор писался на паскале, компилировался модифицированным tpc, и исполнялся изнутри другой программы как некий плагин. Вобщем я через много всяких извращений прошел и оценил на сколько на С все это проще получается. Но отчасти мне самому Паскаль нравился больше, отчасти заказчики наши не хотели никакого С.

dima