архитектуры arm, avr

[Sash0k]

Доброго времени.

Смотрю в trunk fpc и удивляюсь: оказывается авр потихоньку пилят. Насколько понимаю, пилят по образу и подобию gcc-avr, который уже давно есть и хорошо работает.
Идея иметь свободный компилятор под свободную ОС для авр на любимом языке очень хороша. Пользовался компилятором от mikroE для PIC24 - иде у них конечно не идеальная (тем более что хотят за нее 200 баксов), но работать можно. Прошивка получается может и не оптимальная, но скорость доработки/удобство поддержки радует.

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

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

Дополнение: arm интересует именно в Ъ-варианте arm-linux (wince ненужно)

[SII]

Я смотрел МикроПаскаль под AVR8 -- это ужас. Код мало того, что крайне неэффективный, так ещё время от времени ошибочный. В общем, для серьёзной работы не годится абсолютно, во всяком случае, на AVR. Сейчас, правда, AVR меня уже не интересует: на работе от них отказываемся, переходим на ARMы. Хорошо бы, конечно, было получить нормально работающий Паскаль...

Кстати, о GCC. Недавно для интереса сравнивал на маленьком примерчике качество кодогенерации у него (и у самого Си, и у Ады, входящей в состав GCC) с "официальным" ARMовским компилятором от KEIL:

http://osdev.ru/viewtopic.php?f=6&t=433

. В итоге пришёл к выводу, что для серьёзной работы системного уровня GCC под ARM не подходит. Ну а поскольку писать на Си у меня ни малейшего желания нет, весь низкий уровень продолжу клепать на ассемблере. Вот вопрос с прикладным ПО пока открыт: несмотря на неэффективность транслятора, Ада как язык хороша, но и от Паскаля не отказался бы, буде нашёлся б более-менее нормально работающий транслятор.

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

[kipar]

Поддержка arm была бы неплоха, но для С есть FreeRTOS и другие подобные ОСи, а для паскаля таких наработок нет и непонятно когда появятся. А писать свой шедулер и TCP/IP как-то нет желания.

Еще поддержка arm интересна в плане разработки под Андроид. Если доведут до ума - будет просто сказка.

[SII]

Ну, я б постыдился FreeRTOS, как и всякие подобные коммерческие вещи (типа кейловской RTX или как там её) назвать осью: такой примитив за день-два пишется (имеется в виду собственно эти "типа ОС", а не поддержка сети, но одно с другим прямо не связано: сеть может быть реализована вообще без всякой ОС, ну а ОС вполне может существовать без сети). Всякие линухи меня не устраивают: во-первых, они ни разу не ОСРВ (попробуй предскажи, насколько быстро будет обработано то или иное прерывание, не говоря уже о времени активации определённого потока режима пользователя), громоздки, неэффективны; во-вторых, имеют извращённый АПИ, унаследованный от Униха (в частности, нет нормального асинхронного ввода-вывода); ну а в-третьих, требуют обязательного наличия MMU и вообще "жирной" аппаратуры, ну а для встраиваемых систем сие не всегда позволительно и практически никогда реально не требуется. Правда, имеется какой-то недоЛинух (ucLinux вроде зовётся), который менее требователен к железу, но кардинально качества системы этим не улучшаются... QNX много лучше, но всё равно не шибко удачный АПИ (поскольку опять-таки восходит к Униху) плюс наличие MMU, да и для коммерческого применения она платна. Ну а посему изобретаем собственную ось

[Sash0k]

Поддержка arm была бы неплоха, но для С есть FreeRTOS и другие подобные ОСи, а для паскаля таких наработок нет и непонятно когда появятся. А писать свой шедулер и TCP/IP как-то нет желания.

Еще поддержка arm интересна в плане разработки под Андроид. Если доведут до ума - будет просто сказка.

Это вы под словом "arm" имеете ввиду микроконтроллер. Мне же интересно использование arm - как процессоров общего назначения для ширпотребовских компьютеров (т.е. замену сегодняшним x86).
Вот простое и понятное описание тегры, там есть немного про армы, и картинка, взятая с arm.com. Сама компания arm условно делит процессоры на 3 группы: classic, embedded, aplication.
Мне кажется интересным иметь компилятор с паскаля, при помощи которого можно писать один код для архитектур x86 и arm (-Tlinux, разумеется). fpc уже это умеет, но, как понимаю, разработкой arm занимаются значительно меньше, чем x86, и дела у нас на сегодняшний момент хуже, чем в gcc.

