Языки программирования

[TomCaT]

Хорошо. Беру слова назад. С + ассемблер, но по крайней мере до 20-30 МГц -- с уклоном в сторону последнего, т.е. после переноса и до окончательной сборки, конечно.

[Vitamin]

С + ассемблер, но по крайней мере до 20-30 МГц -- с уклоном в сторону последнего, т.е. после переноса и до окончательной сборки, конечно.

8051@1Мгц вполне терпимо исполняет код, собранный из С. И это с учетом одного-единственного 16-разрядного регистра. Для спека должно быть получше...

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

[maximk]

Кто-нибудь находил версию GCC для зетника? А то перерыл дофига ссылок- одни огрызки информации, ни сорцов ни бинарника.

Та же фигня. Но есть открытый компилятор из ACK, причем его можно оптимизировать. Имхо, эта задача на порядок проще, чем писать back-end к gcc.

[Vitamin]

Но есть открытый компилятор из ACK, причем его можно оптимизировать.

Подробнее можно? Не слышал о таком чтото...

Имхо, эта задача на порядок проще, чем писать back-end к gcc.

Гм... Иногда проще написать заново, нежели переделывать уже написанно

[maximk]

Подробнее можно? Не слышал о таком чтото...

ACK = Amsterdam Compiler Kit.

http://tack.sourceforge.net/

Целый пакет из средств разработки. Компилятор C, как и другие (еще поддерживаются несколько языков) производит промежуточный код, а back-end'ы из него создают код для целевой платформы. Причем, как транслировать промежуточный байт-код в реальный описывается на специальном языке. И соответствующее описание для генерации кода z80 уже есть! Но, как и сказано в доке, оно не оптимально, ибо за основу был взят вариант от i8080.

[Vitamin]

ACK = Amsterdam Compiler Kit.

Почитал, завтра скачаю и попробую под никсами собрать и попрогонять. Хочется посмотреть асм на выходе. Ибо все существующие кросс-компилеры такую хрень городят... Разве что IAR по слухам весьма достойно себя ведет (надо достать попробовать).

[Robus]

Графическая библиотека для монохромных жк-дисплеев- всякие линии, точки, пропорциональная печать со стилями, работа с изображениями, буферизация, аппаратная независимость от реализации (работало даже на подключаемом через последовательный канал дисплее). Вторая библиотека- пользовательский интерфейс в стиле меню для бытовой техники, основан на графической библиотеке. Не бог весть что, но не ОЧЕНЬ простое.

Практически каждый раз пишу под каждый LCD процедуры вывода, поскольку каждый LCD очень отличается от предыдущего. Практически везде использую поддержку окон, она, конечно, стандартная и написана только на assemblere. Последние попытки использовать предлагаемые библиотеки закончились тем, что вывод символов, конечно же разной ширины, выглядил как прин на "васике", хоте нет наш "васик" примерно в 10-ть раз быстрее. Короче скорость просто ужасная и подходит для отображения каких-нибудь крайне статических изображений. Мало того, я постоянно занимаюсь тем, что подрабатываю на фирмах где меня просят ускорить вывод информации на LCD'шки. Вот на следующей неделе еду делать работу для компании Квазар-Микро, которая выставляется на выставке на стендах. Их программисты не могут на 25 мипсовм "интеле51" сделать нормальную анимацию. Я же программирую только на асме, скорорсть разработки, конечно не лучшая, примерно неделя для любой задачи с переферией(а значит и LCD), а остальное это уже мелочи, которые долизываются по ходу дела. В последний раз делал прибор месяц тому назад с LCD 240х128 (epson), за день был написан полностью модул графики со всеми окошками, шрифтиками и другой мелочью. Поэтому не вижу смысла писать на Си, только тратить время на поиск, - "а почему же это всё так тормозит..." ...

[Vitamin]

Немного оффтопа, но с рациональным зерном

Практически каждый раз пишу под каждый LCD процедуры вывода, поскольку каждый LCD очень отличается от предыдущего.

Я для себя выбрал другой подход. Библиотека заточена под работу с дисплеями 128х64 (8 строк по 128 байт, пиксели вертикально). Но благодаря буферу позволяет работать с дисплеями с любой(!) организацией растра (успешно работал на многстраничном дисплее с "растровой" организацией). Естественно, тормознее (перекидывание буфера целиком на экран), но зато "все внутри".
Ну и библиотека пользовательского интерфейса. К ней в комплекте программа-конструктор и конвертер в С.

Практически везде использую поддержку окон, она, конечно, стандартная и написана только на assemblere.

И путем каких манипуляций ты ее портируешь на другие процессоры? Переписывание?

Последние попытки использовать предлагаемые библиотеки закончились тем, что вывод символов, конечно же разной ширины, выглядил как прин на "васике", хоте нет наш "васик" примерно в 10-ть раз быстрее.

Вышеупомянутый 8051 на 1мгц запечатывает весь экран (с прямой отрисовкой в дисплей) примерно за 0.4с. Это с пропорциональной печатью с обработкой (особенно трудно реализовывать наклонный шрифт в силу структуры).

Их программисты не могут на 25 мипсовм "интеле51" сделать нормальную анимацию.

Мдя Помнится ради хохмы написал прогу под 470 (48 мипс вроде, но не уверен), которая по последовательному каналу принимала кадры изображения, распаковывала их в реалтайме на экран. А другая прога на компе из авишника конвертила и слала. До 25фпс выдавало при размере кадра в 1к, сжатие в 1.5...3 раза получалось. Все ограничивалось скоростью порта- до 200кбит только выжимал (далее конвертер не позволял). Надо будет ради прикола попробовать эту же фишку на 8051...

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

У меня в боекомплекте периферия- 6 счетных каналов (16-разрядные счетчики импульсов), жк-дисплей (символьный, с тупой организацией), лсд-матрица (примитив...), последовательный порт, плюс внутри математика. И все это на одном 8051 и на С. Прога писалась очень долго, ассемблерный вариант уже почти неуправляем (постоянные доделки-переделки), сейчас переписываю на С.
Второй вариант отличается графическим ЖК, 8 счетными каналами, 2 последовательными портами. Проц тот же самый, прога изначально писалась на С, благодаря чему доработка относительно проста.

Поэтому не вижу смысла писать на Си, только тратить время на поиск, - "а почему же это всё так тормозит..."

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

[SfS]

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

Целиком и полностью согласен. Это некий "юношеский комплекс" - писать все на АСМе... Причем нисколько не обоснованный. Как показала практика и опыт - продумывание алгоритма и распределение по приоритетам задач - гораздо более эффективный способ сделать, "чтобы не тормозило", чем переписывание всего на АСМе. Куски на асме - другое дело (например в обработчиках очень критичных ко времени прерываний). Но все на асме - изврат

[maximk]

Хочется посмотреть асм на выходе.

Я смотрел. Фигня. Но дело в другом. Чем с нуля писать кодогенератор под монстрообразный gcc можно попробовать (если конечно есть желание, а ведь именно об этом шла речь ) _оптимизировать_ уже существующий back-end из ACK.