ARM Pascal compiler

[defecator]

Я использую портированную под Delphi версию FreePascal
для разработки своего открытого проекта ARM Pascal.

Если есть заинтересованные программисты, прошу на мой сайт:
http://www.arm-pascal.ru/

[скалогрыз]

хорошее начинание...

А зачем нужно было компилятор переписывать под Delphi? почему бы не собирать компилятор самим же FreePascal-ем?
может правильнее было модифицировать уже существующий компилятор, изменяя его под нужный ARM процессор, как это сделано здесь: http://svn.freepascal.org/svn/fpc/branc ... /armthumb/ ?!

[defecator]

Потому что мне лично не нравится:
1. Нет среды разработки, которая устраивала бы меня по качеству и удобству. Ведь сам по себе компилятор никаких удобств разработчику не приносит, если его приходится запускать батниками из командной строки. Главное в разработке - это удобство написания, отладки и (само)документирования кода, а сам по себе компилятор - это всего лишь инструмент по преобразованию одного языка в другой.
2. Компилятор FPC во всех средах является по отношению к ним "инородным" телом.
3. Компилятор FPC не имеет в своем составе "нативного" генератора бинарного кода для ARM, и предлагается использовать сторонний ассемблер и сторонний линкер. И вот и получается - среда разработки использует сторонний компилятор, который, в свою очередь, использует сторонний ассемблер и линкер. Я хочу иметь все в одном флаконе, ровно так же, как работает в этом плане хотя бы Borland Pascal.

По ссылке посмотрел - ничего такого "потрясного" не обнаружил. Как не было "нативного" ассемблера, так и нет. Хотя кое-какие идеи оттуда, безусловно, я почерпну несомненно.

И потом, папка "arm" что в "родном" компиляторе, что по Вашей ссылке - не поддерживает генерацию кода хотя бы для семейства ARM микроконтроллеров LPC2000. Это вовсе не то же самое, что напереводить API для WinCE и потом юзать генератор COFF.
Какие-то абстрактные машины, типа "embedded". Что это ? О чем это ? Я начал именно с этого, и убедился, что "embedded" - это сферический конь в вакууме. Код "ни о чем".

Я не ради наездов это все пишу, а ради того, чтобы показать, что наш родной и любимый FreePascal больше заточен для разработки программ для систем с устоявшейся программно-аппаратной архитектурой и не позволяет (возможно, пока) генерировать код для архитектуры "Embedded ARM" так же просто, как для Linux или для Windows.

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

[скалогрыз]

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

Да и "людей в помощь" можно будет проще найти, используя уже раскурченный бренд и сайт FPC

3. Компилятор FPC не имеет в своем составе "нативного" генератора бинарного кода для ARM, и предлагается использовать сторонний ассемблер и сторонний линкер.

Не соглашусь с тем, что нету "нативного генератора" бинарного кода! Он есть! только он ещё не написан

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

Например под Win32 компилятор, по-умолчанию, работает без помощи сторонних утилит, но одним лишь ключиком командной строки, может переключится на генерацию ассемблера и внешних утилит (as и ld).

я не знаю о твоих планах на компилятор, но:
* есть правильный путь: расширять компилятор, используя предоставленные в нём возможности (Если возможностей не хватает, то нужно это обсуждать с разработчиками, и дополнительные возможноси появяться).
* есть неправильный путь: изменять (переписывать компилятор). "Выбрасывая" всё что "не нужно" для конечной цели (поддержка ARM). Почему это неправильно - получается обосбленный продукт. FPC уйдёт вперёд (появятся дополнительные расширения и/или возможности, исправленны баги). Твой компилятор останется на месте.

Кстати, изменение кода компилятора под делфи - уже превый шаг по неправильному пути!

По своему опыту скажу. Прикручивая внутренний линкер для darwin-i386 платформы, я использовал Lazarus. Никаких неудобств не испытывал по этому поводу. Но т.к. времени мало, линкер пока что бросил писать, хотя надеюсь его закончить и добавить в FPC до конца года.

И потом, папка "arm" что в "родном" компиляторе, что по Вашей ссылке - не поддерживает генерацию кода хотя бы для семейства ARM микроконтроллеров LPC2000. Это вовсе не то же самое, что напереводить API для WinCE и потом юзать генератор COFF.

http://wiki.freepascal.org/Embedded
http://www.mail-archive.com/fpc-devel@l ... 14623.html

gnu tools поддерживают LPC2000 (ибо это ARM7TDMI-S). т.е. использовать внешний ассемблер - правильно и разумно(потому что получишь результат быстрее).
Переводя содержимое статьи в FPC wiki,