Поддержка ведроида к поддержке арм, как я понимаю отношения не имеет, там софт в виртуальной машине исполняется, да и сам ведроид работает отнюдь не только на армах.

[SII]

С архитектурой ARM не совсем так. Грубо говоря, можно разделить все процессорные ядра, разработанные этой фирмой, на две большие группы: семейство Cortex-M (архитектура версий ARMv6-M и ARMv7-M), использующееся только для микроконтроллеров, причём начального уровня (ну, для 32-разрядных начального, конечно ), и всё остальное -- хоть древние ядра ARM7 (версия ARMv4), хоть новейшие Cortex-A, причём сюда входят как контроллеры, так и процессоры. "Все остальные" являются "настоящими" ARMами с единой системной архитектурой и системой команд (общая метода обработки прерываний, общий набор регистров, общий набор инструкций и т.п., просто более поздние версии архитектуры имеют всякие дополнения, отсутствовавшие у более ранних версий), поэтому здесь, говоря о компиляторе, некорректно делить по признаку контроллер/процессор: для них должен генерироваться одинаковый код, разница кроется лишь в аппаратуре управления памятью и периферии, что к трансляции никакого отношения не имеет. А вот Cortex-M, строго говоря, вообще нельзя считать ARMом: у них абсолютно иная системная архитектура (в частности, совсем по-другому обрабатываются прерывания) и отсутствует "родная" система команд ARM, реализована лишь Thumb или Thumb-2, но она имеется и у "нормальных" ARMов, начиная с версии ARMv4T, ну а более древние на рынке уже отсутствуют.

Соответственно, чтобы транслятор годился для разработки программ для Cortex-M, от него требуется в обязательном порядке поддержка генерации кода для системы команд Thumb/Thumb-2, для всех остальных можно обойтись одной ARM, но намного лучше иметь обе, поскольку ARMовский код пожирает очень много памяти, а это неприятно, даже если сама память не является дефицитным ресурсом.

[kipar]

Ну, я б постыдился FreeRTOS, как и всякие подобные коммерческие вещи (типа кейловской RTX или как там её) назвать осью: такой примитив за день-два пишется (имеется в виду собственно эти "типа ОС", а не поддержка сети, но одно с другим прямо не связано: сеть может быть реализована вообще без всякой ОС, ну а ОС вполне может существовать без сети).

Но суть в том, что для С есть и поддержка сети (uIP & lwIP) и FreeRTOS (т.е. многозадачность + оптимизированная реализация очередей для общения между задачами + всякие рутинные моменты по инициализации, так что можно сразу запустить тестовое приложение (веб-сервер) на любой поддерживоемой железке и потом модифицировать его под свои нужды). А для Паскаля этого всего (пока?) нет. Если бы было - с радостью бы перешел на паскаль.

Поддержка ведроида к поддержке арм, как я понимаю отношения не имеет, там софт в виртуальной машине исполняется, да и сам ведроид работает отнюдь не только на армах.

Нет, там можно нативные приложения писать. Нужно только компилятор под arm-linux и виджетсет доработать.

[.wOvAN]

Windows 8 в сентябре обещают в виде превью или даже беты, так что поддержка arm дело полезное.

[Sash0k]

Windows 8 в сентябре обещают

Вот только зачем она нужна, если по бинарникам она несовместима с х86? % ПО на .NET не думаю, что очень большой сейчас, да и сам дотнет годится далеко не для всего.

[SII]

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

[Sash0k]

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

Это уже холивар, но покажите мне качественный продукт от ms, который они от начала до конца разработали сами
ядро NT - изначально не их, а больше ничего от них полезного навскидку как-то в голову не приходит

[SII]

