Написание программ для БК0010

[ivagor]

Результатами работы новейших упаковщиков ZX0 и ZX1 теперь можно пользоваться и на pdp11 (1, 2). Особенно приятно то, что мощные упаковщики сочетаются с компактными и сравнительно быстрыми распаковщиками. Если расположить на одной шкале еще и lzsa1/2, то:
быстрая распаковка LZSA1 - (LZSA2) - ZX1 - ZX0 сильное сжатие
К сожалению текущий вариант распаковщика LZSA2 для PDP11 никуда не годится, он непристойно большой, а по скорости его обогнал ZX1 и почти догнал ZX0, но в принципе его можно оптимизировать. А вот с остальными все довольно неплохо, особенно удался распаковщик ZX0 (забавно, что его версии для 8080 и pdp11 получились почти одинаковые по размеру: 101 и 102 байта соответственно).

[Advertiser]

[Manwe]

Результатами работы новейших упаковщиков ZX0 и ZX1 теперь можно пользоваться и на pdp11

Круто! А где скачать сами упаковщики? Под Windows или под Мак.

[ivagor]

Там есть ссылки на github автора упаковщиков (Einar Saukas). Для mac нет, под win есть.

[litwr]

Это ответ на вопрос: Как узнать сколько памяти осталось?
Но был задан иной вопрос

π-калькулятор захватывает всю память и это получалось около 31000 байт - никаких специальных конфигураций не использовал.

[Raydac]

Там есть ссылки на github автора упаковщиков (Einar Saukas). Для mac нет, под win есть.

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

[ivagor]

Einar Saukas сделал на основе ZX0/1 упаковщик ZX2 для маленьких файлов, а я сделал распаковщик для PDP11. Стоит пару слов сказать про опции.
Опция -y для реализации на PDP11 (в отличие от 8 биток) бесполезна и я не стал ее поддерживать.
Опция -z для большинства упакованных файлов прибавляет +1 байт, но зато распаковщик pdp11 с ней на 4 байта короче, поэтому
оба варианта распаковщиков рассчитаны на использование -z.
Опция -x сокращает распаковщик на 6 байт, но упакованный файл может получится (не всегда) чуть больше, поэтому в каждом конкретном случае надо смотреть на общую длину связки распаковщик+упакованный файл.
Опцию -b (распаковка в обратном направлении) для PDP11 на данный момент не реализовал.
В итоге 2 варианта распаковщиков: 80 байт (-z) и 74 байта (-x -z).

[S_V_B]

Прикольная картинка от RDC:

        MOV	#40000,R0
	CLR	R1
	MOV	#400,R3
3:	MOV	#40,R4
2:	MOV	#20,R5
1:	ADD	R1,R2
	ROR	(R0)
	ADD	#100,R1
	SOB	R5,1
	TST	(R0)+
	SOB	R4,2
	SUB	#77600,R1
	SOB	R3,3

Лучше в нулевой палитре

[Manwe]

Прикольная картинка от RDC

Где нарыл?

[S_V_B]

Где нарыл?

Искал для Неона что-нибудь.. там до кучи валялась

[SuperMax]

И как повторное подведение итогов.
При текущем раскладе дел - я не буду даже пробовать PDPy11 - потому что даже простейшие мои программы он не оттранслирует - независимо от того - под какой целевой комп (БК-УКНЦ-ДВК) они будут написаны.

напишу о своем опыте - я честно попытался

1. тк он написан на питоне - получаем приколы от питона, а именно он (питон) требует свою кодировку
иначе говоря ему KOI8 не подсунуть (или надо разбираться как)
UTF-8 на винде 7-ке он тоже есть не захотел, пришлось конвертировать в 1251

2. макросы не знает, те стандартный код в MACRO11 не понимает

3. cравнил генерацию моего старого кода климата
тут 293 differences.
PDPy11_BUG_#2.rar
сходу вижу расхождение в адресах - дальше не копал.

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

upd: первый баг не подтвердился, точнее тут виноват не PDPy11 а asm.com который подавился длинной меткой