ATmega после x86

Ustus
В той задаче количество прерываний могло быть до 168000 в секунду, а частота процессора 32МГц, то есть на одно прерывание около 200 тактов. Вроде бы вполне достаточно чтобы обработать один байт. Только вот код, который вставлял сишный компилятор в обработчик прерывания, сохранял/восстанавливал порядка 30 регистров и съедал большую половину времени. Переписывание обработчика на ассемблер позволило сократить количество сохраняемых регистров до 5, да и в остальном коде количество команд уменьшилось раза в 2-3.
Я не призываю всё делать на ассемблере, но в некоторых случаях на нём "в лоб" решается задача, которую на си можно решить только с жуткими извращениями.

 

qqwe

Ну, это да
Хочу язык, который этому мешает

Не было там поставщика, это наше, внутреннее чудище. Человек уволился - попало ко мне на сопровождение. Так что, в данной ситуации поставщик - это как бы я

Не столько асма, сколько его неуместного использования.

И этот аспект... ?

Black_mirror

Возможно, просто хреновый компилятор? Что за контроллер/копилятор, если не секрет?

Кто бы спорил - а я не буду Бывает, все бывает...

 

Ustus
xmega / AVRStudio+gcc

 

SII

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

Black_mirror

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

разводка мк с обвязкой на 40 ногом дип

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

Ustus

мешает писать проги нечитабельно мешает больше всего на сегодняшний день - питон
сопротивляется нечаянной и даже в какойто мере нарочной глючности - паскалевая линия. выделю модульный оберон и его девайсный вариант оберон-07

бывший тут богдант портировал (или пробовал) оберон-07 для генерации под авр, но что получилось - не знаю, потому что полная зависимость от А2

лично я бы сделал вариант оберон-07, но в синтаксисе наподобие питона и типизацией взятой из лимбо (потоки-каналы можно тоже потом взять для МК их понимающих). сохранив питоновую систему модулей.
и даже не на С, а на распространенном интерпретаторе. например, том же питоне. это значительно упростит дальнейшие правки, развитие и перенаправление (например, сорслевел дебугер или профайлер). кроме того, работать это будет на всем на что портирован питон, те почти на всем.
далее, компиляцию с проходом через п-код. крупнозернистый-адресный, это облегчит написание оптимизаторов/кодогенераторов(для начала просто транслятора в С) к нему. ну, и прогнать для проверки алгосов можно будет без использования эмуляторов.

зачем я все эти глупости тут написал? потому, что написать это все с 0 (оберон-07 прост по синтаксису) будет проще, быстрее и дешевле, чем разбирать, отлаживать и править. чем убеждать писать не в хакерском стиле и без использования хакерских фокусов на самых хакерских языках (асм, С, С++).
почему пишу слова вместо возьми и напиши ланг? не знаю, наверно охота в коллективе. да и лучше так выйдет. не все, что нравится мне устраивает и других.

плохой менеджмент. например, чела неправильно мотивировали к работе (предпочли надавить чем заплатить), он скомпилил в асм с оптимизацией, подставив где надо абсолютные значения. асм сдал. такое тоже может быть.

 

Black_mirror

Странно... вроде бы gcc в хреновом коде не уличен... простейший случай прерывания:

Код (Text):

1. ISR( USART_RXC_vect )
2.   92:   1f 92           push    r1
3.   94:   0f 92           push    r0
4.   96:   0f b6           in  r0, 0x3f    ; 63
5.   98:   0f 92           push    r0
6.   9a:   11 24           eor r1, r1
7.   9c:   8f 93           push    r24
8.   9e:   ef 93           push    r30
9.   a0:   ff 93           push    r31
10. {
11.     *r_ptr++ = UDR;
12.   a2:   8c b1           in  r24, 0x0c   ; 12
13.   a4:   e0 91 60 00     lds r30, 0x0060
14.   a8:   f0 91 61 00     lds r31, 0x0061
15.   ac:   81 93           st  Z+, r24
16.   ae:   f0 93 61 00     sts 0x0061, r31
17.   b2:   e0 93 60 00     sts 0x0060, r30
18.      ++r_bytes;
19.   b6:   80 91 62 00     lds r24, 0x0062
20.   ba:   8f 5f           subi    r24, 0xFF   ; 255
21.   bc:   80 93 62 00     sts 0x0062, r24
22. }
23.   c0:   ff 91           pop r31
24.   c2:   ef 91           pop r30
25.   c4:   8f 91           pop r24
26.   c6:   0f 90           pop r0
27.   c8:   0f be           out 0x3f, r0    ; 63
28.   ca:   0f 90           pop r0
29.   cc:   1f 90           pop r1
30.   ce:   18 95           reti

- пять регистров и есть.
Может вы в прерывание чего лишнего напихали?

 

qqwe