Добавление нового контроллера

Чтобы добавить новый тип контроллера, нужно выполнить простых шага:
1-расширить компилятор, чтобы он знал имя контроллера
2-добавить скрипт линковки для этого контроллера
3-создать rtl модуль (для контроллера) с описанием регистров и начальным кодом.

я тебя не отговариваю! бери - пиши, правь! на то он и open-source Просто какая твоя цель: сделать новую паскаль-систему, или заработать, как можно больше денег, совершив при этом как можно меньше телодвижений?!

[defecator]

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

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

Именно это я и делаю !
Плюс доработки синтаксиса Pascal для поддержки прерываний,
ввел несколько новых макросов для определения карты памяти и добавил генерацию кода для сохранения/восстановления регистров при обработке прерываний.


Вот этот кусок текста меня как раз кардинально и не устраивает в статье по Вашей ссылке:

Чтобы добавить новый тип контроллера, нужно выполнить простых шага:
1-расширить компилятор, чтобы он знал имя контроллера
2-добавить скрипт линковки для этого контроллера

Пункт 1 Я не хочу, при появлении нового контроллера, заново собирать компилятор. Компилятор вообще не должен знать, какой именно контроллер я использую. Его задача - генерить код из того, что я ему подкладываю. Что он должен знать - так это то, как генерить код для процессора ARM. Все остальное должно быть в pas-файлах, сторонних по отношению к компилятору - все описания регистров, стартовый код - все должно быть "вовне" в виде библиотек, юнитов. Пункт 3 как раз про это и пишет.
Пункт 2 Если написать "нативный" ассемблер и линкер, никаких скриптов добавлять не придется. Компилятор должен знать только карту распределения памяти для конкретного контроллера, а ее как раз можно держать в тех же pas-файлах.

Все описанные "простые шаги" - это хорошо для разработчика компилятора, но не для пользователя компилятора. Потому что человек, который пишет программы для того же ARM, может вовсе не владеть сборкой компилятора, ковырянием его кода для добавления чего-то там. Между нами говоря, большинство программ из мира OpenSource рассчитаны как раз на предлагаемую модель - если что-то тебе надо, возьми и скомпили себе сам. А если человеку ЭТО надо, но у него просто нет навыков сборки и добавления ? Нет опыта ?
И мнимая свобода оборачивается дерганьем в те области, в которых человек не является специалистом.
Ну ладно, это я увлекся

Код компилятора для переноса в Delphi изменился о-о-о-очень несильно.
И никаких проблем с обновлениями я не обнаружил.
Изначально я брал версию 2.2.2, и переводил ее.
Когда же скачал версию 2.2.4 - обновился на нее произошло примерно за час в ручном режиме.
Для этого есть замечательный инструмент - Araxis Merge. Код компилятора изменяется не очень значительно от версии к версии,
и если постоянно держать руку на пульсе и вовремя синхронизировать свой код с текущим кодом FPC, то изменений будет совсем не много. Так что за поддержку компилятора в свежем состоянии я не волнуюсь


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

[Bupyc]

Или кто-то может сказать, что он работает не за деньги, а за интерес ?

Не, всё правильно. Работать просто за интерес как то не здорово. Однако для себя я выбрал следующий принцип: прежде всего стараться стать профессионалом в той области, которой я занимаюсь, а уже потом думать, как на этом денег заработать. Т.е. интерес имеет всё таки больший приоритет. Ну это так, к слову.

Есть вопрос по поводу поддержки компилятора в актуальном состоянии. Как быть, если в компиляторе будут использованы какие-нибудь синтаксические конструкции, отсутствующие в делфи? Например, генерики. Или перегрузка операторов.

[defecator]

Есть вопрос по поводу поддержки компилятора в актуальном состоянии. Как быть, если в компиляторе будут использованы какие-нибудь синтаксические конструкции, отсутствующие в делфи? Например, генерики. Или перегрузка операторов.

И генерики, и перегрузка операторов есть в Delphi.
Только я сомневаюсь, что в обозримом будущем в компиляторе появятся генерики - зачем они там ?

Заодно спрошу тут, может быть, кто-то знает, что это такое, хотя бы логический смысл этого.
По поводу операции с множествами. В FPC есть оператор ><, описан как ">< is for a symetric diff for sets"
Как можно это представить для компилятора Delphi ? Сейчас я сделал просто операцию "-" вместо "><"

[Mr.Smart]

Только я сомневаюсь, что в обозримом будущем в компиляторе появятся генерики - зачем они там ?

