WINAVR

Дело то в том что "просто Си" в принципе бывает, а вот полезного и жизнеспособного "просто паскаля" я что то не припомню. Ну не живой язык этот самый Виртовский паскаль - всегда приходится расширять его - и для эмбеддед и так просто. А вот чистый Си честно имплементированный - по крайней мере для обычного (с ОС) окружения вполне себе пригоден и примочки ассемблерные или расширения нужны только для облегчения/улучшения жизни.

А куда вдруг делись битовые поля из Си? Другое дело что используются они ну очень редко.

Часть библиотеки. Как часть языка - это только часть "hosted environment" - что позволяет не использовать ее совсем или использовать по другому в freestanding пирограмме (эмбеддед). Суть же printf не в том что он ввод-вывод делает, а в том что он демонстрирует метод КАК это делать в Си.

Кстати - в Си есть куча других программ с printf-Like интерфейсом - форматная строка какого нибудь вида и далее параметры полностью управляемые этим форматом - конечно можно и обойтись - но насколько это временами облегчает жизнь - особенно для печати сообщений об ошибках (не жизненно важно в эмбеддед)! Наличие такой фичи как varargs - позволяет такой код структурировать - что помогает сильно экономить место (а вот это для эмбеддед уже было важно).

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

Hello, Andrey Solomatov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 25 Oct 2005 08:10:05

+0000 (UTC):

AS>>> Классическое "Hello, vasja!" на Туурбопаскале занимало у AS>>> меня (без особых усилий с моей стороны) этак килобайта 3. AS>>> Аналогичное, но сделанное на Си - при всех усилиях не AS>>> помещалось в 9к.

DO>> Это ты С пользоваться не умеешь.

AS> Угумс. "А если Вы воспользуетесь напильником"...

DO>> Я его тебе в несколько десятков байт скомпилирую.

AS> Попробуй. Конечно, можно разобрать RTL, собрать её под себя... AS> Вот только тогда может проще асм заюзать?

Если тебе проще - юзай. Мне проще написать несколько функций ввода-вывода (на С) и ими пользоваться, если полнофункциональность имеющихся для меня слишком громоздка.

DO>> А вот на паскале - фиг, там нельзя никак переписать стартап и DO>> изменить состав system

AS> 9к - это не стартап, это printf. Во всяком случае у Борманда AS> было.

9к - это все вместе.

dima

Hello, Andrey Solomatov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 25 Oct 2005 07:52:11

+0000 (UTC):

AS> [кусь] DO>>>> В продуманный язык не суют два механизма работы с DO>>>> динамической памятью.

AS>>> malloc / free и new / delete ? ;))

DO>> malloc/free - это библиотечные функции, а new/delete в С нет DO>> :) и это совсем другое.

AS> Угумс. AS> Потому, что нормально реализовать работу с памятью через "классические" AS> функции невозможно - malloc возвращает void* (а раньше AS> возвращал char*). Но всё равно - это *два* механизма.

Один. malloc - это библиотечная функция, а не часть языка. В обычно турбопаскале, без объектов, есть два механизма mark/release и GetMem/FreeMem. New/Delete в OP - это другое.

AS>>> Кстати, а какие два механизма динамической памяти в паскале? AS>>> [кусь]

DO>> mark/release доставшиеся от папаши Вирта, и getmem/freemem - DO>> от С...

AS> Про getmem/freemem ничего не помню.

Твои проблемы. В ТР - это основной механизм для работы.

dima

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

Tue Oct 25 2005 14:22, Arcady Schekochikhin wrote to Andrey Solomatov:

AS> Дело то в том что "просто Си" в принципе бывает, а вот полезного и AS> жизнеспособного "просто паскаля" я что то не припомню. Hу не живой язык AS> этот самый Виртовский паскаль - всегда приходится расширять его - и для AS> эмбеддед и так просто. А вот чистый Си честно имплементированный - по AS> крайней мере для обычного (с ОС) окружения вполне себе пригоден и AS> примочки ассемблерные или расширения нужны только для AS> облегчения/улучшения жизни.

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

AS> А куда вдруг делись битовые поля из Си? Другое дело что используются они AS> ну очень редко.

Редко потому, что обработка этих битов в полях, например для AVR, производится компиляторами за несколько инструкций, внутрь которых может влезть прерывание, которое шустрит по соседним битовым полям- и привет Вася!

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

Hello, Andrey Solomatov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 25 Oct 2005 08:37:13

+0000 (UTC):

DO>> Операция плюс в языке программирования и в математике - DO>> существенно разные вещи. В математике 127+1 - всегда 128, а в DO>> языках программирования может быть и -1 и много чего еще.

AS> Ну, насколько мне известно результат -1 полученный от 127 +1 AS> всегда интерпретируется как ошибка. И ЯВУ придумывались не для

Где и когда это интерпретируется как ошибка?

AS> того, что-бы множить число новых операций.

Ты о чем?

AS> А то были любители вводить новые конструкции типа "выход из AS> второго вложенного цикла" и т.д. Тоже вроде выразительности добавляет...

А это о чем?

AS>>> Стандартная адресная арифметика всегда является хакерством.

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

AS> int i; AS> int *p = &i;

AS> p++; /* скажешь не хак? */

Нет конечно.

AS>>> С учётом того, что в Си эллипсис - это тоже полухак...

DO>> Вовсе нет, почему?

