Pascal для AVR Опции

[DMD]

Здравствуйте.
Ребят, посоветуйте хороший компилятор паскаля для AVR, в частности для серии ATTiny, но лучше для большинства (а то мало ли что).
И ещё, не подскажете - слишком придется "платить" за язык высокого уровня в смысле объема кода? А то тут проект светит, там на ассемблере далеко не уедешь, язык С скучный, хочу вот паскаль освоить...
Спасибо.

[Жека]

Господа программеры, можно список того, что делается на Си, но не делается на Паскале?
С точки зрения конечной задачи, а не какие-то нюансы синтаксиса

[defunct]

Господа программеры, можно список того, что делается на Си, но не делается на Паскале?

Могу привести обратное.
"C" не предоставляет стандартных средств для работы со строками (присваивать, сравнивать, складывать). Паскаль - предоставляет.

Но проблема не в том какой язык лучше, какой хуже. Проблема в том что хороших компиляторов с Паскаля для AVR нет. Все что я видел (а видел я аж 2 таких компилятора - ELAB и микро-чего-то-там) неполноценны. Стоит ли расчитывать, что работая с неполноценным компилятором получится что-то полноценное?

[zhevak]

Могу привести обратное.
"C" не предоставляет стандартных средств для работы со строками (присваивать, сравнивать, складывать). Паскаль - предоставляет.

Это что, разве проблема? Конечно, си-шные операции со строками несколько отвлекают от бизнес-логики, нужно помнить размер буфера, нужно подключать билиотеки. Но с другой стороны -- процесс полностью контролируется! Меня вообще убивало непонимание как работают эти же операции в том же Васике. С Паскалем более-менее понятно. А там, где нет понимания, возникает риск.

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

[code]
PROCEDURE OUTER
VAR
...
BEGIN

PROCEDURE INNER
VAR
BEGIN
...
END
[code]
Языковая среда -- Турбо-Паскаль для ДОС.

Но проблема не в том какой язык лучше, какой хуже. Проблема в том что хороших компиляторов с Паскаля для AVR нет. Все что я видел (а видел я аж 2 таких компилятора - ELAB и микро-чего-то-там) неполноценны. Стоит ли расчитывать, что работая с неполноценным компилятором получится что-то полноценное?

Вот что за фигня такая -- здесь, вот, некоторые люди упорно доказывают, что Паскаль лучше Си. Но почему ни одна уважающая себя фирма-писатель-компиляторов не хочет написать Паскаль-компилятор. Почему? Если верить товарищам, защищающим позицию Паскаля, то успех будет беспечен, и мало-ли что там маркетологи вещают! Я выбираю инструмент не по тому укритерию, что как про него говорят, а по тому, на сколько мне удобно с ним работать, на сколько он хорошо создает продукт.

[defunct]

Вот, что лично меня убило в Паскале, так это то, что внутри процедуры можно было определять вложенные процедуры таким образом, что опреторная скобочка END для обеих процедур являлась возвратом. С точки зрения Си -- это дикость и нонсэнс!

.

В Паскале нет той дикости о которой вы говорите.
если надлежащим образом оформить выглядит абсолютно прозрачно:

Код

procedure outer;
var ...
    procedure inner;
    begin
    end;

begin
    inner
end;

Вот что за фигня такая -- здесь, вот, некоторые люди упорно доказывают, что Паскаль лучше Си. Но почему ни одна уважающая себя фирма-писатель-компиляторов не хочет написать Паскаль-компилятор. Почему?

В некоторых аспектах - определенно лучше, в некоторых - нет. Если мне нужно быстро сварганить программу для обработки лог файла я предпочту сделать это на Pascal'е. Если что-то overIP - то я определенно предпочту C. Другой вопрос - это ширина круга задач на котором Pascal выигрывает как инструмент, в контексте embedded даимерт этого круга равен нулю (потому и нет серзъезных компиляторов с Паскаля для embedded МК).

А вообще - всякий овощ полезен....

[zhevak]

В Паскале нет той дикости о которой вы говорите.

Да. Признаю. Это я спутал с Васиком, где строки нужно было нумеровать... Там вообще никаких правл не бвло! Спутал оформление Паскалеских процедур с оформлением самой программы. Вопрос снимаю.
Наезд на Паскаль был не обоснован.

В некоторых аспектах - определенно лучше, в некоторых - нет. Если мне нужно быстро сварганить программу для обработки лог файла я предпочту сделать это на Pascal'е. Если что-то overIP - то я определенно предпочту C. Другой вопрос - это ширина круга задач на котором Pascal выигрывает как инструмент, в контексте embedded даимерт этого круга равен нулю (потому и нет серзъезных компиляторов с Паскаля для embedded МК).

А вообще - всякий овощ полезен....

В том-то и дело! В сфере МК Паскаль -- аутсайдер. Но и в сфере ПК (обсуждать которую здесь на нашем форуме не совсем легитимно) Паскаль тоже далеко не блещет. Почему для обработки логов Вы выбрали бы именно Паскаль? Ведь на шестом Вижуал-Васике, или на Шарпе, или даже на том же Perl Ваша задача решилась бы еще легче. На сколько я понял, Ваша задача -- одноразовая. Для себя любимого, а не для коробочных продаж. Вам совсем не нужен компилятр. Я предвосхищаю ответ -- "Мне так удобнее, т.к. я знаю Паскаль лучше, чем BASIC/C#/Perl." Ключевое слово -- "я знаю", а не "Паскаль лучше подходит, чем Шарп". Т.е. опять же получается, что аргумент не в пользу Паскаля.

Кстати, мне недавно пришлось делать выбор, похожий на Ваш. Мне нужно было из текстового документа выдернуть данные измерений, и посчитать кое-какую статистику (мин, макс, среднее, отклонение, ...), упорядочить их, вывести результаты. В общем мура всякая. Одноразовая. Сначала я начал писать на Шарпе, т.к. там легче все это сделать. Но потом, я понял, что я пишу шарповскими операторами, но стилем Си++. Т.е. мыслю-то я все равно на Си++. (Это очень сложно знать два языка и одновременно мыслить на них.) Я задвинул проект на Шарпе и лекго решил свою задачу на старом добром VC++ 6.0 в консоли. А с выводом результатов в файл я вообще не стал заморачиваться -- просто вывел их на косоль через printf, а с консоли забрал их в файл ДОСовскими пайпами средствами, типа так: myProg.exe >> result.txt.

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

Почему я вернулся на Си, а не сделал ее красиво на Шарпе? -- Да потому что мне так было легче. Если б я знал так же хорошо Шарп, если б я "мыслил Шарпом", я бы сделал все на Шарпе. Но я мыслю на русском и на Си. Поэтому мне легче на этих языках выражать свои мысли. Но это совсем не значит, что я не знаю английский и, скажем, тот же Паскаль. Просто для меня они второстепенны. (Думаю, что в этом я не уникален. Большинство программистов думают точно так же, ну или примерно так же.)

Почему я считаю, что Паскаль мертв? -- Потому, что низкоуровневое (железное) программирование -- это удел Си/Си++, а высокоуровневое -- удел Шарпа. Паскалю, в этом отношении, нет места. Не имеет он особого преимущества ни там, ни там.

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


Блин, поспал называется! Пойду давану, хоть пару часов что-ли...