http://wiki.freepascal.org/Generics

[defecator]

Только я сомневаюсь, что в обозримом будущем в компиляторе появятся генерики - зачем они там ?

http://wiki.freepascal.org/Generics

Mr.Smart, имелось ввиду, что генерики появятся в коде компилятора, а не в синтаксисе языка

[Attid]

defecator
мне кажется вы не поняли сообщение скалогрыза. может перечитаете еще раз ? он как раз и говорит что можно дорабатывать родной компилятор с внутреним асмом и линковщиком. тогда не надо лепить свое детище, а взращивать общаковского =)

[defecator]

defecator
мне кажется вы не поняли сообщение скалогрыза. может перечитаете еще раз ? он как раз и говорит что можно дорабатывать родной компилятор с внутреним асмом и линковщиком. тогда не надо лепить свое детище, а взращивать общаковского =)

Я как раз понял, о чем он написал
Еще раз повторюсь
Я не хочу дорабатывать родной компилятор на родном же компиляторе.
Я уже писал - мне абсолютно неудобны средства разработки, которые предлагаются для работы с FPC.
Я привык к Delphi, у меня куча удобных мне библиотек, большое число наработок. Зачем мне уходить с него на FPC ?

Я хочу сделать на базе FPC узкозаточенный инструмент, но этот инструмент будет удобен мне и, надеюсь,
разработчикам, которые будут его использовать.
Мне не нужен компилятор "сам-по-себе", мне нужна интегрированная среда разработки для ARM, не имеющая и, по возможности, не использующая сторонних программ. И код компилятора FPC - это всего лишь часть этой среды. Я для этого его и портировал под Delphi, чтобы он стал частью моей программы.

[скалогрыз]

Я хочу сделать на базе FPC узкозаточенный инструмент, но этот инструмент будет удобен мне и, надеюсь, разработчикам, которые будут его использовать.

и именно по-этому сайт называется ARM pascal, а не FPC for ARM

кроме ассемблера для embedded систем на чём принято писать?!

[defecator]

Кроме ассемблера принято писать исключительно на Сях. Имхо, мерзопакостных и богопротивных

Для ARM, в отличие от контроллеров 8051,AVR, программирование на голом ассемблере - это довольно жутковатое занятие.
Потому что система команд заточена под поддержку компиляторов с языков высокого уровня.


Я у себя на сайте выложил исходники порта компилятора версии 2.2.4 под Delphi.
Примечания.
1. Из исходников компилятора начисто убрана поддержка любых процессоров, кроме ARM. Сделано для того, чтобы "лишний" код не мешал восприятию
2. Исходники в части файла options.pas слегка изменены, так что подсказку по параметрам командной строки выводить не будет
3. В папке bin_gba лежит собранный компилятор и тестовый проект

http://www.arm-pascal.ru/index.php?page=cmsms_tags

P.S. Кто там говорил, что нереально собрать FPC в Delphi ?

[скалогрыз]

Примечания.
1. Из исходников компилятора начисто убрана поддержка любых процессоров, кроме ARM. Сделано для того, чтобы "лишний" код не мешал восприятию
2. Исходники в части файла options.pas слегка изменены, так что подсказку по параметрам командной строки выводить не будет

2й и 3й шаги в "неправильном" направлении. Совместить изменения с 2.5.1 уже будет намного труднее, да и зачем?!

хотя никто не запрещает написать свой компилятор (с блекджэком и шлюхами).

я бы ещё раз советовал, обратиться в fpc-devel рассылку, с предложением обоюдного сотрудничества! выступить с идей универсального "rtl" и возможности подключения необходимых startup-ов модулями.

[defecator]

Скажем так, в том виде, в котором я "эксплуатирую" исходники, файл options.pas вообще отсутствует как класс. То есть он не используется. В сборке, которую я выложил, просто файлы - перевод под Delphi.

А в сборке моей среды разработки уже довольно хорошо измененный парсер для обработки новых директив компилятора (например, $MEMBANK(x),$FLASHSIZE...,$STARTUP, еще несколько), обработки процедур прерываний ARM (в "родном" FPC этого нет ничего). Как говорится, работа кипит

Нормально совместятся исправления Гарантирую Araxis Merge - наше все
Да и структуру исходников я довольно хорошо знаю и "проникся" ею.

я бы ещё раз советовал, обратиться в fpc-devel рассылку, с предложением обоюдного сотрудничества! выступить с идей универсального "rtl" и возможности подключения необходимых startup-ов модулями.

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