А какие языки программирования были реализованы на спеке?
Насколько я помню несколько басиков, си, паскаль... что ещё?
Вид для печати
А какие языки программирования были реализованы на спеке?
Насколько я помню несколько басиков, си, паскаль... что ещё?
кучка васиковЦитата:
Сообщение от BlackWolf
паскаль
си
лого
пролог
форт
больше вроде не было ничего
Есть несколько версий Forth, в том числе и дисковая, TAP версия Prolog, TAP версия Lisp.Цитата:
Сообщение от BlackWolf
А какие были вариации на тему бейсика?
мегабейсик, бетабейсик, лазербейсик, ну и компиляторы со стандартного бейсика типа бластаЦитата:
Сообщение от BlackWolf
а пролог на самом деле был микропрологом с другим синтаксисом и сильно примитивнее
Хотя серьезно подходить к программированию все равно можно только на машкодах без макросов и процедур. :)
Ну, а серьезно -- хотя бы асм без макросов.
Типа "суровые сибирские мужыки пишут только на машинных кодах сразу в шестнадцатеричном дампе"? Обоснуй плз свое заявление, потому что я на своем личном опыте убедился, что наиболее эффективное программирование именно на С (для встроенных систем).Цитата:
Сообщение от TomCaT
Имхо наоборот- макросы позволяют хоть как-то приблизить асм к уровню ЯВУ. Как говорится, на безрыбье...Цитата:
Сообщение от TomCaT
И замедлить прогу
Изучая сейчас цэ после паскаля соглашусь, что он совсем не плох. Но никакие доводы не отберут пальму с кокосами у асма. Уж извините, можно и с ирландцем по-английски говорить, но как правило ирландский ему попонятней...
Все зависит от поставленной задачи, если надо костьми лечь но обеспечить быстродействие тогда тока "в машинных кодах сразу в шестнадцатеричном дампе" если задача за разумные сроки сделать приложение отвечающие по скорости и трудозатратам изначальным условиям почему бы не использовать отвечающие заданным критериям доступные инструменты : макросы, яву и т.д.?
Сколько проектов заморожено-развалилось из-за сложностей реализации в разрезе трудозатрат? Почему бы их не уменьшить (трудозатраты) если это можно сделать? :mad:
О сколько нам открытий чудных....Цитата:
Сообщение от TomCaT
А как быть с доводами скорости и удобства разработки? Так что насчет "никаких доводов" будем считать что ты погорячился.Цитата:
Сообщение от TomCaT
Не надо аналогий. Они никогда полностью не отражают обсуждаемую ситуацию.Цитата:
Сообщение от TomCaT
Расскажи пожалста, каким это образом макросы могут замедлить прогу? Или злобный ассемблер при развороте макроса после каждой команды halt вставляет? :)Цитата:
Сообщение от TomCaT
Я тоже когда-то бегал и махал флагом "асм рулит, С для ленивых". Но после того как пришлось сначала разбираться, а потом переделывать чужую программу на асме (микроконтроллер 8051, довольно примитивно), я слегка поменял свое мнение. Плюс к тому, С обеспечивает кроссплатформенность- пара моих библиотек без проблем была опробована на трех разных процессорах (8051, TMS430, TMS470). Сколько бы я писал их вручную?Цитата:
Сообщение от TomCaT
Так что для промышленного программирования лучше С пока ничего не придумали. И если очень уж требуется быстродействие, ассемблерные вставки никто не отменял.
(для справки- изучаю асм спека уже 7 лет, С/С++ уже 5 лет, плюс еще парочка асмов, полузабытый паскаль/делфи и т.д.)
ЗЫ. Все-таки на спеке не хватает С с приличной средой разработки...
На любом языке можно написать гадость, но на С не возможно написать оттактированую во времянках програму. Хотя можно пойти корявым способом и навесить всё на таймера, ну тогда програмирование будет ограниченным.Цитата:
Сообщение от Vitamin
Наверное это что-то очень простое. Практически всё время нужно писать под процессор новые процедуры. Особенно если у тебя всего 128 байт памяти из которых для исполнения задачи нужно 128. Я хочу посмотреть как на СИ будет рашаться эта проблема ? Сколько я не видел фирмв с инициативами писать для МК на СИ, они постоянно занимаются поиском дорогих МК для решения серьёзных задач. Типичная гигантомания в стиле виндовсовских программ, года "весь пар уходит на гудок" ... =)Цитата:
Сообщение от Vitamin
Все зависит от дискретизации тактирования. Для периодов в миллисекунды и выше таймер как раз то самое средство. А если надо меньше- то тут, конечно, ассемблер.Цитата:
Сообщение от Robus
Графическая библиотека для монохромных жк-дисплеев- всякие линии, точки, пропорциональная печать со стилями, работа с изображениями, буферизация, аппаратная независимость от реализации (работало даже на подключаемом через последовательный канал дисплее). Вторая библиотека- пользовательский интерфейс в стиле меню для бытовой техники, основан на графической библиотеке. Не бог весть что, но не ОЧЕНЬ простое.Цитата:
Сообщение от Robus
А если у тебя куча устройств, множество источников прерывания, дофига разных таймеров. Я хочу посмотреть как на ассемблере будет решаться эта проблема, и, самое главное, сколько времени будет писаться эта программа.Цитата:
Сообщение от Robus
Скажу по секрету, мощный буржуйский микропроцессор стоит дешевле наших слабеньких монстров (зато с 5 приемкой....), при этом ему не требуется большей части обвязки, да и по настройке и надержности он гораздо легче. А дорого-дешево- это все относительно, сэкономишь на процике- потеряешь на написании программы.Цитата:
Сообщение от Robus
Бывает, соглашусь. Когда вместо PIC ставят навороченный процик "чтоб было" :)Цитата:
Сообщение от Robus
еще есть довод - "переносимость" или "портирование"...доводку на асме, если использовался качественный компилятор, тоже никто не запрещает...Цитата:
Сообщение от TomCaT
у нас в фирме ставят из-за того, что у заказчиков софт под QNX...а наши делают для них железо, драйверы и тесты...на PIC же QNX пока вроде не портировано...хотя и pic PICу рознь...последние пики очень так навороченные :)Цитата:
Сообщение от Vitamin
если брать современное железо, то хороший оптимизирующий компилятор c/c++ делает код быстрее чем средний программер на асме.Цитата:
Сообщение от TomCaT
не, я не про такую ситуацию, а именно про "шоб было" %)Цитата:
Сообщение от andrews
ага. а еще б я настоятельно посоветовал пописать на асме под АРМ :)))Цитата:
Сообщение от elf/2
+1Цитата:
Сообщение от Vitamin
зато на GB есть...через 5 минут как я энтот компилятор себе поставил уже гонял какую-то демку на эмуле...как приятно все ж найти заброшенный, но пользованный миллионами юсерами предмет который безукоризненно работает :)
для GameBoy? так это ж кросскомпилятор, работающий на "больших" машинах, такого и для спектрума понаписано достаточно (z88dk, SDCC)Цитата:
Сообщение от andrews
а еще, к слову, есть ACK -- кросскомпилятор с C,pascal,fortran,modula,occam и васика.
но вот на zx -- только hisoft C :(
Напишите...пока такого вроде нет с нормальными графическими и звуковыми библиотеками и поддержкой железа.
Хорошо. Беру слова назад. С + ассемблер, но по крайней мере до 20-30 МГц -- с уклоном в сторону последнего, т.е. после переноса и до окончательной сборки, конечно.
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.
Почитал, завтра скачаю и попробую под никсами собрать и попрогонять. Хочется посмотреть асм на выходе. Ибо все существующие кросс-компилеры такую хрень городят... Разве что IAR по слухам весьма достойно себя ведет (надо достать попробовать).Цитата:
Сообщение от maximk
Практически каждый раз пишу под каждый LCD процедуры вывода, поскольку каждый LCD очень отличается от предыдущего. Практически везде использую поддержку окон, она, конечно, стандартная и написана только на assemblere. Последние попытки использовать предлагаемые библиотеки закончились тем, что вывод символов, конечно же разной ширины, выглядил как прин на "васике", хоте нет наш "васик" примерно в 10-ть раз быстрее. Короче скорость просто ужасная и подходит для отображения каких-нибудь крайне статических изображений. Мало того, я постоянно занимаюсь тем, что подрабатываю на фирмах где меня просят ускорить вывод информации на LCD'шки. Вот на следующей неделе еду делать работу для компании Квазар-Микро, которая выставляется на выставке на стендах. Их программисты не могут на 25 мипсовм "интеле51" сделать нормальную анимацию. Я же программирую только на асме, скорорсть разработки, конечно не лучшая, примерно неделя для любой задачи с переферией(а значит и LCD), а остальное это уже мелочи, которые долизываются по ходу дела. В последний раз делал прибор месяц тому назад с LCD 240х128 (epson), за день был написан полностью модул графики со всеми окошками, шрифтиками и другой мелочью. Поэтому не вижу смысла писать на Си, только тратить время на поиск, - "а почему же это всё так тормозит..." ...Цитата:
Сообщение от Vitamin
Немного оффтопа, но с рациональным зерном
Я для себя выбрал другой подход. Библиотека заточена под работу с дисплеями 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
Я смотрел. Фигня. Но дело в другом. Чем с нуля писать кодогенератор под монстрообразный gcc можно попробовать (если конечно есть желание, а ведь именно об этом шла речь :) ) _оптимизировать_ уже существующий back-end из ACK.Цитата:
Сообщение от Vitamin
Медленно но верно, я тоже пришел к такому выводу :) Особенно если приходится переделывать чей-то код- на сях бывает достаточно отформатировать исходник чтобы понять что к чему. А вот на асме обычно надо глубоко разбираться...Цитата:
Сообщение от SfS
Я просто видел одну реализацию компилятора на С. Сделано все влоб, продвинутые грамматические разборы не применяются (подозреваю что и стандарт не полностью соблюдается и оптимизация слабоватая), но зато все относительно ясно и понятно.Цитата:
Сообщение от maximk
А весёленькие эти "The Ten Commandments for C Programmers" у АСК'ного lint =)
А эффективный С для спеки скорее всего будет далёк отстандарта,тк наверняка придётся много делать руками: и типы вызовов прописывать и со стеком извращаться и код ORG'ами рассовывать...
++
"ACK has received minimalmaintenance for the best part of a decade. During that time, the Unix world has moved on", "the ACK is not C99 compatible" ещё бы, 10 лет ему... стоит ли вообще возиться?
++
Жгут: "User options - How to make lint shut up".
У АСК походу дела внутрях стековая машина ЕМ, будет ли это хорошо для Z80?
Альтернатив не видно. Если кому-то хочется сделать лучше, чем в z88dk или sdcc, то, имхо, лучше всего начать с ACK. Что проще: ковырять исходники всего компилятора (как вариант - писать вообще с нуля :) ) или написать нормальный конвертер из EM в код Z80, пусть даже для этого придется выкинуть штатный кодогенератор.Цитата:
Сообщение от NovaStorm
10 лет это пустяки :) Сколько там некоторым местам кода ядер BSD или древних гнушных утилит? :)
C99 для спека и нафик не нужен. Имхо, если бы даже был Small C (подмножество т.е.) , но генерил мега-код - это был бы реальный рулез. Что с того, что sdcc ANSI-compliant?
И еще: лично мне больше всего понравился LCC. Хоть он и написан для RISC-машин, но я думаю, можно было бы приспобосить и для z80. Но там с доками глухо... Исходники есть, но не с самодокументированным кодом :)
Писать back-end для EM почти бесперспективно. Может лучше в сторону www.cminusminus.org податься, там хотя бы серьёзные дядьки работают, работы конечно там будет скорее всего больше, но и результат себя должен будет оправдать.
++
блин, этих С--, как собак... но смысл я думаю понятен - попытаться попользовать более поддерживаемый кодогенератор.
++
Можно небольшое how-to по ACK? скомпилил, проверил... Вроде что-то делает, но на z80 код это ну совсем не похоже =)
Если говорить о z80 вообще, то под CP/M есть много всяких языков - покопайтесь на файловых хранилищах.
Документация на один из компиляторов Modula-2 (freeware c 2002 года):
http://www.hartetechnologies.com/manuals/Modula2/
Хехе. Я тут недавно сравнивал: распоследний SDCC генерит с одного и того же исходника вдвое более объемный код, чем CP/M Hitec C однатысячадевятьсотмохнат ого годаЦитата:
Сообщение от maximk
Да вообще нужно хотябы один более-менее похожий на C язык с изначальной поддержкой нормальных типов данных (32bit integer, float)Цитата:
Сообщение от maximk
Но их нет! Все недоделанные, либо генерят монструозный код, либо ни с чем не совместимы кроме как сами с собой.
Вот ещё нагуглилось:
http://www.softools.com/scz180.htm
http://www.ticalc.org/pub/text/z80/
Да уж, под CP/M есть вот например что http://www.bdsoft.com/resources/bdsc.html, но исходник на асме 8080 =(
А Small C кто-нибудь собирал?
++
Ага! Ситуация проясняется... Z88DK это потомок от Small C.
Гляжу теперь AnyC.
Надо бы FAQ сделать прилепленный, чтоб не лазить толпой...
bdsc генерит код для i8080. Код относительно нормальный, но с hisoft уже не сравнить, а то, что он не для z80 делает его малопригодным...
я собирал...это самое простое, но нужны хорошие графические и прочие библиотеки( в частности работающие со специфическим железом спектрумов)Цитата:
Сообщение от NovaStorm