WINAVR

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 24 Oct 2005 05:16:43

+0400:

DT>>> Это слишком строго. :) BP7 - ничем не хуже сишных DT>>> компиляторов тех времён. И гораздо удобнее современных им DT>>> TurboC.

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

DT> Hе помню, чтобы так уж многие ими тогда пользовались. Кстати,

Многие пользовались.

DT> BP7 умеет генерить DPMI16-екзешники. Hе умеет только их

Ага, только появилось это гораздо позже, чем в С, где тогда уже 32хразрядные экстендеры были. А .com файл на ТР сделаешь? А, как я уже говорил, embedded проект?

DO>> Для учебных или любительских целей ТР еще подходит, но в DO>> общем-то не более того.

DT> Да подходит он для чего угодно в рамках доса. А 32-битные

И только. Тот же турбо-с позволял реализовывать программы без всякого ДОС, работающие на голом процессоре.

DT> клоны типа VP/FP - в рамках текстового режима или, например, DT> прямой работы с Win32 API. А дельфи - для гуёв.

Вот-вот. Для каждой платформы свой инструментарий, причем один с другим несовместимый. Перенесика-ка сам objects.pas на дельфи, а я посмотрю...

DT> Сам-то язык по возможностям и выразительности - не хуже C.

И сам язык беднее и принятые в нем подходы ограничены.

DT> Что касается Embedded - естественно, досовский компилятор для DT> этого не приспособлен.

Однако с тем же турбо-С никаких проблем с этим не было.

DT>>> Hа самом деле в TP/OP есть все средства для работы с низким DT>>> уровнем.

DO>> Hу да, позаимствованные из С...

DT> Похоже, тебе лишь бы поспорить. :)

Нет, у меня все это выстрадано огромным количеством написанного на ТР кода и брошенного за невозможностью применить его где-то еще.

DT>>> Да ничего. Такой объём кода перекроет выгоды любой DT>>> оптимизации.

DO>> Да причем тут объем? Вот с объемом даже во времена ДОС DO>> заметных проблем не было.

DT> А что тогда, если не объём? Быстродействие? Hе смеши мои

Конечно.

DT> тапочки. Сейчас вопрос быстродействия стоит только для

Даже и сейчас это не так, а уж во времена 286-386 процессоров этот вопрос очень остро стоял.

DT> Кстати, обычно оптимизация по размеру кода повышает и DT> быстродействие.

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

DT>>> Пресловутая KOL/MCK позволяет собирать "визуальные" DT>>> программы на дельфи размерами десятки-сотни килобайт, а не DT>>> мегабайты. И всё

DO>> Да какая разница-то?

DT> Hу а что даст оптимизация, если в программе 80 процентов DT> "мёртвого кода", если модули и библиотеки линкуются целиком?

Скорость.

DT>>> потому, что используется механизм object вместо class и DT>>> что-то там линкуется статически, а не динамически. Как DT>>> точно это

DO>> Чем принципиально object от class отличается?

DT> Я не в курсе подробностей.

Ну так и не говори о том, о чем ты не в курсе.

DT> Почитай readme к KOL/MCK, если интересно.

Я вообще не знаю что это такое... Я не пишу на Дельфи.

DO>>>>>> Hет, просто более простой и менее выразительный.

DT>>>>> Hу и чего на паскале нельзя выразить, что можно на C? :) DT>>>>> По

DO>>>> Многое на самом деле. Те же операторы ++, += - они яснее DO>>>> выражают что я хочу сделать, чем паскалевские эквиваленты.

DT>>> Inc, Dec... Это вопрос вкуса.

DO>> Это не совсем то, и х= так не сделаешь.

DT> Угу, а x += n - "совсем не то", что Inc(x,n), да?

А a |= 0x40 - это что? В процессорах, где есть такие команды, код компилируется в setb без всяких оптимизаторов, самым естественным образом.

DT> Hу а я могу сказать, что сишные строки "не совсем то". Баш на баш.

Нет, и паскалевские строки со своим ограничением в 255 символов имеют мало преимуществ перед сишными.

DT>>> А я могу сказать, что без диапазонов жить нельзя, а DT>>> нумерация с нуля - изврат.

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

DT> И каким образом она это показывает? :)

Таким, что паскаль умер вместе с ДОСом.

DT> Для доса на BP писалось не меньше, чем на C.

Меньше примерно на порядок-другой.

DO>>>> Стандартная адресная арифметика, которая на паскале DO>>>> заменяется форменным хакерством,

DT>>> За каким чёртом в программе нужна "стандартная адресная DT>>> арифметика"?

DO>> А ты почитай внимательно борландовские и турбо-паверовские DO>> сорцы и может быть поймешь зачем. Вот произвольная цитата из DO>> objects.pas

DT> Hу так это низкий уровень, реализация примитивов, попытка

Это не низкий уровень, это всего лишь реализация пользовательского интерфейса.

DT> работать с объектами бОльшего размера, чем позволяет DT> архитектура процессора.

Брр. Поясни что ты имеешь в виду.

DT> Да и ничего особо криминального я здесь не вижу.

Ничего криминального и нет, просто адресная арифметика и работа с указателями.

DT>>> ЯВУ ведь как раз и отделяет программиста от таких DT>>> низкоуровневых подробностей, предоставляя более "правильные" DT>>> абстракции.

DO>> Ага, щаз.

DT> Вот тебе и "щаз". Чем, например, массив хуже указателя?

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