Не, никто там не давил. Было, правда, надцатикратное изменение ТЗ по ходу работы, но ИМХО, это не оправдание. И на С у него такой же бардак, зато ну очень красиво оформленный, со строгим форматированием и комментами чуть на каждую строку. Только оно все ни хрена не помогает, увы...
Я вообще заметил, что среди мк-программеров мало вменяемых, туда часто попадают в основном железячники-радиолюбители, а для них софт сугубо вторичен, поэтому навыки программирования у них хреновые и улучшение не планируется. Увы еще раз.

 

Ustus
Честно говоря, я уже не помню почему компилятор сохранял все регистры, логика там была такая, что когда в буфере окажутся 4 байта с одинаковыми старшими тетрадами, из младших тетрад нужно собрать 16 битное значение, этот кусок кода компилятор оптимизировал хорошо, но уж слишком с размахом регистры использовал. А может я туда еще воткнул вызов какой-то простенькой библиотечной функции, и компилятор решил, что он не знает какие она может использовать регистры.

 

Ustus
Как компилирует GCC для AVR, я не знаю, не использовал, но для ARM он даёт очень плохой код, да и для IA-32 вчистую проигрывает мелкомягкому на любых режимах оптимизации. Так что, думаю, и для AVR он на самом деле даёт плохой, просто не всегда это проявляется. Главные же претензии к его качеству на ARMе -- "склероз" (не помнит, что лежит в регистрах, из-за чего постоянно генерит команды загрузки одного и того же значения), неумение грамотно распорядиться регистрами (что-то загрузил в один из регистров -- начинает потом пересылать в другие без всякой на то нужды), в Thumb-2 по крайней мере в некоторых случаях -- внесение (!) ненужных команд в циклы. Ну и плюс временами неверная кодогенерация. Небольшой примерчик его глупостей я дал в http://osdev.ru/viewtopic.php?f=6&t=433; если любопытно, можете глянуть.

 

Ustus

сложный вопрос. иногда этими изменениями так достают, что начинаешь писать только для галочки - все равно заставят все переписать еще N-раз. в независимости от качества и трудозатрат. менеджеру ведь не понятно, что вот это "маленькое изменение/дополнение" требует переписывания и переотладки на 70%.

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

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

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

SII
в гцц такой себе оптимайзер. и для х86 и для арм дает большой код. для авр тоже самый толстый. иаровский, говорят, боле мене плотненько генерит.

 

qqwe
Ну, я для АТмеги писал толкьо на ассемблере (и правильно сделал, как выяснилось -- иначе б в память не влезло), ну а для АРМа пишу на смеси ассемблера (ядро оси и драйверы ядра) и Ады (код режима пользователя; компилятор из состава гецеце -- качество кода похабное, конечно, но для задач обычно терпимо). Изначально думал и ядро на Аде написать почти целиком, но быстренько убедился и в низком качестве кода, и в регулярных ошибках кодогенерации, и просто в нестабильности транслятора (правда, тогда были версии 4.4.х и более ранние; 4.5.3 ещё ни разу не падала на ровном месте, хотя код по-прежнему хреновый и временами кривой).

 

SII
в гцц, вроде, кодогенератор 1 на всех? оптимизация сложная штука. ленятся все. это раньше битва за байт шла (сужу по тому, что в мсвс качество кода не улучшается).
из открытых самый приличный оптимизатор в опенватком. причем, описанный. в кодогенераторах нет ни авр, ни арм. и непонятно почему никто не допишет на основе того же мипсовского.
вообще непонятна низкая популярность ов. сравните тотже ов графический дебугер и гнутый гдб. ов линер - вообще сказка.
может быть причина в гнутых расширениях и поддержке новых стандартов? так парсер там на яцц - добавить синтаксическую конструкцию куда проще чем замутить нормальную оптимизацию кода на выходе.
ладно, это опять я за свое

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

 

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

Кстати говоря, Ада не так сложна, как кажется на первый взгляд. Монструозный объём описания связан не столько со сложностью самого языка (Си++ намного сложней и... хм... неинтуитивней, что ли), сколько с самим подходом к его проектированию и описанию: все возможные нюансы должны быть описаны абсолютно точно. Кроме того, в том же мануале идёт описание стандартной библиотеки, что тоже занимает немало места.

 

Black_mirror

Да, это наиболее вероятно, наверное.

SII

С gcc на ARM не копался, ничего не скажу, а на AVR дает вполне приемлемый код. Правда, IAR лучше (чаще всего, редко бывает, что хуже). Ну, и я бы не сказал, что для IA-32 так уж все однозначно. MS здорово паттерны отлавливает - этого у него не отнимешь, но в остальном я бы сказал, что они практически на равных.

qqwe

Да вроде бы уже давно нет, или я что-то путаю?

И вообще, Солнце взорвется, потом погаснет и мы все умрем Не падайте духом, будет хуже!

SII

По-моему, с третьего, что ли, не помню, там одинаковый только фронт-енд, и то я временами сомневаюсь...