А чьё, интересно, ядро NT? С луны свалилось? Но дело даже не в этом. На самом деле неважно, что у кого и когда какая контора приобрела, а важно, что она предлагает сейчас. МС Офис и удобнее, и быстрее, и стабильнее, чем ОпенОфис, например. ИЕ -- далеко не лучший браузер, но, тем не менее, для практического использования вполне пригоден. ВизуалСтудио -- хорошая среда для разработки, а заодно и весьма неплохой компилятор для IA-32 (по слухам, получше, чем GCC, хотя и уступает интеловскому; сам я на Си практически никогда не пишу, а посему сравнениями не занимался, но в низком качестве кода GCC для ARM убедился). Есть и ERP-системы (бывшие Navision и Axapta, которые действительно были во время оно куплены мелкомягкими; сейчас не помню, как это направление обзывается, вроде Dynamics, но название, понятное дело, неважно)... В общем, сия контора может предложить клиентам весьма широкий выбор ПО и для офиса, и для бизнеса, и для разработки приложений, а не только "голую" систему. Ну а уж разработать всякие мелкие "свистелки" и "перделки" вроде книгочиталок при нужде она уж точно сможет в короткий срок.

[Ism]

А чьё, интересно, ядро NT? С луны свалилось?

http://ru.wikipedia.org/wiki/OS/2

Добавлено спустя 7 минут 19 секунд:

В общем, сия контора может предложить клиентам весьма широкий выбор ПО и для офиса, и для бизнеса,

Прикол в том, что их приложения очень тяжеловесны или требуют объемистых библиотек (смотрим на .NET 4 и размер Win 7 после установки всех обновлений )
Вы не можете выкинуть то, что вам не нужно из Win. А это ведет только к уменьшению производительности и надежности.
Интересно, что изменится в Windows 8 при переходе на Arm ?

[SII]

Если Вы обратили внимание, OS/2 разрабатывалась совместно Майкрософтом и ИБМом, ну а то, что впоследствии они разругались, сего факта не меняет. Рабочее название новой системы Микрософт, NT OS/2, говорит разве что о том, что сию систему изначально задумывали как замену полуоси на базе неких "новых технологий" (коих в ней не было начисто, но это уж другой вопрос). Эту систему разрабатывал исключительно коллектив Майкрософт, а руководил им выходец из DEC Дэвид Катлер. В результате в ядре NT без проблем угадывается родство с VAX/VMS, ну а эта система появилась малость раньше, чем MS DOS, не говоря уж о OS/2 (помню, что, когда пришлось писать драйвер для NT 4, у меня было стойкое ощущение дежавю -- до этого много работал с предком VAX/VMS, системой RSX-11M, ну и самим VMSом был немного знаком; лишь много позже я узнал, в чём дело, ну а тогда, году эдак в 1995, я понятия не имел, кто возглавлял проектирование NT). В общем, к OS/2 у NT отношение очень и очень косвенное, и, если уж ставить мелкомягким в вину (или в заслугу -- это уж с какой стороны смотреть) заимствование чужих идей, то "пострадавшей" стороной будет DEC, а отнюдь не IBM (её OS/2, включая последнюю из виденных мною версий -- 3.0, была "лучшей Windows", если рассматривать 16-разрядные Windows 3.0/3.1, но никак не 32-разрядную NT). Кстати говоря, уход Катлера из ДЕК был связан как раз с разногласиями относительно дальнейших путей развития, и, как показала история, ошибалось руководство фирмы, а не их ведуший программист...

Добавлено спустя 6 минут 12 секунд:

Прикол в том, что их приложения очень тяжеловесны или требуют объемистых библиотек (смотрим на .NET 4 и размер Win 7 после установки всех обновлений )
Вы не можете выкинуть то, что вам не нужно из Win. А это ведет только к уменьшению производительности и надежности.
Интересно, что изменится в Windows 8 при переходе на Arm ?

Насчёт размеров не могу не согласиться. На счёт "не можете выкинуть" -- не согласен, хотя такое выкидывание сопряжено со значительными трудностями. Однако альтернатива в лице Линух технически, пожалуй, ещё хуже будет, ну а то, что её потенциально можно настроить "под себя", ситуацию в корне поменять не может: непомерно раздутое и неповоротливое ядро никуда не денется... В общем, будем ждать Вынь-8 и посмотрим, крепчает ли маразм у мелкомягких или (надежда умирает последней ) всё ж чуточка здравого смысла появилась.

[Ism]

хотя такое выкидывание сопряжено со значительными трудностями

Просто все предоставляют интерфейс, но мало предоставляют способов его контроля(вариантов использования). Все приходится пилить самому.
Кроме того при модификации софта Windows вы нарушаете лицензию и лишаетесь гарантии и техподдержки.
В общем замкнутый круг.