AS> Отказ от проверки типизации. Полный.

Я тебе уже показывал полный отказ от типизации в паскале.

DO>> Не более хакерская, чем передавать в функцию указатель, а уж DO>> это в паскале на право и на лево делается.

AS> В паскале все указатели типизированы.

Нет. Есть просто pointer.

AS> Плюс "направо-налево" можно передавать "по ссылке" - тот-же указатель, только AS> записывается удобнее - чей расширенный аналог - ссылки C++.

Ага, написал var v и передавай что хочешь.

DO>> Да и stdout можно было переназнчить, что в частности стартап DO>> модуля CRT и делал, только все равно не гибко все это очень.

AS> В смысле "негибко"?

А прямом. Ты не можешь формат вывода сделать изменяемым.

DO>> И сгородили, звалась drivers.formatstr. Посмотри на сколько DO>> коряво в сравнении с sprintf все это выглядит.

AS> А у меня просто вкусы другие.

Причем тут вкусы? Какой надо иметь вкус, чтобы такое вот понтравилось? Или это не хакерство? Или не паскаль?

procedure PrntMsg(Pref: String; var Text: String); var S: String; L: array[0..3] of Longint; begin L[0] := Longint(@Pref); L[1] := Longint(@HelpStrm^.FileName); L[2] := Count; L[3] := Longint(@Text); if Count > 0 then FormatStr(S, '%s: %s(%d): %s'#13#10, L) else FormatStr(S, '%s: %s %#3%s', L); PrintStr(S); end;

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

AS> Мне всегда было влом разбираться с этими закорючками в командной строке.

В командной строке чего?

AS>>> Ну, собственно, за пределы вывода строк/символов/числе AS>>> способности printf не распространяются -

DO>> Это уже не мало. В паскале и для этого городить приходится.

AS> ? AS> var i: integer; c: char; s: string; AS> f: file; AS> ... AS> write(f, i, c, s);

А теперь поинтересуйся как в паскале управлять форматом и шириной вывода (write(d:3:2)). И попробуй задать этот формат не в тексте программы, а как параметр.

DO>> Хочешь удивлю? Попробуй найти где-нибудь турбо-паскаль и DO>> скормить ему такой текст:

DO>> {$A+,B+,D+,E+,F-,G-,I+,L+,N+,O-,P-,Q-,R-,S+,T-,V-,X+,Y+} DO>> {$M 16384,0,655360}

AS> [кусь]

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

AS> А что делают псевдокомментарии вверху?

А в хелпе посмотри. Тоже кстати милая для "продуманного языка" штука - ключик B+ - управляет полностью вычислять логическое выражение или нет. И кому такое в голову пришло?

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

DO>> Ась? Какого типа "v" в вышеприведенном примере?

AS> Так мы обсуждаем язык или конкретную реализацию?

Учитывая, что в паскале конкретный язык, соответствующий ISO не помню какому обсуждать бессмысленно ввиду отсутствия вменяемых реализаций, приходится обсуждать языки реализаций, так как они существенно различаются. Сейчас обсуждались преимущества и недостатки борландовской (и отчасти совместимых) реализации со стандартным ANSI C.

AS> А то я щазз начну ругацца "а вот См не умеет работать с битовыми полями. AS> С битами - может, в т.ч. и как с элементами слова, а вот с полями, скажем в три бита - нет"

А как он должен с ними работать?

AS>>> В отстальном - не вижу особой разницы.

DO>> Посмотри на то как "изящно" вызывается drivers.formatstr по DO>> сравнению с sprintf и может быть увидишь разницу.

AS> Таки sprintf - это часть языка или как?

Нет, но язык позволяет написать такую функцию, в отличие от паскаля.

dima

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Arcady Schekochikhin on Tue, 25 Oct

2005 11:49:26 +0000 (UTC):

AS>> Дело то в том что "просто Си" в принципе бывает, а вот AS>> полезного и жизнеспособного "просто паскаля" я что то не AS>> припомню. Hу не живой язык этот самый Виртовский паскаль - AS>> всегда приходится расширять его - и для эмбеддед и так AS>> просто.

ON> Расширять синтаксис, вводить новые ключевые слова, ON> отказываться от прежних, приходится всегда, когда классические ON> Паскаль и Си напчинают натягивать на другую архитектуру ON> процессора, не ту, в которой они были рождены.

А для какой они были рождены?

ON> В Си, например, пришлось впендюривать аттрибут FLASH, а за ним и целую, совсем

Не в С, а в конкретную реализацию, причем пользоваться этим совсем не обязательно. И зачем ее туда всунули лично я не понимаю. Вполне достаточно было бы описать объект как константу, чтобы она размещалась в ПЗУ, как это например в HiTech для PIC сделано. Впрочем добавление модификаторов для переменных и функций не идет ни в какое сравнение с переделаками, которым был подвергнут виртовский паскаль для придания ему минимальной юзабилити в реальном программировании.

ON> нестандартную библиотеку работы с константами из FLASH.

AS>> А куда вдруг делись битовые поля из Си? Другое дело что AS>> используются они ну очень редко.

ON> Редко потому, что обработка этих битов в полях, например для ON> AVR, производится компиляторами за несколько инструкций,

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

ON> внутрь которых может влезть прерывание, которое шустрит по ON> соседним битовым полям- и привет Вася!

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

dima