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

Вариант: создаем проект в Delphi-8, компилим. Затем декомпилим в cpp-clr. Затем снова компилим, gcc++ или как он там называется. В общем, все упрется в либы, т.е. framework. Но framework для линуха есть, gtk#, как минимум, а с ним исходники, которые можно попробовать скомпилить куда надо. Порт M$ Framework под линух вроде бы тоже есть, но я как-то его еще не нашел. Иначе таки просить у M$ исходники micro-framework - он дают своим партнерам типа под nda. Готов кто договорится ?

Вот такида! +1


Ну, на кой мне для РС такие сложности? А на МК - Тут же все делается на своих либах. Или вот - FPC для ARM. Такшта...

Сурово. Месье знает толк ...

Прога, которую ищите, по сути, тоже компилер/декомпилер. Вообще, такую вещь можно самостоятельно и цивильно сделать. Но только на C#(или его братьях-сестрах).
На своих либах - проще. Только нуево, писать свои либы, если есть возможность использовать чужие и отлаженные. Я за это даже бга паять научусь ) Надеюсь.

В продолжение дискуссии

Отличий в стековом байт-кодовом подходе VM ( виртуальных машин ) Java и С# меньше,
чем можно себе представить. Для Java ( байт-кода ) и С# ( MSIL - байт-кода ) есть даже
front-end для Си компиляторов.

При достаточной мотивации использовать ( не совсем понимаю, что значит поднять ) можно
уже были ссылки на 2-а старт проекта Java для AVR ( поищите nanoVM и JODE )

На Iar интересуясь для AVR ( поднимал 2-у лет назад ) Java интерпретатор. ( ~14Кб)
Для каких-то применений возможно, и в таком виде, использовать. Для серьёзного, использования
из Java, пожалуй, стоит для МК убрать понятие GC ( сборки мусора) и создать оптимизатор ( на базе JIT ) из байт-кода в нативный код требуемого контроллера. И будет вам счастье

P.S. Универсальный ассемблер - не сильно большая утопия.
Как вариант наиболее близкий к этому подходу можно использовать Forth ( Форт).

Так вот куда все подевались, а я всё пропустил.
Хочу вставить свои 5 копеек.

Итак на мой взгляд.
1) Автор топика прав. Дают не знания, а учат получать и усваивать знания, которые необходимы. Для этого необходим кругозор, систематизация и т.п. К примеру, на 5 курсе мне надо было в среднем от 2 до 7 дней чтобы выучить и сдать любой экзамен. Средний бал у меня был 4.7
2) Количество языков, исходя из п.1., желательно всётаки больше. Это приводит к общему пониманию как работает процессор или система программирования. Как работает компилятор. Приведу пример, по поводу обсуждаемого for. Если на это посмотреть так как я смотрю на это, то оператора for в С просто нет! Есть три оператора, которые компилятор размещает возле скобок{}.
Хорошо это или плохо? Это даёт понимание, но только после знакомства с Pascal.
3) А вот ++ мне кажется построены значительно хуже чем object Pascal (Delfi). И это, на мой взгляд, следствие простоты синтаксиса С. Расширение синтаксиса, привело к труднозапоминаемым конструкциям. А в Паскале стройность построения и относительная сложность привела к органичному "вписанию" объектов. Иными словами, как всегда, две стороны одной медали. Достоинства и есть недостатки. Именно поэтому студенты должны сравнивать. Сами сравнивать.

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

Есть в ObjectPascal (Pascal упоминать не надо - это совсем не то, что подразумевают по этоим словом) шаблоны и множественное наследование?


Какие конструкции в С++ вы относите к труднозапоминаемым?

Я не говорю о конкретных возможностях языка, не об эффективности компилятора, не о стройности построения. Я говорю о синтаксисе языка, притянутом за уши.

Вы сейчас можете утверждать что угодно, но давайте посадите простого паренька за компьютер, не вдаваясь в подробности с преподом рядом. На Delfi он создаст самостоятельное приложение через 2 дня. Можно с объектами. На билдере (Той же фирмы) он будет с той же задачей мудохатся неделю.

Что означает конструкция "::"? С чем она у вас ассоциируется? Как скоро появится C+++? Там надо будет ввести конструкцию ":::", а также ":;:" и "::::". Это, на мой взгляд, банальное продолжение синтаксиса С "for(;;){}". Но при 10 операторах и 6 ключевых словах это супер, а вот в плюсах это конкретный недостаток.

Конечно, когда знаний вагон и опыта море - это не мешает а помогает (писать быстрее), но в освоении очень тяжело. Это я вам по собственному опыту говорю. А я с разными языками знакомился.

