Просмотр полной версии : Хочу писать программы для ретрокомпьютеров
Добрый день всем присутствующим. Вопрос немного не по теме, но я вижу, что тут много знающих людей, которые могут подсказать.
Я студент старших курсов и прилично разбираюсь в C, C++ и OpenGL. Помогут ли мне эти знания, если я хочу писать игры для ретро компьютеров? Или там требуются знания basic и ассемблера? Может все-таки есть какие-то компьютеры, для которых существуют кросс-компиляторы? Если все-таки требуются знания basic и ассемблера, то какие компьютеры (желательно отечественные) документированы лучше всего, чтобы было проще начать.
Конечно надо брать ассемблер и писать для БК0011М. Там полно документации, примеров и широкое поле для творчества :)
прилично разбираюсь в C, C++ и OpenGL. Помогут ли мне эти знания, если я хочу писать игры для ретро компьютеров?
Начать наверно проще с кросс-компилятора z88dk (https://github.com/z88dk/z88dk/wiki), который поддерживает кучу целевых платформ (https://github.com/z88dk/z88dk/wiki/Platform). Он не идеален, но программы при желании можно писать. А потом уже будет видно, что делать дальше.
Для начала лучше всё-таки БК0010. Она проще.
CityAceE
16.03.2022, 11:33
Может все-таки есть какие-то компьютеры, для которых существуют кросс-компиляторы?
Основная проблема ретро-компьютеров - это недостаток ресурсов (малый объём памяти и медленные процессоры). Именно поэтому все пишется на максимально низкоуровневом языке (ассемблере), так как ни один компилятор для ретро-платформ не сможет обеспечить такое же быстродействие и компактность кода, как это сделает программист на ассемблере.
Из отечественных, как уже писали - БК0010. Из импортных, как нетрудно догадаться - ZX Spectrum 48/128.
Бейсик на них использовать можно, но для несложных и не требующих динамичной графики игр.
Полноценные игры - только ассемблер. После Си его изучение не должно вызвать проблем, тем более на таких машинах.
С точки зрения человека, начинавшего со Спектрума, его ассемблер понятней. БКашники не согласятся =)
Советую обратить внимание на PDP8 - (аналоги в СССР Саратов-2 и Электроника-100). Там UNIX и компилятор C. Эмуляторы и ассемблеры тоже есть, причем и в исходниках. В России на них мало кто обращает внимание. Поэтому есть возможность сразу "засиять на небосклоне" и быть цитируемым в интернете. Ну а ряд аналогов PDP-11 представлен широко и специалистов в советские времена были сотни тысяч человек. Если думаете о трудоустройстве, то тогда надо выбирать конечно PDP-11.
- - - Добавлено - - -
С точки зрения человека, начинавшего со Спектрума, его ассемблер понятней
поскольку он, z80 CISC, то весьма сложен для начинающего. Огромное количество "недокументированных команд". С ассемблером PDP-8 (или PIC-12)не сравнить!
- - - Добавлено - - -
как это сделает программист на ассемблере.
хороший программист на ассемблере.
Большое спасибо всем за ответы! Постараюсь резюмировать информацию для себя и для тех, кому это тоже может быть интересно.
Существует кросс-компилятор z88dk, который компилирует код на языке C для процессоров I8080 и Z80 и поддерживает особенности ряда популярных компьютеров для работы с графикой и звуком. Но, как я понял, этот проект все еще активно развивается, и почти все компьютеры поддерживаются не в полной мере. Плюс скорее всего данный компилятор работает не совсем оптимально при адаптации кода под конкретную платформу.
Если хочется писать быстрый код и использовать все возможности машины, придется писать код на ассемблере. Из западных компьютеров популярней и доступней всего ZX Spectrum, а из отечественных компьютеры серии БК. Еще есть более редкие машины на архитектуре PDP-8, но скорее всего будет сложно найти рабочие экземпляры этих машин, а ведь хочется запустить свой код на реальном железе.
Лично для меня интересней было бы попробовать БК, тем более, что в интернете быстро нашлись две книги с подробным описанием программирования под БК 0010 и 0011. Оставлю тут ссылки на них. Еще оставлю ссылку на статью на Хабре, где помимо всего прочего описывается новый удобный кросс ассемблер для БК
http://gid.pdp-11.ru/books/Zaltsman.html
http://gid.pdp-11.ru/books/00015-01.32.01.html
https://habr.com/ru/post/469117/
Поправьте меня, если что-то не так понял
Не хватает ссылки на шикарный эмулятор всех конфигураций БК: http://gid.pdp-11.ru/
он, z80 CISC, то весьма сложен для начинающего. Огромное количество "недокументированных команд"
Насчет огромного количества, это, конечно, преувеличение. А с точки зрения человека именно ассемблерные записи Z80 выглядят куда понятней, чем для PDP11.
С его кучей способов адресации и восьмеричной записью чисел, нигде, кроме PDP, не применяющейся. 10-тичную и 16-ричную любой программист поймет, они везде есть.
Поправьте меня, если что-то не так понял
Все понятно правильно. Добавлю лишь, что недостаточно выучить ассемблер такого-то процессора, придется изучать железные особенности конкретной машины.
Потому как везде разное строение экрана (работа с экранами), порты ввода-вывода и прочие тонкости, без которых полноценное написание игр невозможно.
Соответственно, работа со звуком, с клавиатурой, загрузка-сохранение данных на каждой конкретной машине будут свои, даже если процессор одинаковый.
Имеются в виду разные компьютеры, построенные на одном процессоре: ZX Spectrum, Amstrad, MSX и так далее.
С его кучей способов адресации
Часто позволяющей одной командой сделать то, на что на других процах (включая Z80) уйдёт несколько...
Lethargeek
16.03.2022, 14:03
Часто позволяющей одной командой сделать то, на что на других процах (включая Z80) уйдёт несколько...
...только часто медленнее, чем на спеке выполняются эти несколько, даже если есть практическая польза от той команды
"Опять! Ну, теперь стало быть, пошло, пропал калабуховский дом." (с) Собачье сердце
одной командой сделать то, на что на других процах (включая Z80) уйдёт несколько...
Это да, но после простых и понятных записей асма Z80 команды вида MOV 2000(Rx),@#ADR заставляют поднапрячь мозги =)
Особенно если до этого никогда таких адресаций не видел. Тут минимум неделю лазишь в справочник, чтоб не запутаться.
При переходе с высокоуровневого языка оно, конечно, лучше: не нужно расписывать кучу команд для нужного действия.
Уже упомянутый спорный момент о том, какой код в итоге будет быстрее, для начального освоения асма считаю второстепенным.
Но именно на ретрокомпьютерах стоит все же учитывать все нюансы, вплоть до объема программы в (кило)байтах и времени исполнения кода.
Это так, для "широких масс", возможно, читающих данный топик в будущем. Не ленитесь сравнивать и проверять разные варианты кода.
команды вида MOV 2000(Rx),@#ADR заставляют поднапрячь мозги =)
Мне уже достаточно давно интересно - с каких времен необходимость - поднапрячь мозги - у программистов стала вызывать такое неприятие?
И что, на этапе освоения
минимум неделю лазишь в справочник, чтоб не запутаться
это прям такой неподъёмный срок?
И я просто молчу, сколько по времени надо лазить в справочник при освоение x86 даже в варианте 8086/8088.
А так же вспоминаю, что в своё время пришлось выписать ВСЕ варианты допустимого использования в командах регистров на 8080
Ну и для разминки мозгов - кусок кода, написанный на языке MACRO-11
;
; R2 R3
;
PROCEDURE CNV
BEGIN
LET R0 := #BUF
THRU R4 := #EBUF-BUF
LET (R0)+ :B= #SPACE
END
LET -(SP) := #4
LOOP
LET R4 := #0
LET R5 := #0
LOOP
IF R2 EQ #0 AND R3 LO R1 LEAVE LOOP
ADD #1, R5
ADC R4
SUB R1, R3
SBC R2
END
LET (SP) := (SP) - #1
IF RESULT IS EQ THEN
LET -(R0) :B= #SPACE
LET (SP) := #3
END
LET -(R0) :B= R3
LET (R0) :B= (R0) SET.BY #'0
LET R2 := R4
LET R3 := R5
IF R2 EQ #0 AND R3 EQ #0 LEAVE LOOP
END
POP
RETURN
END CNV
Честно говоря - надо бы его переписать - ибо жутко медленный, но пока не парит :)
Это да, но после простых и понятных записей асма Z80 команды вида MOV 2000(Rx),@#ADR заставляют поднапрячь мозги =)
Особенно если до этого никогда таких адресаций не видел. Тут минимум неделю лазишь в справочник, чтоб не запутаться.
Ну не знаю. По мне всё просто и понятно, запутываться просто негде. Особенно, если знаешь, как эти команды кодируются. Это на Z80 надо запоминать, почему нельзя сделать LD IX, HL, и надо перепихивать через стек.
А вообще, если кто хочет действительно крышесносящего ассемблера, то вот вам PIC:
MOVLW 2H
MOVWF 3H
MOVLW 4H
ADDWF 3H, 0
Что делает эта программа?
В регистр W заносится число 6. В регистре STATUS устанавливаются флаги Z и DC.
Но, наверное, что-то еще происходит, да ?
Ну МАКРО это не аргумент! Понятно, что на МАКРО любой начинающий без напряга напишет, особенно имея под рукой примеры.
А вообще любой язык, язык программирования в том числе, для освоения требует практики. Аргумент против восьмеричной системы это не аргумент! Это ж не 32-ричная и не двоичная системы. И не китайский язык!
По поводу желания запускать программы на реальном железе это конечно похвально, только требует немалых финансовых затрат.
Воспроизводить то же PDP-8 на транзисторах с ферритовой памятью в единичном экземпляре тут даже миллиона долларов не хватит. Да и смысл? Разве что в музее где-то сидеть за пишущей машинкой Консул, привлекая внимание публики, любящей острые ощущения. Набивать перфокарты и вводить код с них есть желающие?
Kakos_nonos
16.03.2022, 19:32
Также можно писать для радио-86рк совместимых компьютеров. Они достаточно просто устроены, и ассемблер простой. А потом перейти уже на z80, потому что z80 это расширенная версия 8080.
Oleg N. Cher
16.03.2022, 19:58
Помогут ли мне эти знания, если я хочу писать игры для ретро компьютеров? Или там требуются знания basic и ассемблера? Может все-таки есть какие-то компьютеры, для которых существуют кросс-компиляторы?Даже независимо от юзаемой ретро-платформы я рекомендую использовать именно кросс-компиляторы и писать на Си со встроенным асмом. Какие-то зачатки асма всё равно понадобятся, это будет неплохой старт в асм, а уверенно писать на асме целиком Вы сможете не раньше, чем через год или несколько. И то в случае почти ежедневной практики. Я знаю 8080 и Z80 довольно хорошо, но на PDP-11 до сих пор пишу очень неуверенно.
Итак. Для PDP-11 есть порт GCC (MINGW). Там, правда, есть некоторые трудности, но уж что поделать, привыкайте, это ретро.
https://www.1801bm1.com/files/pdp11/cross-compilers/
Для Z80 лучше всего взять SDCC: http://sdcc.sourceforge.net
Для 8080 берём z88dk: https://z88dk.org
По тонкостям всех этих компиляторов есть гуры. Лучше всего иметь такого гуру под боком, чтобы задавать ему тонну глупых вопросов.
Да, кстати, я освоил все эти компили и использую их в качестве бэк-эндов при написании программ для ретро-платформ на Обероне (через трансляцию в Си).
Почему я сразу говорю про гур. Потому что кроме компиляторов понадобятся утилиты, библиотеки, подпрограммы на ассемблере, приёмы их стыковки к Си-коду. И да, не слушайте "ассемблерщиков". Это профи, они хотят выжимать из ретро-машинок их максимум. Ваша же задача другая - вообще понять что к чему и сделать хоть что-то. А там дальше талант-упорство-мотивация покажут. Может вообще не понравится, слишком заморочливо.
shattered
16.03.2022, 21:48
есть любопытный язык cowgol, с генераторами кода для 8080, z80, итп -- https://github.com/davidgiven/cowgol
А еще для 8080 есть PLM-80, а для 8051 PLM-51, а для 8086(8088) PLM-86. Разыскать мифическую версию этого компилятора для z80 мне так и не удалось.
В свое время казалось, что ассемблер Z80 это просто и здОрово, но попробовав писать на ассемблере под БК, понимаешь, что не всё так однозначно. На мой взгляд процессор БК не очень хорошо заточен для работы с байтами в слове, а в остальном вещь достойная. И для программиста период вхождения в уверенное пользование едва ли будет больше одного-двух месяцев.
PS Шестнадцатиричное представление числа воспринимается конечно легче восьмеричного, но ведь нет запрета записывать числа в текстах ассемблера даже и в десятичном виде.
Для Z80 лучше всего взять SDCC: http://sdcc.sourceforge.net
Для 8080 берём z88dk: https://z88dk.org
Все же не стал бы так разделять/противопоставлять sdcc и z88dk. В составе z88dk два компилятора С: кастомизированный sdcc zsdcc (z80/продвинутые z80) и sccz80 (z80/8080/8085). Компилировать для z80 лучше с использованием sdcc или zsdcc, тут не спорю, но это можно делать и в рамках z88dk.
ТС, Велкам на sprinter.ru
если есть желание покодить. можно си, можно асм.
Для Z80 лучше всего взять SDCC: http://sdcc.sourceforge.net
для Z80 лучше брать IAR.
Все же не стал бы так разделять/противопоставлять sdcc и z88dk.
оба компилятора - суть одно и тоже. Корни растут из древнего Small C 2.1 (если не ошибаюсь) который тогда был распространён в виде исходников, из которых повылазили вот эти 2 товарища, и всякие MESCC и подобные.
Язык С древен по определению. IAR бесплатный имеет ограничения. А сейчас даже с ограничениями не знаю может быть скачан из России или нет. На ряд продуктов уже на этой неделе натолкнулся на ограничения в возможности скачивания без VPN.
оба компилятора - суть одно и тоже.
SDCC/ZSDCC и sccz80 сильно отличаются, сложно это не заметить, если написать (а тем более попробовать портировать готовый проект с другой платформы) хотя бы по одному проекту в каждом из них. Из small c вырос sccz80
для Z80 лучше брать IAR.
1. SDCC открытый проект, можно посмотреть исходники в случае необходимости
2. SDCC развивается, там исправляют ошибки и добавляют новые возможности
Язык С древен по определению. IAR бесплатный имеет ограничения. А сейчас даже с ограничениями не знаю может быть скачан из России или нет. А вы точно-точно в России живёте ?
На рутрэкере раздач с разными версиями IAR-а больше сорока штук.
DCC/ZSDCC и sccz80 сильно отличаются,
да ничем они не отличаются. оба являются только лишь диалектом языка си, со своими костылями и "изобретениями". sccz80 это и есть z88dk. у меня где то дома лежит чуть ли не самая первая его версия, ещё под ms-dos. думаешь он как-то отличается? кодогенерация всё так же отвратная. при этом в исходниках сказано:
sccz80 is derived from small c
что как бы тонко намекает, что это и от куда.
1. SDCC открытый проект, можно посмотреть исходники в случае необходимости
какой тебе толк от "просмотра" этих исходников? если не считать автора fuzix, то больше никто свои руки в исходники не сувал и не вносил правки для своих нужд. во всяком случае публично таких факто я найти не смог. так скажи, что для тебя наличие этих исходников?
2. SDCC развивается, там исправляют ошибки и добавляют новые возможности
да. сейчас с выходом 4.2.0 заметил небольшое отличие в кодогенерации - начал гонять регистры для передачи аргументов. похвально. НО, у меня вопрос: а почему sdas остался старым? где поддержка недокументированных команд? нету. а где активное использование всяких альтернативных наборов регистров, включая всякие ex af,af'? не замечено. IAR, хоть и abandonware, но умеет куда больше уже 20 лет к ряду.
если же говорить за Спринтер, там есть компилятор Solid C, перенесённый с MSX. так вот, компилятор 1995го года, БЕСПЛАТНЫЙ, умеет всё тоже самое, кроме лонгов. Если представить ситуацию, при которой мы пишем программу, в которой нет нужды в лонгах, IAR на пару с Solid C в нескольких местах ломают "хребет" sdcc и его напарнику z88dk.
опять же, жизненный опыт - FatFS. Собираем его при помощи SDCC и IAR, без поддержки exFAT. SDCC сливает по размеру бинара, по производительности там просто вообще, рукалицо. это даже не смешно, чесслово.
Smalovsky
17.03.2022, 10:35
А про Борель-бейсик и оберон забыли.
Smalovsky, оберон к ретро каким местом?
Smalovsky
17.03.2022, 10:40
Прямым. На обероне уже кучу игр написали.
Smalovsky, кроме того, что прямого компилятора оберона под z80 никогда не существовало. есть нагромождение из "трансляторов". с таким же успехом можно и на C# кодить под Z80, а потом транслировать (конвертить). сам понимаешь, какое там будет качество...
при этом это не отменяет того факта, что компилятора оберона под z80 как не было, так и нет (как и C#).
да и куча игр, весьма громкое заявление, как и качество самих игр.
Lethargeek
17.03.2022, 10:56
Почему я сразу говорю про гур. Потому что кроме компиляторов понадобятся утилиты, библиотеки, подпрограммы на ассемблере, приёмы их стыковки к Си-коду. И да, не слушайте "ассемблерщиков". Это профи, они хотят выжимать из ретро-машинок их максимум.
не слушайте явушников, только потеряете время, а потом всё равно придётся освоить асм, причём даже не для максимума
Ваша же задача другая - вообще понять что к чему и сделать хоть что-то.
вот как раз чтобы "понять, что к чему", и надо начинать снизу, и делать мелкое "хоть что-то" сразу на асме, нарабатывая свою кодобазу
sccz80 это и есть z88dk
В составе z88dk два компилятора С: кастомизированный sdcc zsdcc (z80/продвинутые z80) и sccz80 (z80/8080/8085)
sccz80 is derived from small c
что как бы тонко намекает, что это и от куда.
Из small c вырос sccz80
да ничем они не отличаются.
Мог бы привести конкретные примеры, чем они отличаются, но учитывая предыдущие высказывания не вижу в этом смысла.
чем они отличаются
что-то я тебя не понял. ты пишешь про sccz80, я тебе говорю, sccz80 = z88dk и ты говоришь, чем они отличаются? ни чем они не отличаются, это один и тот же компилятор. sccz80 это старое название z88dk.
и что тебе не понравилось в предыдущих высказываниях? я вполне конкретно привёл в пример FatFS, что не так? или мне тут весь листинг показывать нужно?
я тебе говорю, sccz80 = z88dk
Не вижу смысла в дальнейшем обсуждении
ivagor, тут обсуждать нечего - открой файл README.md из исходника z88dk, если мне не веришь. чёрный по белому написано:
* **SCCZ80** is z88dk's native c compiler. sccz80 is derived from small c
что не так?
* **ZSDCC** is z88dk's customization of the [sdcc compiler]
что не так?
а вот из исходника за 96й год
scc Ron Cain's Small C compiler originaly from Dr. Dobbs Journal.
- - - Добавлено - - -
оба компилятора, что sdcc, что z88dk, не способны отказаться от индексных регистров. это как пример багованности или тупости этих компиляторов.
static UINT wc, bc, t;
static DWORD fsect, tmp;
и что я вижу в листинге?
push ix
ld ix,#0
add ix,sp
ld iy, #-12
add iy, sp
ld sp, iy
и т.д. хотя static явно указывает на то, что индексы надо убрать. беру тот же код, пихаю в IAR, который вы тут так ненавидите (потому, что нужно стать капером, видите ли (я просто напоминаю, вы тут все сидите и строчите из под каперской венды, таблички пилите на каперском экселе, картинки рисуете на каперском фотошопе, а от IARа нос воротите, вам шашечки или ехать?)) и вместо IX/IY получаю быстрый код на обычных регистрах. плюс ключами компиляции я указываю компилятору - заюзать недокументированные команды, регистры и альтернативный набор регистров.
тут действительно, обсуждать нечего.
до смешного доходит, в Solid C через #pragma nonrec даже статики писать не нужно и минус индексные регистры.
банальный printf("Hello Word!"); на z88dk - 4 килобайта! на Solid C что-то около 900 байт.
придётся освоить асм
но это не значит, что получится сколько нибудь значительный проект изваять на нем. Представим себе 10 000 строк плохо структурированного и не комментированного кода. Если будет хотя бы полугодовой перерыв в работе, то и сам автор ничего с этим куском софта сделать не сможет! Чтобы делать проекты на asm-е мало освоить сам asm, надо еще правильно организовать свою работу с ним.
- - - Добавлено - - -
вы тут все сидите и строчите из под каперской вендыудаляйте и лицензионную. Я вчера пытался в свой аккаунт на Microsoft попасть, который был зареган на яndex почте сдуру. Предустановленный производителем железа MO "накрылся медным тазом" при том, что годовая проплаченная подписка еще не истекла. Скайп к счастью пока не блокируют.
удаляйте и лицензионную.
зачем удалять лицензию, если её нет? (хаха) ))) мне и так хорошо. да, и не пираты мы нынче, каперы мы;)
плохо структурированного и не комментированного кода
Так кто виноват, что кто то так написал? Язык программирования или автор кода?
- - - Добавлено - - -
вы тут все сидите и строчите из под каперской венды, таблички пилите на каперском экселе
Слишком громко сказано про ВСЕ
Язык программирования или автор кода?
так свобода же самовыражения без границ(если еще фрагменты кодом добавить без всякой мнемоники). Кстати, FORTH тут еще не упомянули.
так свобода же самовыражения без границ
То есть автор. Вот пусть и разбирается в своем "творчестве" без границ.
Oleg N. Cher
17.03.2022, 12:52
для Z80 лучше брать IAR.Лично моя претензия к IAR - невозможность повлиять на его развитие. Всё остальное проистекает из этого данного прискорбного факта. А когда начинаешь пилить серьёзный проект и привязываешься намертво к средству разработки - потом морально очень тяжело упереться в какой-то трудно преодолимый косяк, намекающий на "забудь".
компилятора оберона под z80 как не было, так и нетКакая тебе разница прямой там компиль или нет? Нативодрочер? А ты копал как, к примеру, устроен FPC или хотя бы тот же SDCC? Или LLVM. Там куча промежуточных уровней и представлений.
банальный printf("Hello Word!"); на z88dk - 4 килобайта! на Solid C что-то около 900 байт.Ну, printf для ретро не особо и нужен. И вообще это не показатель, сколько там затянула его внутренняя реализация и мало ли чего он там тянет с собой. Это не про качество кода и не про эффективность.
как и качество самих игр.Ну, дело вкуса. Тут как бы даже на качество игр на Васике не жаловались. Наоборот, прикольно. Говорю же - дрочер. Ну иди коди на асме игры на эффективном printf из Solid C ;-)
не слушайте явушников, только потеряете время, а потом всё равно придётся освоить асм, причём даже не для максимумаРазделение на явушников и ассемблерщиков условное. Я бы скорее разделил на желающих и не желающих что-то сделать для ретро. А начать с ЯВУ и получить путёвку в асм наименее болезненным способом - очень даже можно.
вот как раз чтобы "понять, что к чему", и надо начинать снизу, и делать мелкое "хоть что-то" сразу на асме, нарабатывая свою кодобазуЯ так и предлагаю, только через Си. Кто тут скажет, что на встроенном в Си асме нельзя писать?
Итак, резюме: не слушаем никого и пробуем что-то делать. Но я бы всё-таки советовал на Си. Никому нельзя верить. Мне - можно (c)
Лично моя претензия к IAR - невозможность повлиять на его развитие.
морально очень тяжело упереться в какой-то трудно преодолимый косяк, намекающий на "забудь".
принципиально таких косяков, в sdcc или iar нету. но, хотелось бы узнать, кто и как может повлиять на развитие sdcc?
снова хочу вспомнить пример про инициализацию массивов - до версии 3.0.0 sdcc прекрасно это делал. т.е. указывать размерность массива не было необходимости.
начиная с 3.0.0 и до 4.2.0 этот баг присутствует. При чём в записях issue на сайте компилятора эта проблема всплывает по много раз.
это как пример того, что ни ты и кто- то ещё не способны повлиять на развитие компилятора. там модель передачи аргументов переделывали 10 лет, а ты хочешь какие то ещё баги или хотелки, чтобы там "на лету" вносили.
конечно, что-то туда внесли (наверное). и что, от этого лучше стало? а точно без этого было никак (например, не решить через асм)?
ещё раз - нужно определится, вам шашечки или ехать. когда в качестве аргумента приводят "да он же open source", это обычно шашечки.
Какая тебе разница прямой там компиль или нет?
разница огромная. или это прямая трансляция в ассемблер (да да, сколько то проходов) или сначала транслировать в один язык, потом в другой, потом в третий... и при этом при трансляции "завезётся" ещё N багов и проблем. нет уж. нафиг надо.
или хотя бы тот же SDCC? Или LLVM.
ну да, LLVM же прям сходу нам в Z80 компилить может, ага...
ну а в sdcc да, смотрел. и в старые версии (очень старые, прям доисторические, от куда корни растут). и что?
на github вон человек декомпил HiTech выложил. тоже посмотрел. и в "исходниках" Солида смотрел (там даже кое какие правки вносил).
hiTech, к примеру, делает промежуточную трансляцию в байт-код, из него потом уже в асм, асм в объектный файл, который потом линкуется. это не одно и тоже с трансляцией из одного языка в другой (например, с объектного в линейный).
Ну, printf для ретро не особо и нужен.
да ну здорово живёшь. а в консоли как работать (если у машины есть консоль)? любая cp/m машина (профи, всякие атм, кворумы, MSX, даже Спринтер). это всё ретромашины.
пример с Hello word притянут, конечно, нет смысла ради одной строки символов пихать printf. но сути то это не меняет. в примере можно и печать хексов указать и прочее. вот и printf понадобился.
Ну, дело вкуса. Тут как бы даже на качество игр на Васике не жаловались. Наоборот, прикольно. Говорю же - дрочер.
а потом ты удивляешься, почему никто не бежит кодить пачки игорей на обероне - кому интересны "крестики нолики"? и не сравнивай игры на ZX Basic и обероновские. "это другое".
Oleg N. Cher
17.03.2022, 13:40
принципиально таких косяков, в sdcc или iar нету. но, хотелось бы узнать, кто и как может повлиять на развитие sdcc?Принципиальные косяки есть везде. Ну и да, я влиял на развитие SDCC через переписку с Филиппом Краузе, разработчиком бэк-энда Z80.
ещё раз - нужно определится, вам шашечки или ехать. когда в качестве аргумента приводят "да он же open source", это обычно шашечки.Уже обсудили, что драйвер FAT надо делать на асме. Не всем надо драйверы. Кому-то надо графические библиотеки, которые есть для SDCC, есть для z88dk, но нет для IAR. И не будет. Так шашечки или ехать? Смотря какие шашечки и смотря куда ехать. Кто-то неплохую игру сделал и на нативном компиле Васика.
сначала транслировать в один язык, потом в другой, потом в третий... и при этом при трансляции "завезётся" ещё N багов и проблем.Очень слабый аргумент. Но, по-моему, у тебя претензий к интерпретатору Васика меньше, чем к Оберону. Но мы на таких, как ты, не особо и надеемся, сами юзаем.
ну да, LLVM же прям сходу нам в Z80 компилить может, ага...Кстати, Лёша Большаков мне как-то показывал код для Z80, сгенеренный LLVM. Я очень впечатлился тем, что там рекурсия развёрнута в цикл. Охрененно круто. А вот передачи параметров без стека там походу нет.
hiTech, к примеру, делает промежуточную трансляцию в байт-код, из него потом уже в асм, асм в объектный файл, который потом линкуется. это не одно и тоже с трансляцией из одного языка в другой (например, с объектного в линейный).На это можно смотреть и как на одно и то же, просто тут промежуточным представлением выступает сам язык.
Официально заявляю, что среда XDev имеет возможность таргетить практически все ретро-платформы от калькулятора МК90 до игровых приставок NES и Sega. И это только благодаря трансляции в Си. Если бы я сел пилить бэк-энд в Z80, на что прозрачно намекает Sayman, то ZXDev был бы сейчас примерно там же, где и ZX Like Pascal.
да ну здорово живёшь. а в консоли как работать (если у машины есть консоль)? любая cp/m машина (профи, всякие атм, кворумы, MSX, даже Спринтер). это всё ретромашины.Даже в консоли не нужна такая избыточная сишная громадина, как printf с его форматтером. Можно и поскромнее выводить. Видел как устроен ввод-вывод в Модуле-2 ?
а потом ты удивляешься, почему никто не бежит кодить пачки игорей на обероне - кому интересны "крестики нолики"? и не сравнивай игры на ZX Basic и обероновские. "это другое".У тебя в мозгах это вообще другое, но кто бы сомневался. Покажи тогда нам игорей на ЯВУ, которые круче, чем асмовские.
Я не удивляюсь. Люди косны и предвзяты. Я для себя доказал, что Оберон норм тема для ретро, а ты хоть лопни - на моё положительное конструктивное мнение по поводу Оберона это никак не повлияет.
Lethargeek
17.03.2022, 13:48
Представим себе 10 000 строк плохо структурированного и не комментированного кода
а что, кто-то под дулом пистолета заставляет так код писать?
макры есть и пользуйтесь на здоровье
Чтобы делать проекты на asm-е мало освоить сам asm, надо еще правильно организовать свою работу с ним.
это надо делать с любыми средствами
- - - Добавлено - - -
Я так и предлагаю, только через Си. Кто тут скажет, что на встроенном в Си асме нельзя писать?
можно, но зачем, когда проще без? учить меньше, помнить меньше "особенностей", обусловленных слабостью платформы
Oleg N. Cher
17.03.2022, 13:51
Ну не факт, спорно всё это. Кто пишет на Си - имеет гипотетическую переносимость между платформами. И тестовую площадку. Всяко удобнее через ЯВУ тестировать и делать различные служебные вещи. А асм как бы намекает на жёсткую привязку к платформе.
Покажи тогда нам игорей на ЯВУ, которые круче, чем асмовские.
Если не спековские, то Metal Mutant. IDA в 90-е у меня об нее зубы обломал. Кто-то здесь много-много-много лет назад высказывал гипотезу, что это FORTH.
- - - Добавлено - - -
Кто пишет на Си - имеет гипотетическую переносимость между платформами.
мне вообще такие софты не встречались, это что-то на уровне ИИ уже. Самое поганое, что ни один С-компилер не может даже устранить сам ошибки, возникающие при переносе софта даже в части кода, не зависящего от конкретного железа! А ни один линкер не может с чужими make-ами разобраться. Не говоря уже о совместимости назад к старым версиям, после преобразования проекта в более новую версию. Можно сказать, что у разработчиков ЯВУ тупо не хватает на все сил и времени. И в этом смысле разработчики ассемблеров и макроассемблеров конечно имеют гигантскую фору.
- - - Добавлено - - -
А асм как бы намекает на жёсткую привязку к платформе.
потому как тоже не имеет встроенных конверторов мнемоник и даже не понимает, какой код ему подсовывают на вход. Даже те, которые имеют ключ -cpu! А им бы неплохо иметь ключи -autodetect_cpu и -board. Особенно кросс-ассемблерам, которые на мощных компах запускаются.
- - - Добавлено - - -
макры есть и пользуйтесь на здоровье
макры ты сам и должен писать! Но это то еще занятие по "простоте". У С ведь тоже макры есть.
Oleg N. Cher
17.03.2022, 15:02
кому интересны "крестики нолики"?Ну ты ж не станешь утверждать, что на Обероне возможны только крестики-нолики? Если человек, который интересуется Обероном, хочет делать именно такие игры, кто ему помешает? Но если найдётся тот, кто захочет сделать аркаду, то без проблем. Более того, подобные разработки есть, например, Bolder16K (https://github.com/Oleg-N-Cher/Bolder16K) для Спектрума 16К и Львова ПК-01. Другое дело, что доля машкодовых подпрограмм в такой игре обычно не такая маленькая, но как же без этого в ретро-разработке.
Если не спековские, то Metal Mutant. IDA в 90-е у меня об нее зубы обломал. Кто-то здесь много-много-много лет назад высказывал гипотезу, что это FORTH.Там, скорее всего, какой-то внутрифирменный байт-код. Разработчики любят такие штуки. Но чем чёрт не шутит, может и Форт.
мне вообще такие софты не встречались, это что-то на уровне ИИ уже. Самое поганое, что ни один С-компилер не может даже устранить сам ошибки, возникающие при переносе софта даже в части кода, не зависящего от конкретного железа! А ни один линкер не может с чужими make-ами разобраться. Не говоря уже о совместимости назад к старым версиям, после преобразования проекта в более новую версию. Можно сказать, что у разработчиков ЯВУ тупо не хватает на все сил и времени.А вот тут-то на первый план выходит польза от уровня Оберона. Оберон выступает объединяющим началом для всех компилей в Си - он может дать на выходе как ANSI C, так и K&R (есть соотв. опция). Проблемы со сборкой он конечно не решает, придётся разбираться с каждым отдельным компилером.
Как человек, много времени потративший на портирование игры Дурак (c) Copperfeet на самые разные ретро-платформы, могу с уверенностью сказать, что часть Оберон-кода в этой игре довольно велика. И перенос этой части между платформами сильно упрощается. Даже неизмеримо с асмом. Другое дело, что увязаешь в машинных особенностях каждой платформы. Вот именно для таких проектов и стоит это юзать. А в написании драйвера FAT у Оберона конечно нет преимуществ перед Си или, не дай бог, асмом.
скорее всего, какой-то внутрифирменный байт-код
А игра-то сразу была многоплатформенная. Если байт-код, то часть данных должна быть одна и та же на разных платформах!
В конечном счете байт-код должен где-то в теле программы выходить на исполняемый код? Как и у FORTH.
Вряд ли они этот блок раскидали по разным модулям? Какой-то кусок проги должен этот код загружать и интерпретировать, значит можно и ловушку на эту область поставить? И программный счетчик никогда на эти коды не должен попадать! В общем кажется должны быть инструменты программные. Не вручную же они эти вещи лопатили. Только непонятно по каким ключевым словам гуглить. И тем более вручную их не получится "разлопатить"
- - - Добавлено - - -
Другое дело, что увязаешь в машинных особенностях каждой платформы
вот как раз и такие инструменты отсутствуют. Хотя казалось бы чего сложного. Создаешь базу знаний по каждой железяке и скармливаешь ее подготовленного к этому дизассемблеру( ассемблеру с конвертером). Я понимаю еще, что среди коммерческого инструментария подобного софта нет( потому что дураков за это платить не нашлось), но и среди бесплатного софта (где пишут не из-за денег) тоже ничего нет?
shattered
17.03.2022, 20:47
почитайте, как устроен another world / zork / sierra agi / scumm, там тоже байт-код
https://fabiensanglard.net/another_world_polygons/
Я понимаю еще, что среди коммерческого инструментария подобного софта нет( потому что дураков за это платить не нашлось), но и среди бесплатного софта (где пишут не из-за денег) тоже ничего нет?
Т.е. среди авторов бесплатного софта дураки должны найтись на такой безумный объем работы?
вот как раз и такие инструменты отсутствуют. Хотя казалось бы чего сложного. Создаешь базу знаний по каждой железяке и скармливаешь ее подготовленного к этому дизассемблеру( ассемблеру с конвертером).
Вероятно у вас за плечами нет дизасма более-менее большой программы. А так да ничего сложного... Вывод в порты, да вывод на экран... Хотя тот же вывод на экран не всегда означает вывод изображения...
Хотя казалось бы чего сложного.
Да ваще как два пальца об асфальт.
З.Ы. Хотя может и найдется прогер, который напишет такое за две недели на "изичах" ?
Lethargeek
17.03.2022, 21:31
макры ты сам и должен писать! Но это то еще занятие по "простоте"
да не сложнее сишечных процедур
Т.е. среди авторов бесплатного софта дураки должны найтись на такой безумный объем работы?
вот здесь на форуме есть продюсеры софтовых проектов и даже выражение употребляли "на что, чёрт возьми вы тратите мои деньги?!" А когда я ишачил программером в небольших российских телекоммуникационных фирмах то всегда был специальный чел, который наблюдал за тем, что там "черти" кодят. То есть в этом случае программисты жутко несвободны! Это все, что я имел в виду, говоря о дураках.
- - - Добавлено - - -
Да ваще как два пальца об асфальт.
просто есть очень сложные алгоритмы и даже есть задачи, которые вообще не поддаются алгоритмизированию в момент их постановки. Здесь же сравнение с образцами из базы и вывод о принадлежности. И выбор подходящего ключа для компилятора, возможно с подтверждением от сведующего программиста. Если ассемблер рассчитан на работу в режиме трансляции для данного cpu, а на вход ему дается безошибочный код, то и после этой операции ошибок в трансляции возникнуть не должно.
- - - Добавлено - - -
да не сложнее сишечных процедур
Имхо некоторое отличие все же есть.
- - - Добавлено - - -
Вероятно у вас за плечами нет дизасма более-менее большой программы
Да, Вы правы, с Metal Mutant-ом и IDA был единичный негативный опыт. Еще был позитивный опыт тупого взлома тупого софта для СВЧ печки. Там не было никакой защиты, а мы придумали простую, но эффективную. Через антидребезг клавиатуры. Чел с ВОМЗ, который не расплатился с нами за авральную работу, расплатился потом тем, что все эти печки пришлось удалять с ленинградских прилавков магазинов и ВОМЗ понес убытки репутационные и экономические. Причем нашего злого умысла в этом не было никакого. Мы ему про то ПЗУ, которое он у нас в Ленинграде забрал как готовое в серию, не говорили, что оно готово в серию на 100%. Он напирал на то, что утром ПЗУ, вечером деньги, а сам исчез с концами и денег мы никогда не увидели. Через пару месяцев на прилавках появились печки, а еще через месяц навсегда исчезли. Кому из потребителей понравится при включении печи получать комфортное нажатие на пластиковые кнопки, а спустя сутки нажимать их все сильнее и сильнее. Если печь перевключить все повторялось по новой.
Ну это было начало 90-х поэтому сложно все было.
У массы людей была система ККН, а у самых отмороженных даже ККУ.
- - - Добавлено - - -
З.Ы. Хотя может и найдется прогер, который напишет такое за две недели на "изичах" ?
вообще я не из продюссеров. Мой первый код был для программируемых калькуляторов, а придя на работу в 1983-м я получил МСУВТ В7 с корзинкой на 6 мест, мембранную клавиатуру на ней, телетайп РТА-80 с перфовыводом и перфовводом и кое какую документацию. А также задание написать кучу драйверов для системы автоматического управления по выращиванию бездислокационного кремния. То, что в ПЗУ на плате был ассемблер и примитивный редактор я узнал не сразу. А сразу я выучил почти всю систему команд 8080, вводил коды с пленочной клавиатуры, отлаживал в мониторе на линейке 7 сегментных индикаторов и чуть позже распечаткой на телетайпе. Даже переадресацию своих кодов делал вручную пока не изучил содержимого монитора. Готовые коды хранил на перфолентах, пока сам не подключил кассетник и фрязинский дисплей. А после всех этих успехов завлаб мне выделил этот кассетник в вечное владение на рабочем месте и осциллограф-мультиметр впридачу. Ну и первую прибавку к окладу со 120 руб. в месяц до 135 руб. в месяц.
Принципиальные косяки есть везде.
принципиальные косяки (читай, баги) это такие косяки, которые в момент останавливают весь проект. таких косяков в указанных компиляторах нет. есть другие моменты, влияющие на разработку.
Ну и да, я влиял на развитие SDCC через переписку с Филиппом Краузе, разработчиком бэк-энда Z80.
рад за тебя. что конкретно ты ему предложил и он это реализовал? а то народ там десятилетиями шлёт ему письма, а воз и ныне там.
Уже обсудили, что драйвер FAT надо делать на асме.
ОК, хотел бы я сказать, НО... на сегодняшний день существует только 2 (два, ДВА) драйвера fat12/16 под Z80, полноценные, которые используются в двух дисковых операционных системах. Не видно что-то множества других реализаций. Сам то ты умеешь с FAT работать? из не давнего - по какой то не ведомой причине Нихираш не стал в своём MoonRabbit для Караба-ПРО запиливать драйвер FATов на асме, а взял FatFS. это при том, что MoonRabbit написан на асме. Ну и да. это вполне реальная и довольно нужная весч (FAT) на сегодняшний день (как оказалось).
Кому-то надо графические библиотеки, которые есть для SDCC, есть для z88dk, но нет для IAR.
я щас тебе твоими же словами - "не всем надо графические библиотеки"...
опять же, ты потратил такую гору времени для портирования всяких библиотек под оберон, а щас говоришь, "ой, под IAR нет библиотек". Руки и голова вроде есть - значит можно написать.
опен сорсность это корявая отговорка.
Очень слабый аргумент. Но, по-моему, у тебя претензий к интерпретатору Васика меньше, чем к Оберону. Но мы на таких, как ты, не особо и надеемся, сами юзаем.
к Васику нет претензий потому, что он, ВНЕЗАПНО, в ПЗУ Спектрума есть (и не только Спектрума). какие могут быть претензии к языку, который сидит в ПЗУ и помогает изучать комп?!
и что значит слабы аргумент? т.е. плодить баги, косяки, ухудшать качество выходного продукта для тебя это нормально?! ну ОК.
Кстати, Лёша Большаков мне как-то показывал код для Z80, сгенеренный LLVM.
да, я тоже видел какой то код сгенерированный LLVM... хелло ворд какой то. и код результирующий ничем не лучше small c. даже парочка тем пролетали на этом форуме. больше ничего как бы и нет по сей день.
На это можно смотреть и как на одно и то же,
совершенно разные вещи. байт-код у хайтеха или солида, это упрощённая форма записи распарсенных функций. это нее одно и тоже, как если пытаться через наборы скриптов приводить к одному виду разные конструкции разных языков. особенно когда речь идёт про ООП в линейку.
Даже в консоли не нужна такая избыточная сишная громадина, как printf с его форматтером.
ага ага (так и запишем)...
Покажи тогда нам игорей на ЯВУ, которые круче, чем асмовские.
эээммм. ШТА?
ну давай)))
http://speccy.info/Evo_SDK
https://www.msx.org/forum/msx-talk/software/fusion-c-call-to-fusion-c-users-coders
как бы есть ещё MSXgl, там тоже Ц...
а теперь посмотрим на игры на обероне?
https://zx.oberon.org/links.htm?Games
ой... а игр то нету под ZX))) где они все?
https://zx.oberon.org/xdev
и тут какие то картинки "красивые" (нет).
вопрос - для чего нужен оберон. если "вот это" на Васике 48м за пару часов набивается?
Oleg N. Cher
18.03.2022, 18:13
Садись и пиши игры на Обероне, которые будут круче. Если можешь. Если не можешь - молчи уже в тряпочку.
- - - Добавлено - - -
Sayman, всё бы ничего, но ты сейчас занимаешься чистым вредительством. Я исследую Оберон-технологии и применяю их для моих любимых ретро-платформ. Только некоторых. Я не пишу для Спринтера или для ZX Next. А ты пытаешься всем навязать своё корявое представление про Обероны на ретро. Давай разберёмся. Если крутые игры на Обероне никто ещё не написал, то где тогда твои ненаписанные программы и нерождённые дети? Где твоя несделанная докторская? И всё в таком роде. А если крутые игры на Обероне вообще невозможны, тогда докажи нам это? Но ты не доказываешь, ты просто методично гробишь моё начинание, как злой демон.
т.е. плодить баги, косяки, ухудшать качество выходного продукта для тебя это нормально?! ну ОК.Если бы был, к примеру, нативный компилятор Оберона в Z80, то ты бы сейчас с пеной у рта сравнивал его кодогенерацию с твоим любимым IAR C. Где основания считать, что отладить компилятор в машкод проще, чем транслятор в Си? Зачем ты вообще говоришь про баги? Я эти баги правлю уже много лет и вылизал всё практически до блеска, притом с адаптацией для получения кода для ретро-платформ. Но зато сейчас есть возможность подключить к этой связке даже IAR. Почему ты не проявляешь восторга? Да всё поэтому же. Или ты хочешь сказать, что ZX Like Pascal менее бажный, чем Ofront+ ? Нет, это не так.
опять же, ты потратил такую гору времени для портирования всяких библиотек под оберон, а щас говоришь, "ой, под IAR нет библиотек". Руки и голова вроде есть - значит можно написать.Если кому-то будет нужно - напишут. Но никому не нужно.
к Васику нет претензий потому, что он, ВНЕЗАПНО, в ПЗУ Спектрума есть (и не только Спектрума). какие могут быть претензии к языку, который сидит в ПЗУ и помогает изучать комп?!Внезапно тебя удивлю. У моей среды XDev была такая же задумка - сделать простой старт в разработку для _разных_ ретро-платформ. Единостильно и просто, без погружения в тонкости машкодов, форматов и утилит. И это вполне удалось в доступном для меня объёме. Я весьма впечатлён как лихо люди разрабатывают на Обероне для ZX, GameBoy. Но люди делают только то, что хотят. Заставить их делать крутые игры я не могу.
да, я тоже видел какой то код сгенерированный LLVM... хелло ворд какой то. и код результирующий ничем не лучше small c. даже парочка тем пролетали на этом форуме. больше ничего как бы и нет по сей день.Намного лучше там код, чем от Small C.
Навязывать кому-то что-то в этом вопросе как модно сейчас выражаться "контрпродуктивно". "Пусть расцветают все цветы" Вот мне отец в 17 лет в 1977 году предлагал помочь сдать на права( он тогда преподавал на автокурсах при ГАИ). Я ему "ты мне сперва ключи от автомобиля дай". Теперь у меня в 2022 году ни прав, ни автомобиля, ни с 1996 года отца. Мачеха предлагала мне его последний автомобиль в 1997 году вместо денег по наследству. А так как прав не было, и не было тогда ни времени, ни денег, то даже вот и тогда "ключи от автомобиля" я не получил.
Это я к тому, что если хоть с чего-то не начать кодить, то пройдет вся жизнь мимо этого.
Это я к тому, что если хоть с чего-то не начать кодить, то пройдет вся жизнь мимо этого.
Путь в тысячу шагов начинается с первого шага, китайский мудрец.
Я стал копать поглубже про программирование под PDP-11 в целом и под БК в частности. Наткнулся на вот такую статью
https://github.com/hoglet67/PiTubeDirect/wiki/PDP-11-Co-Pro-Notes#attempt-1---compiling-on-v7-unix-in-simh
Самое ценное тут это сравнение кросс компиляторов C для PDP-11
https://i.ibb.co/H7vX47Q/image.png (https://ibb.co/H7vX47Q)
Автор приходит к выводу, что наиболее быстрым и удобным является компилятор ACK из 1980ых, лежащий тут
https://github.com/davidgiven/ack
Выше писали, что есть еще GCC, заточенный под PDP, но автор статьи показывает, что GCC проигрывает ACK. Кто-нибудь пробовал использовать ACK для разработки под PDP? Мне кажется, было бы удобно писать код на C с ассемблерными вставками, тем более, что по словам автора ACK такое поддерживает.
Выше писали, что есть еще GCC, заточенный под PDP, но автор статьи показывает, что GCC проигрывает ACK. Кто-нибудь пробовал использовать ACK для разработки под PDP? Мне кажется, было бы удобно писать код на C с ассемблерными вставками, тем более, что по словам автора ACK такое поддерживает.
Если хочешь брать и писать под БК - надо брать ассемблер и писать. Остальное приведет к 15 страницам срача "под БК нет/есть unix", "под БК нет/есть C" (как тут развели на тему Z80) и закончится на том, что все в этом мире хрень, а особенно [подставить марку ретрокомпа].
shattered
19.03.2022, 15:18
к ack придется приделывать runtime для rt-11 или другой ос по вашему выбору, и соответственно заменить toolchain (ассемблер, линкер)
Спасибо. Понял, что это не вариант.
Oleg N. Cher
19.03.2022, 20:23
Если хочешь писать под БК на Си, бери тот GCC, что я сказал. Но без асма всё равно никуда.
Вероятно, здесь на форуме найдутся люди, которые помогут написать первоначальные процедуры на асме, расскажут как стыковать асм с сями. Это будет не быстро, но всё равно будет комфортнее, чем на MACRO-11, ещё и, не дай бог, на самой RT-11.
Выше писали, что есть еще GCC, заточенный под PDP, но автор статьи показывает, что GCC проигрывает ACK.GCC не может проигрывать ACK. ACK это самопальный почти не оптимизирующий компилятор. А GCC выдаёт такие штуки, что прямо диву даёшься. Это лучший из возможных компилей, и мне очень жаль, что нет рабочей версии для Z80.
без асма всё равно никуда
Особенно если писать для БК0010, где доступной памяти программ, по сути, меньше 16 кило. Это как ZX Spectrum 16КБ, коли сравнивать.
Особенно если писать для БК0010, где доступной памяти программ, по сути, меньше 16 кило. Это как ZX Spectrum 16КБ, коли сравнивать.
Почти в два раза больше. У Спектрума 16К реально под программу доступно около 8К. Если забить на подпрограммы из ПЗУ, то почти 10.
Oleg N. Cher
19.03.2022, 21:24
Подтверждаю, что и для БК-0010, и для ZX Spectrum 16K можно писать на Обероне.
В качестве иллюстрации такой разработки для Спека 16К есть Bolder16K (https://github.com/Oleg-N-Cher/Bolder16K), а для БК10/11(M) есть начатки Дурачка (https://zx-pk.ru/threads/33974-esli-by-u-mednonogova-byl-bk.html), куда уже поместилась почти вся нужная логика и графика. Кстати, надо бы его дальше делать.
shattered
20.03.2022, 00:18
GCC выдаёт такие штуки, что прямо диву даёшься
любопытно. какие?
Oleg N. Cher
20.03.2022, 01:16
Один раз он оптимизировал умножение переменной-параметра функции на 5, учтя то, что этой переменной присваивалось только одно константное выражение. Я это заметил только потому, что не было вызова внешней процедуры умножения. Умножения-деления, кратные 2, он тоже ессно оптимизит до сдвигов. Ну и многое другое. Он очень хороший код для PDP-11 даёт, реально. Намного лучший, чем я напишу руками.
- - - Добавлено - - -
Кстати, я знаком с человеком, который использует GNU Pascal для разработки под БК-0010. Но там более древняя версия GCC юзается, чем та, что по ссылке выше. И не адаптированная для КР1801ВМ1 - так что он патчил код уже после выхлопа GCC на уровне асма. И этот механизм не позволял юзать библиотеки. Я к тому, что мой подход с Обероном и более новым GCC несколько совершеннее. И ещё - было бы желание. Нравится Паскаль - пиши на Паскале, нет проблем.
Один раз он оптимизировал умножение переменной-параметра функции на 5, учтя то, что этой переменной присваивалось только одно константное выражение. Я это заметил только потому, что не было вызова внешней процедуры умножения. Умножения-деления, кратные 2, он тоже ессно оптимизит до сдвигов. Ну и многое другое. Он очень хороший код для PDP-11 даёт, реально. Намного лучший, чем я напишу руками.
Сворачивание константных подвыражений и замена алгебраическими эквивалентами -- это типовые оптимизиции, они в любом нормальном компиляторе есть.
Oleg N. Cher
20.03.2022, 14:17
В том случае это не просто было сворачивание константных подвыражений. Это было сворачивание параметра функции до константы, раз он передавался только константой. Согласитесь, это несколько другое.
В том случае это не просто было сворачивание константных подвыражений. Это было сворачивание параметра функции до константы, раз он передавался только константой. Согласитесь, это несколько другое.
Категорически не соглашусь. Аргумент функции в C -- ровно такое же выражение, как и любое другое. С точки зрения компилятора, между этими двумя вызовами функции нет никакой разницы:
int a = 5 + 8;
func(a)
...
func(5+8)
Точнее, разница только в том, что значение переменной a может потребоваться сохранить.
- - - Добавлено - - -
Или речь о том, что он сворачивает вызов чистых функций с константными аргументами в предвычисленную константу? Так это тоже оптимизация константных подвыражений. Чистые функции по определению всегда возвращают одно и то же при тех же аргументах.
Oleg N. Cher
20.03.2022, 17:12
Имеется в виду вот что:
void func (int a, int b, int с) {
... a ; // вот здесь компилятор прямо вставляет константу вместо a,
// ибо он проверил, что все вызовы func идут с этой константой
}
Насколько говорит мой опыт, компиляторы Си (особенно набортные или для ретро-таргетов) эту оптимизацию не делают.
А, понял. На самом деле, такая частичная параметризация возможна не всегда. Если мы экспортируем функцию, то компилятор не имеет права так делать, поскольку мало ли кто её с какими параметрами будет вызывать.
Что же касается GCC, то, видимо, это косвенный эффект оптимизации шаблонов с константными параметрами, типа MyTemplate<a, 5>. В STL и Boost это просто необходимо, там такого -- вагон и маленькая тележка. Страшный язык этот современный C++, вот что я скажу.
А вот в C компиляторах я действительно никогда такого не видел.
Думаю, если эту фекцию экспортировать, то ничего подобного не будет, скорее всего компилятор даже не попытается порождать специализированную версию. Лень проверять :)
Oleg N. Cher
20.03.2022, 20:49
Видимо, да. Функция не экспортирована, помечена static, потому и возможна эта оптимизация. Но GCC реально удивляет качеством кода и помимо этого случая.
shattered
20.03.2022, 23:05
жаль, что godbolt не умеет в pdp11 :)
любопытно посмотреть, во что развернется такой код
void update(unsigned char *mem, int *bitmap, int x, int y) {
for (int m = x; m < x+y; m++) {
unsigned char bits = *mem++;
for (int i = 0; i < 8; i++) {
*bitmap++ = (bits >> i) & 1;
}
}
}
Oleg N. Cher
21.03.2022, 00:23
GCC даёт такой код:
; ---------------------------------------------------------------------------
mov R2, -(SP)
mov R3, -(SP)
mov R4, -(SP)
mov R5, -(SP)
add #-12, SP
mov 30(SP), R3
clr R2
mov 32(SP), R0
add R3, R0
mov 32(SP), R1
inc R1
cmp R3, R0
bgt loc_1062
cmp R0, #-100000
bne loc_1066
loc_1062: ; CODE XREF: RAM:001052↑j
mov #1, R1
loc_1066: ; CODE XREF: RAM:001060↑j
; RAM:001242↓j
mov #4, R0
mov R2, R3
loc_1074: ; CODE XREF: RAM:001100↓j
asl R3
dec R0
bne loc_1074
add 26(SP), R3
mov R3, 10(SP)
dec R1
beq loc_1122
jmp loc_1140
; ---------------------------------------------------------------------------
loc_1122: ; CODE XREF: RAM:001114↑j
add #12, SP
mov (SP)+, R5
mov (SP)+, R4
mov (SP)+, R3
mov (SP)+, R2
return
; ---------------------------------------------------------------------------
loc_1140: ; CODE XREF: RAM:001116↑J
mov 24(SP), R0
add R2, R0
movb @R0, 7(SP)
clr R0
mov #10, R3
loc_1160: ; CODE XREF: RAM:001236↓j
mov R0, R4
asl R4
add 10(SP), R4
mov R4, 2(SP)
clr R4
bisb 7(SP), R4
mov R4, @SP
mov R0, R5
ble loc_1220
loc_1210: ; CODE XREF: RAM:001214↓j
asr R4
dec R5
bne loc_1210
mov R4, @SP
loc_1220: ; CODE XREF: RAM:001206↑j
mov @SP, R4
bic #-2, R4
mov 2(SP), R5
mov R4, @R5
inc R0
sob R3, loc_1160
inc R2
br loc_1066
; ---------------------------------------------------------------------------
GCC даёт такой код:
Печально. Оптимизатор не осилил.
Вот, например:
loc_1066: ; CODE XREF: RAM:001060↑j
; RAM:001242↓j
mov #4, R0
mov R2, R3
loc_1074: ; CODE XREF: RAM:001100↓j
asl R3
dec R0
bne loc_1074
Очевидные ошибки:
1) Проигнорировано существование команды SOB. Компилятор прибит гвоздями к самым младшим моделям PDP-11? Не верится, дальше-то SOB есть.
2) Правильно этот код пишется так:
mov R2, R3
asl R3
asl R3
asl R3
asl R3
На слово короче, не использует дополнительный регистр и как минимум в 3 раза быстрее.
3) Чудовищным образом закодирован цикл со счётом вниз до нуля. Ну это же типовая идиома, кодогенератор должен её узнавать и вставлять шаблон.
А самое главное -- это не совсем от этой функции код :P
Вот сходу в уме декомпилировал начало функции:
func(int a, int b, int c, int d) {
int v3 = c;
int v2 = c + d;
int v1 = d +1
// ЧТО ЭТО ???
if (v3 > v0 || v0 == 0100000) {
v3 = v2* 16;
}
while (--v1 > 0) {
...
}
}
- - - Добавлено - - -
жаль, что godbolt не умеет в pdp11 :)
любопытно посмотреть, во что развернется такой код
void update(unsigned char *mem, int *bitmap, int x, int y) {
for (int m = x; m < x+y; m++) {
unsigned char bits = *mem++;
for (int i = 0; i < 8; i++) {
*bitmap++ = (bits >> i) & 1;
}
}
}
А в этом коде ничего, случаем, не пропало? Что там происходит с x? Зачем он нужен?
- - - Добавлено - - -
Переписал вручную на ассемблере. Если x всё-таки имеет значение, то в инициализации цикла добавляется ещё несколько команд.
Аргументы в регистрах r1..r4
;void update(unsigned char *mem, int *bitmap, int x, int y) {
; for (int m = x; m < x+y; m++) {
; unsigned char bits = *mem++;
; for (int i = 0; i < 8; i++) {
; *bitmap++ = (bits >> i) & 1;
; }
; }
;}
update: mov r5, -(sp)
mov r4, -(sp)
mov r3, -(sp)
mov r2, -(sp)
mov r1, -(sp)
cmp #0, r4
bge 0$
1$: movb (r1)+, r0
mov #10, r5
2$: clr r3
asr r0
adc r3
mov r3, (r2)+
sob r5, 2$
sob r4, 1$
0$: mov (sp)+, r1
mov (sp)+, r2
mov (sp)+, r3
mov (sp)+, r4
mov (sp)+, r5
ret
- - - Добавлено - - -
Таки залез на gobolt.org, и проверил, что тамошняя коллекция компялиторов думает.
Несколько родственный MSP-430
update:
PUSHM.W #1, R10
SUB.W #14, R1
MOV.W R12, 6(R1)
MOV.W R13, 4(R1)
MOV.W R14, 2(R1)
MOV.W R15, @R1
MOV.W 2(R1), 12(R1)
BR #.L2
.L5:
MOV.W 6(R1), R12
MOV.W R12, R13
ADD.W #1, R13
MOV.W R13, 6(R1)
MOV.B @R12, 9(R1)
MOV.W #0, 10(R1)
BR #.L3
.L4:
MOV.W 4(R1), R10
MOV.W R10, R12
ADD.W #2, R12
MOV.W R12, 4(R1)
MOV.B 9(R1), R12
MOV.W 10(R1), R13
CALL #__mspabi_srai
AND.B #1, R12
MOV.W R12, @R10
ADD.W #1, 10(R1)
.L3:
MOV.B #7, R12
CMP.W 10(R1), R12 { JGE .L4
ADD.W #1, 12(R1)
.L2:
MOV.W 2(R1), R12
ADD.W @R1, R12
CMP.W R12, 12(R1) { JL .L5
NOP
ADD.W #14, R1
POPM.W #1, r10
RET
Ужас какой! Плохо у GCC с 16-битками...
Богомерзкий RISC-V:
update(unsigned char*, int*, int, int):
add a5,a2,a3
add a7,a0,a3
li a6,8
ble a5,a2,.L1
.L5:
lbu a2,0(a0)
mv a3,a1
addi a0,a0,1
li a5,0
.L3:
sra a4,a2,a5
addi a3,a3,4
andi a4,a4,1
sw a4,-4(a3)
addi a5,a5,1
bne a5,a6,.L3
addi a1,a1,32
bne a7,a0,.L5
.L1:
ret
А вот это примерно то же самое, что и я написал.
Богомерзкий RISC-V
где бы этот скачать c-компилер?
shattered
21.03.2022, 12:22
изначально этот код выглядел примерно так:
https://github.com/mamedev/mame/blob/master/src/mame/drivers/okean240.cpp#L424
u32 okean240_state::screen_update_okean240(screen_devi ce &screen, bitmap_ind16 &bitmap, const rectangle &cliprect)
{
for (u16 y = 0; y < 256; y++)
{
u8 const ma = y + m_scroll; // ma must be 8-bit
u16 *p = &bitmap.pix(y);
for (u16 x = 0; x < 0x4000; x+=0x200)
{
u8 const gfx = m_p_videoram[x|ma] | m_p_videoram[x|ma|0x100];
/* Display a scanline of a character */
*p++ = BIT(gfx, 0);
*p++ = BIT(gfx, 1);
*p++ = BIT(gfx, 2);
*p++ = BIT(gfx, 3);
*p++ = BIT(gfx, 4);
*p++ = BIT(gfx, 5);
*p++ = BIT(gfx, 6);
*p++ = BIT(gfx, 7);
}
}
return 0;
}
где бы этот скачать c-компилер?
Так это же GCC, последней доступной версии для каждой платформы (для MSP аж шестая, его поддерку давно вырезали). Если надо именно RISC-V, то последняя -- GCC 10.2.0, можно взять, например, тут: https://xpack.github.io/riscv-none-embed-gcc/releases/
- - - Добавлено - - -
изначально этот код выглядел примерно так:
Это вообще другой код. Особенно с точки зрения компилятора. В нём даже циклы не так организованы.
shattered
21.03.2022, 13:42
верно, и внутренний цикл (по битам) разворачивается оптимизатором
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot