WINAVR

Loading thread data ...

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

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

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

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

Reply to
Arcady Schekochikhin

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

Reply to
Arcady Schekochikhin

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

formatting link

Reply to
Dmitry Orlov

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

formatting link

Reply to
Dmitry Orlov

Здравствуйте, Уважаемый 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, производится компиляторами за несколько инструкций, внутрь которых может влезть прерывание, которое шустрит по соседним битовым полям- и привет Вася!

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

Reply to
Olga Nonova

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

formatting link

Reply to
Dmitry Orlov

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

formatting link

Reply to
Dmitry Orlov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.