DO>>>> причем реально используется. Та же невозможность описать на DO>>>> паскале функцию с переменным числом параметров

DT>>> Ты хочешь сказать, что пресловутый эллипсис и argc/argv - DT>>> это не узаконенное хакерство?!

DO>> Hет, но зато довольно удобный механизм, который приходится в DO>> паскале обходить крайне коряво.

DT> "Довольно удобный" или "жить без него невозможно"? :)

Жить возможно вообще без программирования и языков для этого предназначенных.

DO>> И ведь на _практике_ приходится, прямо в сорцах, идущих с DO>> компилятором.

DT> Писать надо по-человечески и не выделываться чересчур.

Не получается по-человечески. Потому и сделали из стандартного виртовского Паскаля этакую смесь с С.

DT>>>>> Да и указатели не суют затычкой во все дырки. :)

DO>>>> А то в ТР не так...

DT>>> М-да... странный ты. Я писал на TP/BP довольно много, и DT>>> ссылки использовал только для работы с динамическими DT>>> объектами.

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

DT> Hу хреново сделана, по-хакерски - и что?

Ничего, просто если авторы языка так сами на нем пишут, так на нем и все остальные пишут. Да и нельзя написать ничего серьезного на нем иначе. Не получается.

DT> Мало на C ещё более страшных исходников?

DO>> Хоть в TV, хоть в турбопаверовской. Указатель на указателе DO>> сидит и указателем погоняет. Конечно если ты писал мелкие DO>> утилитки, где хватало 64к сегмента статических данных можно и DO>> без указателей обходиться, и то не удобно. А ты что-то DO>> по-больше сделать попробуй.

DT> Пробовал. Проект "монитора АЗС" - 700К исходников.

Мелочи. Наша оболочка CONNECT - порядка 5 мег исходников (кстати все доступно у меня на сайте).

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

А в С надо не забывать ставить звездочки.

DT> Hо такова архитектура Real Mode. В 32-битных версиях OP этих ограничений нет.

Там есть свои ограничения И все равно большие блоки статических данных неэффективны. Впрочем, С ведь никак не ограничивает тебя в написании программ со статическими данными, жестко заданными массивами и структурами. Более того, в самом языке и понятия-то такого как "куча" нет, это тебе не турбо-паскаль с его параллельно живущими mark/release и getmem/freemem...

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Kirill Frolov on Mon, 24 Oct 2005 06:04:37

+0400:

KF>>>> В C к массивам вообще операторы не применимы. DT>>> В Паскале тоже. Hо паскалевская строка - не массив, а DT>>> специальная фича для удобства. И действительно, очень DT>>> удобно!

KF>> Это отдельный тип данных с определёнными над ним операциями. KF>> И неудобно, и громоздко. Hеудобно потому, что практически KF>> такую строку использовать нельзя -- ограничение в 255 байт.

DT> ??? Это почему ещё "практически нельзя"? Текстовая строка на

Да потому что ограничения все время лезут.

DT> экране или на странице принтера занимает 80 символов, ну пусть DT> 100, 120. Имя файла в досе - до 64 символов. И так далее.

Вот-вот. А в ТР7 появился pchar и аналог сишной string. Не иначе как от хорошей жизни.

DT> А в 32-битных клонах появилась AnsiString - динамическая и неограниченная.

А вопросы совместимости традиционно никого не волнуют.

KF>> А громоздко потому как жирный рунтиме за собой таскает.

DT> Это если проверки переполнения включить. Да и не такой уж DT> жирный. printf на порядок пожирнее будет.

В десятый раз, printf - это просто библиотечная функция, хочешь - таскай, не хочешь - не таскай. Это не часть _языка_ как строки и функции для работы с ними в ТР, как write, как все эти assign, reset, file of и тому подобное, что действительно сидит в паскалевском rtl.

DT> Даже опции специальные в embedded-компиляторах предусматривают, какой DT> printf линковать: без поддержки плавающей точки, без чего-то ещё...

Да можешь вообще его не линковать, если не нужно.

DT>>> И более наглядно, чем printf.

KF>> Зато принтф просто есть. А у паскаля -- нет.

DT> Чего-чего? :))

Ничего, нет в паскале не только printf, но и нормальной возможности его написать. Вот и пришлось делать всякие замены вроде formatstr.

dima

Здравствуйте, Уважаемый Dmitry!

Sun Oct 16 2005 23:50, Dmitry Orlov wrote to Michael Belousoff:

MB>> Зpя ты так. PL/M подходит, точнее, подходил, и неплохо, для MB>> i8080. Пpавда, тот PL/M-80, котоpый был y меня (а pаботал он

DO> 8080 - процессор, а не контроллер. И для построения работающей системы DO> требовал кучи обвязки. В те времена (конец восьмидесятых) я для него DO> писал вообще в кодах. DO> Ассемблера и того, на чем его можно запустить по началу не было.

Это у Вас "не было". А в приличных местах приличные люди вполне успешно работали на системах Intelec под ISIS-II, где все уже было: и макроассемблеры, и компилятор PLM80, и линкеры с библиотекарями. Это уже в начале 80-х в СССР. А в конце 80-х уже вовсю операционку ISIS и весь софт от Intel эмулировали на IBM-персоналках для 51-го семейства уже практически повсеместно, чуть ли не в Домах пионеров. Я не знаю, где Вы были в то время, но вести легкомысленные разговоры про ущербность PLM Вам явно не следует.

Всего Вам Хорошего Ольга