Хорошо. Беру слова назад. С + ассемблер, но по крайней мере до 20-30 МГц -- с уклоном в сторону последнего, т.е. после переноса и до окончательной сборки, конечно.
Хорошо. Беру слова назад. С + ассемблер, но по крайней мере до 20-30 МГц -- с уклоном в сторону последнего, т.е. после переноса и до окончательной сборки, конечно.
Помни. Только на компьютере можно семь раз Cut, а один - Format. В реале все иначе. (c)
Власть людей сильнее, чем люди у власти.
Чем меньше мы смотрим на мир, тем больше задумываемся о нем. (c)
Скрытый текст
Can you help Robin in his quest for the silver arrow? (c) Odin "Robin of the Wood"
Мы все немного режем по дереву, а потом собираем корабли в бутылках.
Is it the same old story you are going to tell me
or is it the old story telling me and you we are the same?
http://www.sky.od.ua/~ptsk[свернуть]
8051@1Мгц вполне терпимо исполняет код, собранный из С. И это с учетом одного-единственного 16-разрядного регистра. Для спека должно быть получше...Сообщение от TomCaT
Кто-нибудь находил версию GCC для зетника? А то перерыл дофига ссылок- одни огрызки информации, ни сорцов ни бинарника. А то была б маза собрать его же исходники для спека Ибо писать с нуля- весьма ресурсозатратно...
Та же фигня. Но есть открытый компилятор из ACK, причем его можно оптимизировать. Имхо, эта задача на порядок проще, чем писать back-end к gcc.Сообщение от Vitamin
Подробнее можно? Не слышал о таком чтото...Сообщение от maximk
Гм... Иногда проще написать заново, нежели переделывать уже написанноСообщение от maximk
ACK = Amsterdam Compiler Kit.Сообщение от Vitamin
http://tack.sourceforge.net/
Целый пакет из средств разработки. Компилятор C, как и другие (еще поддерживаются несколько языков) производит промежуточный код, а back-end'ы из него создают код для целевой платформы. Причем, как транслировать промежуточный байт-код в реальный описывается на специальном языке. И соответствующее описание для генерации кода z80 уже есть! Но, как и сказано в доке, оно не оптимально, ибо за основу был взят вариант от i8080.
Последний раз редактировалось maximk; 14.11.2006 в 22:26.
Почитал, завтра скачаю и попробую под никсами собрать и попрогонять. Хочется посмотреть асм на выходе. Ибо все существующие кросс-компилеры такую хрень городят... Разве что IAR по слухам весьма достойно себя ведет (надо достать попробовать).Сообщение от maximk
Практически каждый раз пишу под каждый LCD процедуры вывода, поскольку каждый LCD очень отличается от предыдущего. Практически везде использую поддержку окон, она, конечно, стандартная и написана только на assemblere. Последние попытки использовать предлагаемые библиотеки закончились тем, что вывод символов, конечно же разной ширины, выглядил как прин на "васике", хоте нет наш "васик" примерно в 10-ть раз быстрее. Короче скорость просто ужасная и подходит для отображения каких-нибудь крайне статических изображений. Мало того, я постоянно занимаюсь тем, что подрабатываю на фирмах где меня просят ускорить вывод информации на LCD'шки. Вот на следующей неделе еду делать работу для компании Квазар-Микро, которая выставляется на выставке на стендах. Их программисты не могут на 25 мипсовм "интеле51" сделать нормальную анимацию. Я же программирую только на асме, скорорсть разработки, конечно не лучшая, примерно неделя для любой задачи с переферией(а значит и LCD), а остальное это уже мелочи, которые долизываются по ходу дела. В последний раз делал прибор месяц тому назад с LCD 240х128 (epson), за день был написан полностью модул графики со всеми окошками, шрифтиками и другой мелочью. Поэтому не вижу смысла писать на Си, только тратить время на поиск, - "а почему же это всё так тормозит..." ...Сообщение от Vitamin
AAA когда меня режут, я терплю, но когда дополняют, становится нестерпимо.
Немного оффтопа, но с рациональным зерном
Я для себя выбрал другой подход. Библиотека заточена под работу с дисплеями 128х64 (8 строк по 128 байт, пиксели вертикально). Но благодаря буферу позволяет работать с дисплеями с любой(!) организацией растра (успешно работал на многстраничном дисплее с "растровой" организацией). Естественно, тормознее (перекидывание буфера целиком на экран), но зато "все внутри".Сообщение от Robus
Ну и библиотека пользовательского интерфейса. К ней в комплекте программа-конструктор и конвертер в С.
И путем каких манипуляций ты ее портируешь на другие процессоры? Переписывание?Сообщение от Robus
Вышеупомянутый 8051 на 1мгц запечатывает весь экран (с прямой отрисовкой в дисплей) примерно за 0.4с. Это с пропорциональной печатью с обработкой (особенно трудно реализовывать наклонный шрифт в силу структуры).Сообщение от Robus
Мдя Помнится ради хохмы написал прогу под 470 (48 мипс вроде, но не уверен), которая по последовательному каналу принимала кадры изображения, распаковывала их в реалтайме на экран. А другая прога на компе из авишника конвертила и слала. До 25фпс выдавало при размере кадра в 1к, сжатие в 1.5...3 раза получалось. Все ограничивалось скоростью порта- до 200кбит только выжимал (далее конвертер не позволял). Надо будет ради прикола попробовать эту же фишку на 8051...Сообщение от Robus
У меня в боекомплекте периферия- 6 счетных каналов (16-разрядные счетчики импульсов), жк-дисплей (символьный, с тупой организацией), лсд-матрица (примитив...), последовательный порт, плюс внутри математика. И все это на одном 8051 и на С. Прога писалась очень долго, ассемблерный вариант уже почти неуправляем (постоянные доделки-переделки), сейчас переписываю на С.Сообщение от Robus
Второй вариант отличается графическим ЖК, 8 счетными каналами, 2 последовательными портами. Проц тот же самый, прога изначально писалась на С, благодаря чему доработка относительно проста.
А что тратить время? Надо включать логику! В основном цикле программы разные не критичные ко времени процессы (пользовательский интерфейс, пост-обработка данных, печать в буферы и т.п.), а прием данных и предварительная обработка на прерываниях. Ставишь контроль-точки установки/сброса уровней между блоками подпрограммы-обработчика и смотришь на осциллографе кто и сколько чего жрет. А потом уже переписываешь критичные участки на асме. Ну и плюс чисто алгоритмическая оптимизация.Сообщение от Robus
Последний раз редактировалось Vitamin; 15.11.2006 в 00:43.
Целиком и полностью согласен. Это некий "юношеский комплекс" - писать все на АСМе... Причем нисколько не обоснованный. Как показала практика и опыт - продумывание алгоритма и распределение по приоритетам задач - гораздо более эффективный способ сделать, "чтобы не тормозило", чем переписывание всего на АСМе. Куски на асме - другое дело (например в обработчиках очень критичных ко времени прерываний). Но все на асме - извратСообщение от Vitamin
Я смотрел. Фигня. Но дело в другом. Чем с нуля писать кодогенератор под монстрообразный gcc можно попробовать (если конечно есть желание, а ведь именно об этом шла речь ) _оптимизировать_ уже существующий back-end из ACK.Сообщение от Vitamin
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)