Это объективный факт. Посмотрите какие сложности с программерами на плюсах.

Да, а почему нет множественного наследования в c#, наследнике ++ ?
Нате вам


http://www.javable.com/docs/articles/minherit/

Для паскаля тоже верно.


Кстати, про краткость: сравните . и ^ с :: и ->

Сообщение отредактировал Огурцов - Nov 27 2008, 16:17

Приложение одного уровня в Delfi и Builder'е будет создано за сопоставимое время.


У меня это ассоциируется с областью видимости. Очень хороший оператор, улучшает читабельность, простой, лаконичный, однозначный. Не понимаю, чем он вас так испугал.


Это просто ваши фантазии. Нет никакой связи между количеством плюсов в названии и количеством двоеточий - это ваши фантазии, не понятно на чем основанные.

И к вопросу, который я задал, это не относится. Напомню, что вы упомянули какие-то труднозапоминаемые конструкции в С++, я такие что-то не помню/не знаю, поэтому меня это заинтересовало, и я решил уточнить, какие именно конструкции для вас труднозапоминаемые. Оказалось, что оператор области видимости ::.



Во как! А for(;;){} чем не угодило?


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




Кто вам сказал эту глупость? Что С# наследник С++.

Что касается жабы и шарпа, то применямые в них решения будем сравнивать с С++ тогда, когда они сравнятся по эффективности. Включая заявления о "правильности проектирования". Вот и все.

А если не видно разницы...(с) то нафиг этот билдер.
И вообще, нафиг этот билдер - глюкало еще то.
Гораздо лучше по-честному - либо Delphi, либо VS.


Наврено сам придумал. Но копирайт поставить не могу - вдруг прочитал где.
Ок, а иначе кто наследник ?


Ну не сравнивайте шарп и оригинальную (не java#) жабу по быстродействию. Шарповский X-код ложится прямо на команды таргета, а джава (не java#)- все-таки интерпретатор. Так что если вы по эффективности одного делаете предположение о другом, то ошибаетесь. Шарп по эффективности ничуть не хуже, чем це++, а по остальным критериям, включая легкость разработки, так и гораздо лучше.

В Delphi 2009 шаблоны есть. http://www.codegear.com/article/38622/imag...oUpgradeRUS.pdf

+1

Да ладно вам. С каких это пор MSIL стал ложиться прямо на команды таргета? Да, JIT компиляция - вещь хорошая, но до нормального оптимизатора нормального компилятора C++ ей как "до Шанхая пешком".
PS. AFAIK, Java тоже использует JIT компиляцию..

Да нет, угодило. Всем угодило. Более того, для МК считаю значительно более удобным. Основное преимущество, что могу выбрать степень детализации задания компилятору. То есть более точно донести компилятору, что я хочу получить от этого кода.
Ну и плюс, что меня не контролирует компилятор понапрасну. Ну типа "a=a-'0';".

Но ничего не вижу ужасного и если я напишу begin-end вместо {}. Написание текста - малая часть от создания проги.

Я пытался указать, что лаконичность C (малое число ключевых слов) совершенно закономерно перешла на C++. Но там, намного больше надо передать. И в паскале ничто не мешает введению целой кучи новых ключевых слов. А в плюсах - построение. На мой взгляд выглядит натянуто и неубедительно. Начинаешь терятся в этой программе.

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

Будучи студентом, мы изучали Fortran IV, потом PL/I. Ну а сам я работал на Fortran 77, Basic несколько позже Pascal. Но, считаю, что очень многое я переосмыслил когда начал на ассемблере писать.
Причём именно после ЯВУ.

Я считаю, что если бы мне дали один С (тогда он не так распространён был), то было бы хуже. Всётаки надо несколько языков и подходов. И лучше всего именно разноплановых.

К тому же, с чего вы взяли что все будут по завершению этого вуза программистами по МК. Человек может устроится куда угодно и в любой момент лихо завернуть свою судьбу. Например, будет по симатику работать. А там LAD/FBD/STL/SCL. То есть из языков - один ассемблеро-подобный, второй паскале-подобный. А о Си, к сожалению речи не идёт. Я уже о плюсах и не говорю.

Ссылку http://www.mikroe.com/ru/ надеюсь давали???


ЗЫ: Правда - не пользовался. Библиотеки помощнее чем в CV AVR были. И ММС и ЖКИ, включая графический, клава матричная, 24с и прочее. Вместе с эмуляцией. Почему убрали - не знаю.

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