И вообще, господа программеры микроконтроллеров, не отчаивайтесь! Видели бы вы на чем приходится работать нашим несчастным ПЛИСовцам - вот там уж точно никогда не проходил ни Керниган, ни Сэти, ни Кнут. Я, конечно, глубоко не вникал, но ИМХО, скажем VHDL - это такая БАГодельня, что никакому С не снилось. А Verilog - это почти то же самое, только плюс все глюки от Си Про оптимизацию я вообще молчу - ее можно делать только перед релизом, ибо несколько часов гарантировано. На i5 x4.

Кстати, если уже пошел холивар про компилеры, никто внезапно не посоветует приличный компилер на PIC18? А то родной microchip'овский - такую гадость делает, никакому гэцэцэ не снилось

 

Ustus
VHDL -- вполне себе нормальный язык для своих задач. Вполне возможно, что ваши ПЛИСовцы просто работать не умеют: такое встречается, увы, часто. Одна из причин, подозреваю, заключается в том, что к программированию ПЛИС подходят как к обычному программированию, хотя "программа" для ПЛИС -- это не описание последовательности стандартных операций, как на обычных процессорах, а описание функций создаваемых отдельных блоков (которые работают одновременно друг с другом) и их связей друг с другом. Само мышление должно порядком отличаться при программировании для МК и для ПЛИС. У меня, например, в своё время были приличные сложности даже с элементарной задачей: сделать на ПЛИС свой контроллер интерфейса PS/2. Нарисовать его принципиальную схему -- никаких проблем, устройство же простое. А вот запрограммировать ПЛИС -- фигвам. Правда, когда более-менее проникся, всё получилось, но мозги напрягать пришлось: очень уж непривычно. (Сейчас, правда, почти всё позабывал: работать-то по работе с ПЛИС не приходится, только для себя баловался, ну а последний год для баловства особо времени и нет; тем более, что всякую мелочь делать неинтересно -- это так, для освоения годится, -- ну а на серьёзное требуется прилично времени).

 

Ustus
VHDL не язык программирования, а язык описания. А так называемые мифические "глюки" это часто собственная некомпетентность в каких-то вопросах.

 

h0t
Верно замечено. Об этом, собсно, я и хотел сказать. Ну а посему использование его как обычного языка программирования, мягко говоря, неправильно. Видел как-то ПЛИСовскую реализацию PDP-11 на Верилоге. Это ужас... чувствуется, что автор тупо написал эмулятор на Си, а потом ещё более тупо переводил в Верилог, абсолютно не учитывая принципиальную разницу между ПЛИС и обычным процессором.

 

Ustus

плохо выразился. 1 кодогенератор для всех компилеров, но на 1 целевую платформу.

оччень оптимистическое утверждение. ов, да, дает сравнимый код. иногда хуже, а иногда лучше.
ну а гцц стабильно дает раза в 1.5-2 толще + странные недоделки, вроде неумения рассчитать в статике константное выражение.

 

SII

Умеют, умеют. Хотя и не все А язык не то, чтобы нормальный, просто другого не дано...
h0t

Я разве упоминал какие-то "глюки"? Это не глюки, это гораздо хуже. Дело именно в том, что некомпетентность (в идеале) должна приводить к ошибкам при компиляции, а не к труднообнаружимым логическим выкрутасам софта. Это, как мне видится, ни что иное, как детская болезнь, которой процедурные языки давно уже переболели, только в С оно тянется "в целях совместимости". Всякие же HDL такого бурного развития не имели, поэтому и застряли где-то на уровне С.
Что же касается языка программирования или там описания - что-то не вижу принципиальной разницы :P

 

Ustus

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

например, в хдл есть перегруппировка шин ( {sig1, 1'b 0, bus1[3], bus1[2], bus[8], 1'b 1 } ), причем, как для параметров, так и для результатов. кроме числовых - z и x состояния. функции и блоки имеют другой смысл, скорее, макросы. цикличность организуется совсем по-другому (в обычных языках вообще нет синхронизаторов (always)). наличие типа проводов (wire), наличие статической логики (assign out = sig1 == 0 ? in1 : sig2 == 1 ? in2 | in3 : bus1 > 8 ? in4 : in5 & in 6, причем, на статическую логику попадает чуть ли не большая часть описания (?программы?). работа с подключенными модулями путем подачи сигналов, а не прямым вызовом, причем, все модули работают все время и одновременно.
есть еще моментов, например выравнивание задержек разных ветвей динамических частей (always ...), чтоб 1 не держала все остальные. или моменты с параллельным и последовательным выполнением (например, reg [7:0] a = 8; ...... a <= 12; a <= a + 1; чему будет равно a?).

 

Упоминали

Это Вам не С# (некомпетентность на том же ассемблере к ошибкам компиляции не приводит), и "компиляции" там нет а есть термен "fit". HDL языки имеют ровно столько сколько нужно. Если не видите разницы то читайте http://en.wikipedia.org/wiki/VHDL и просвещайтесь.