[SDK] Древняя тема про nedoPC SDK (август 2004)

Публичный форум для http://www.nedopc.org/nedopc

Moderator: Shaos

Post Reply
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: nedoPC SDK

Post by Shaos »

Shaos wrote:Для начала можно предусмотреть окно в блоке кода, куда будут потом вставлены спрайты (т.к. в момент компиляции кода уже известно сколько у нас спрайтов)...
Это же просто INCBIN бинаря со спрайтами надо сделать в сгенерённый ассемблерный исходник программы по заранее известному отступу (скажем 48 байт) - осталось мой RASM научить делать INCBIN (а zmac это уже умеет с 2005 года усилиями Василия Иванова)...

P.S. На самом деле файл TILES.SPR уже является ассемберным файлом (за исключением комментариев, которые записаны как ; а не \ как того хочет RASM), но при компиляции бинарника спрайтов SPR_COMP делает кое-какие манипуляции с атрибутами в соответствии с выбранной платформой, а также может инвертировать саму картинку, если в комментариях есть символ ! - по идее можно просто поправить SPR_COMP, чтобы он генерировал новый ассемблерный исходник описывающий спрайты вместо придумывания как воткнуть INCBIN в RASM...
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: nedoPC SDK

Post by Shaos »

Shaos wrote:P.S. В настоящий момент есть проблемка с зависимостями - файл _FONT.A включается если в программе использовалась команда SAY, однако подпрограмма PUTCH печатающая букву из шрифта 8х8 находится в системном ассемблерном файле - SPETS.A или там ORION.A - и если пытаться собрать программу без SAY для графических платформ (тех же SPETS или ORION), то будет ошибка ассемблера т.к. метка FONT8X8 не найдена - надо подумать как эту подпрограмму PUTCH обобщить для разных платформ и вставить в _SAY.A - там специфические вещи только для атрибутов цвета, поэтому должно быть решаемо т.к. у меня уже есть системные подпрограммы конверсии цвета - RGB и ATTRIB.

P.P.S. Похоже придумал как победить эту проблемку с зависимостями - заодно у пользователя появится возможность подключать свой собственный шрифт 8x8 :mrgreen:
Короче суть придумки - в списке слов в самом начале блока кода появится слово в котором будет храниться адрес шрифта 8x8 для графических систем и ноль (или FFFF?) для текстовых систем (или систем где используется встроенный в целевую систему шрифт типа speccy с выводом текста через подпрограммы бейсика). Подпрограмма PUTCH пока останется в системных ассемблерных файлах, однако при вызове она будет проверять состояние этой переменной и если там что-то необычное типа #0000 или #FFFF, то ничего не будет печататься. Соответственно пользователь получит возможность через встроенный ассемблер подменить адрес в этой переменной на свой, если он захочет задействовать свой шрифт вместо шрифта nedoPC 8x8 (который я на днях перевёл в категорию PUBLIC DOMAIN чтобы всё содержимое LIB в итоге стало PUBLIC DOMAIN). При старте в этой переменной будет ноль и адрес встроенного шрифта там появится только при первом вызове команды SAY (или PUTCH?), которая будет проверять что там ноль и если да, то будет записывать туда адрес FONT8X8 (а для текстовых систем по видимому туда надо записать что-то ненулевое, но заведомо не являющееся шрифтом, например #FFFF).
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Вроде сделал: https://gitlab.com/nedopc/sdk/-/commit/01efab674c8d64e001fee2bc4e5530fbbe4e8290

Заодно новые сдвиги в LIB/I8080/_SHIFTS.A добавились

P.S. Не - всё таки надо инициализацию _L_FONT в SAY как-то воткнуть - без SAY ошибка компиляции опять получается...

P.P.S. И проект RANDOM чото сломался - рисует только красные квадраты........

P.P.P.S. Нашёл косяк в новой реализации != :(
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Фуф - всё исправил :)

Иницализацию _L_FONT всё таки вставил в SAY, но в RADIO.A и SPECCY.A пришлось вписать заглушку FONT8X8 DB 0 (теперь без -I_FONT оно не соберётся из-за двух меток FONT8X8):

https://gitlab.com/nedopc/sdk/-/commit/eaaac8bea2a97a98fd0f7adaba8312260760cf13

Надо чтоли тест 0002 на != расширить, а то он не поймал сравнение одинаковых маленьких ненулевых чисел...

P.S. Заодно подготовил плацдарм для переноса простых тайлов внутрь бинаря по смещению #0030:

Code: Select all

00000000  c3 3e 00 00 00 00 00 00  00 00 00 60 20 62 00 00  |.>.........` b..|
00000010  5b 4e 45 44 4f 50 43 20  53 44 4b 20 42 49 4e 5d  |[NEDOPC SDK BIN]|
00000020  3d 49 38 30 38 30 2f 72  61 64 69 6f 0a 00 00 00  |=I8080/radio....|
00000030  ...
и когда появится перемещаемость, то слово BIN в заголовке заменится на OBJ, а BITMAP-таблицы для перемещаемости кода и данных будут добавлены в конце после ключевого слова [BITMAPS] плюс я наверное буду такие объектники сжимать своим пакером SHAFF, а то там в области битмапов, которые будут иметь размер в четверть кода, предполагается много нулей...

P.P.S. Вот например как сжимается MAPGEN.BIN для РК даже без битмапов:

Code: Select all

-rw-r--r-- 1 shaos shaos 5004 Aug  4 13:26 MAPGEN.BIN
-rw-r--r-- 1 shaos shaos 2924 Aug 11 21:48 MAPGEN.BINFF0
-rw-r--r-- 1 shaos shaos 2381 Aug 11 21:49 MAPGEN.BINFF1
[/b]
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Добавил в скрипт DEFAULT.N таргет i8080obj для сборки кода не привязанного ни к одной системе (и без картинок), которому можно передать 2 параметра - адрес кода и адрес переменных:

https://gitlab.com/nedopc/sdk/-/commit/04126b8fc269abfccea72b29c96b9783d5a28e86

Для получения перемещаемого объектника сначала запускаем сборку без параметров - оно будет 0 и 0 по умолчанию
Потом смещаем код на сколько-то кратное 256, например собирая с параметрами 0x100 и 0
Потом возвращаем код обратно и смещаем переменные - например собирая с параметрами 0 и 0x100
После этого генерим программно 2 BITMAP таблицы и приклеиваем их сзади к бинарнику собранному с 0 и 0 - эту программу ещё надо написать :mrgreen:

P.S. Интересным свойством таких объектных файлов будет то, что их можно линковать как статически, добавляя в общий бинарник по нужным адресам, так и динамически - подгружая на лету и храня независимо от вызывающей их программы! т.е. это будут эдакие LIB и DLL в одном флаконе :roll:

P.P.S. Заодно отключил очистку области переменных и регистров для таких объектников, чтобы их можно было запускать многократно - т.е. такие робото-объекты смогут переиспользовать свои переменные в разных запусках и помнить своё состояние между запусками...

P.P.P.S. Также это означает, что вызывающая программа должна сама очистить память переменных такого объекта перед первым его вызовом (это будет сделано автоматически, если эта память переменных будет располагаться в памяти переменных вызывающей программы)…
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Статистика репы https://gitlab.com/nedopc/sdk с конца 2006 года (т.е. ещё с SourceForge времён CVS):

Screenshot from 2024-07-26 00-52-20.png
Screenshot from 2024-07-26 00-52-20.png (21.01 KiB) Viewed 1488 times

Весной 2018 года был пик это я накидал туда исходников RW1P2 все какие были друг на друга когда переехал на GitHub (а может git отдельными коммитами из CVS добавлял файлы при конверсии в итоге вышел как бы пик), а потом очень скоро (летом 2018) репа переехала на GitLab, где до сих пор и обитает...
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Наверное в копилку софта для nedoPC SDK надо добавить RW1_EDIT, который для меня написал младший брат моей бывшей жены в 1999 году когда он ещё в универе учился - это именно тот редактор, что входил в состав Sprinter SDK by nedoPC (2003), который я называю RW1P2 v1.5:

SprinterSDK-990x840.png
SprinterSDK-990x840.png (175.9 KiB) Viewed 1462 times

До этого редактор использовался в моей шареварной игре для программистов Robot Warfare 1 v2.x (виндовая версия):



Редактор написан на C++ только под Windows и его исходники никогда не публиковались (но они у меня есть т.к. я в 2003 году уже сам этот редактор расширял без помощи первоначального автора, превратив его по сути в IDE для RW1P2) - надо будет его переписать на чистых сях под DOS, а потом уже можно и на Robby портировать...

P.S. Либо переписать его на wxWidgets, чтобы могло работать в современной винде, в линухе и в макос?
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Shaos wrote:Статистика репы https://gitlab.com/nedopc/sdk с конца 2006 года (т.е. ещё с SourceForge времён CVS):



Весной 2018 года был пик это я накидал туда исходников RW1P2 все какие были друг на друга когда переехал на GitHub (а может git отдельными коммитами из CVS добавлял файлы при конверсии в итоге вышел как бы пик), а потом очень скоро (летом 2018) репа переехала на GitLab, где до сих пор и обитает...
Хорошо, что какое-то время назад меня осенило вписать в описание старого проекта на SourceForge линк на новое местоположение репы - теперь все сайты, которые автоматом тянут проекты с SF показывают этот линк :lol:
Attachments

Screenshot from 2024-07-27 11-26-27.png
Screenshot from 2024-07-27 11-26-27.png (59.6 KiB) Viewed 1428 times

Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Самый старый файл в репе с точки зрения гита 8)
Attachments

SDK-oldest.png
SDK-oldest.png (132.57 KiB) Viewed 1426 times

Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Вот думаю может системе Специалист в SDK вернуть историческое название spec вместо spets? И соответственно specmx вместо spetsmx? Я в своё время решил переименовать spec в spets, чтобы буржуи не путали spec со speccy, однако до мая 2018 года оно таки называлось spec:

https://gitlab.com/nedopc/sdk/-/commit/e4fb7feda6b6317dccf87ef09e5ccfaabf99937b
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Гляжу в _VARS.A и там

Code: Select all

\ BASE TO BC

_V_B2B: PUSH_H
        LHLD    _L_BASE
        MOV_B,H
        MOV_C,L
        POP_H
        RET
используется в __RULES, но вызов этой подпрограммы можно выкинуть совсем, вставив в __RULES вместо неё LXI_B, @BASE (что суть тоже самое)

Code: Select all

\ REGS TO BC

_V_R2B: PUSH_H
        LHLD    _L_REGS
        MOV_B,H
        MOV_C,L
        POP_H
        RET
нигде не используется

Code: Select all

\ SET VAR
\ BC - BASE
\ HL - VAR
\ DE - DATA

_V_SET: PUSH_H
        DAD_B
        POP_B
        DAD_B
        MOV_M,E
        INX_H
        MOV_M,D
        RET
пока нигде не используется, но может понадобиться в будущем (см. ниже)

Code: Select all

\ GET VAR
\ BC - BASE
\ HL - VAR
\ --------
\ HL - DATA

_V_GET: PUSH_H
        DAD_B
        POP_B
        DAD_B
        MOV_E,M
        INX_H
        MOV_D,M
        XCHG
        RET
используется только в _VARS.A

Code: Select all

\ GET VAR FROM BASE
\ HL - VAR
\ --------
\ HL - DATA

_B_GET: XCHG
        LHLD    _L_BASE
        DAD_D
        DAD_D
        MOV_E,M
        INX_H
        MOV_D,M
        XCHG
        RET
используется в __RULES, но вызов этой подпрограммы можно заменить на LXI_B, @BASE и CALL _V_GET

Code: Select all

\ SET VAR FROM BASE
\ HL - VAR
\ DE - DATA

_B_SET: PUSH_H
        LHLD    _L_BASE
        POP_B
        DAD_B
        DAD_B
        MOV_M,E
        INX_H
        MOV_M,D
        RET
используется в __RULES (см.ниже)

Code: Select all

\ GET REG
\ L - REGISTER
\ --------
\ HL - DATA

_R_GET: MVI_H,  0
        XCHG
        LHLD    _L_REGS
        DAD_D
        DAD_D
        MOV_E,M
        INX_H
        MOV_D,M
        XCHG
        RET
используется в _VARS.A и __RULES, но вызов этой подпрограммы можно заменить на LXI_B, @REGS и CALL _V_GET с предварительным обнулением регистра H

Code: Select all

\ SET REG
\ L - REGISTER
\ DE - DATA
\ --------

_R_SET: PUSH_D
        MVI_H,  0
        XCHG
        LHLD    _L_REGS
        DAD_D
        DAD_D
        POP_D
        MOV_M,E
        INX_H
        MOV_M,D
        RET
используется в __RULES (см.ниже)

Code: Select all

\ GET ARR
\ BC - BASE
\ DE - ARRAY
\ HL - VAR
\ --------
\ HL - DATA

_A_GET: PUSH_B
        PUSH_D
        CALL _V_GET
        XCHG
        POP_B
        POP_H
        DAD_B
        DAD_B
        DAD_D
        DAD_D
        MOV_E,M
        INX_H
        MOV_D,M
        XCHG
        RET
используется в __RULES

Code: Select all

\ GET ARR REG
\ BC - BASE
\ DE - ARRAY
\ HL - REGISTER
\ --------
\ HL - DATA

_ARGET: PUSH_B
        PUSH_D
        CALL _R_GET
        XCHG
        POP_B
        POP_H
        DAD_B
        DAD_B
        DAD_D
        DAD_D
        MOV_E,M
        INX_H
        MOV_D,M
        XCHG
        RET
используется в __RULES

Code: Select all

\ ADR ARR
\ BC - BASE
\ DE - ARRAY
\ HL - VAR
\ --------
\ HL - ADDRESS

_A_ADR: PUSH_B
        PUSH_D
        CALL _V_GET
        XCHG
        POP_B
        POP_H
        DAD_B
        DAD_B
        DAD_D
        DAD_D
        RET
используется в __RULES

Code: Select all

\ ADR ARR REG
\ BC - BASE
\ DE - ARRAY
\ HL - REGISTER
\ --------
\ HL - ADDRESS

_ARADR: PUSH_B
        PUSH_D
        CALL _R_GET
        XCHG
        POP_B
        POP_H
        DAD_B
        DAD_B
        DAD_D
        DAD_D
        RET
используется в __RULES

Причём самый часто используемый в сгенерённом коде кусок из __RULES выглядит вот так:

Code: Select all

// 0xF3 // LOAD       A -> mem[A]
*EXPR 0xF3
#addsub _VARS
#genlab %l1
#genlab %l2
        MVI_A,  #FF
        CMP_H
        JNZ     %l1
        \ REGISTER
        CALL    _R_GET
        JMP     %l2
%l1
        \ VARIABLE
        CALL    _B_GET
%l2
*
Это дело надо упростить, чтобы было как-то так:

Code: Select all

// 0xF3 // LOAD       A -> mem[A]
*EXPR 0xF3
#addsub _VARS
        CALL _X_GET
*
Соответственно в _VARS.A надо будет добавить "вумную" подпрограмму _X_GET, которая сама будет определять чего от неё хотят - регистр (HL==#FFxx), переменную (HL>=0) или слово из буфера обмена с системой ввода-вывода (#8000...#FEFF) - последнего пока нету, но будет (буфер будет виртуальный - вместо обращения к памяти в данном случае будет вызываться подпрограмма из SYSTEM_.A которая будет возвращать слово по специфическому для системы алгоритму).

Аналогичное надо будет проделать вот с этим:

Code: Select all

// 0xF4 // SAVE       A,B -> .  (mem[A]=B)
*EXPR 0xF4
#addsub _VARS
#genlab %l1
#genlab %l2
        POP_D
        XCHG
        MVI_A,  #FF
        CMP_H
        JNZ     %l1
        \ REGISTER
        CALL    _R_SET
        JMP     %l2
%l1
        \ VARIABLE
        CALL    _B_SET
%l2
        POP_H
*
Добавив "вумную" подпрограмму _X_SET (устанавливающую регистр или память в зависимости от адреса), а подпрограммы _R_SET и _B_SET выкинуть за ненадобностью. Либо надо написать код прямо по месту т.к. SAVE это редкая операция, которая происходит один раз на выражение, и обращений к буферу файловой подсистемы на запись у нас не предвидится поэтому можно обойтись только вызовом _V_SET с разной базой для регистров и переменных:

Code: Select all

// 0xF4 // SAVE       A,B -> .  (mem[A]=B)
*EXPR 0xF4
#addsub _VARS
#genlab %l1
        POP_D
        XCHG
        LXI_B, @BASE
        MVI_A,  #FF
        SUB_H
        JNZ     %l1
        MOV_H,A
        LXI_B, @REGS
%l1
        CALL    _V_SET
        POP_H
*
Единственное тут нету никакой проверки на выход за пределы области переменных (или регистров, коих у нас не более 32), но если компилятор ROBBYC работает корректно, то все смещения должны быть в нужных пределах (ну разве что бинарник будет попорчен при передаче или чтении с диска, тогда конечно да)...

P.S. Инициализация регистров Robby (а именно A,B,C и L) у меня сейчас компилируется в относительно компактный код целевой платформы, как и копирование из памяти переменных в регистр и из регистра в память переменных - вот думаю, а не сделать ли в случае платформы 2 (RW1P2) все регистры read/write? И накидать ещё регистров до 32-х, как планировал ранее - тогда простые подпрограммы можно будет писать только на регистрах (для пользователя они будут выглядеть просто как однобуквенные переменные) и они будут работать заметно быстрее...
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Вот вроде сделал _X_GET:

Code: Select all

\ GET VAR OR REG OR BUF
\ HL - VAR
\ --------
\ HL - DATA

_X_GET: MOV_A,H
        CPI     #FF
        JNZ     _X_G1
        LXI_B,  @REGS
        MVI_H,  0
        JMP     _V_GET
_X_G1:  ADD_A
        JNC     _X_G2
        XCHG
        LHLD    _F_READ
        MOV_A,H
        ORA_L
        RZ      \ RETURN 0 IF NO _F_READ SET
        PCHL    \ OTHERWISE GOTO _F_READ ADDRESS
_X_G2:  LXI_B,  @BASE
        \ GO FURTHER INTO _V_GET

\ GET VAR
\ BC - BASE
\ HL - VAR
\ --------
\ HL - DATA

_V_GET: PUSH_H
        DAD_B
        POP_B
        DAD_B
        MOV_E,M
        INX_H
        MOV_D,M
        XCHG
        RET
Даже удалось воспользоваться тем, что подпрограмма _V_GET идёт следом :)

https://gitlab.com/nedopc/sdk/-/commit/f879a3e3e4e3e7f21a875903f8ca13bdf3f66bb2
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Shaos wrote:Добавил в скрипт DEFAULT.N таргет i8080obj для сборки кода не привязанного ни к одной системе (и без картинок), которому можно передать 2 параметра - адрес кода и адрес переменных:

https://gitlab.com/nedopc/sdk/-/commit/04126b8fc269abfccea72b29c96b9783d5a28e86

Для получения перемещаемого объектника сначала запускаем сборку без параметров - оно будет 0 и 0 по умолчанию
Потом смещаем код на сколько-то кратное 256, например собирая с параметрами 0x100 и 0
Потом возвращаем код обратно и смещаем переменные - например собирая с параметрами 0 и 0x100
После этого генерим программно 2 BITMAP таблицы и приклеиваем их сзади к бинарнику собранному с 0 и 0 - эту программу ещё надо написать :mrgreen:

P.S. Интересным свойством таких объектных файлов будет то, что их можно линковать как статически, добавляя в общий бинарник по нужным адресам, так и динамически - подгружая на лету и храня независимо от вызывающей их программы! т.е. это будут эдакие LIB и DLL в одном флаконе :roll:

P.P.S. Заодно отключил очистку области переменных и регистров для таких объектников, чтобы их можно было запускать многократно - т.е. такие робото-объекты смогут переиспользовать свои переменные в разных запусках и помнить своё состояние между запусками...

P.P.P.S. Также это означает, что вызывающая программа должна сама очистить память переменных такого объекта перед первым его вызовом (это будет сделано автоматически, если эта память переменных будет располагаться в памяти переменных вызывающей программы)…
Кстати аргументы (и результаты) можно ведь не только через область переменных передавать, но и через стек :o
Тогда я для объектников ещё и стек не буду переставлять на внутренний - пусть крутятся в стеке вызывающей программы...

P.S. Сделал. Заодно унифицировал SAY - теперь он единообразен в Z80 и i8080:

https://gitlab.com/nedopc/sdk/-/commit/a8d2b374b2373de4229ef1d1dd42d9276e8bc7da

P.P.S. Печать 16-битных слов в десятичном виде перекочевала в RW1P2 из моей недоделанной операционки ShaOS (т.е. написано мною "из головы" ещё в 1997 году), но оно там было беззнаковым, а знак я добавил сильно позже - Z80 SAY научился печатать отрицательные десятичные числа ещё в 2006 году (т.е. уже после всех релизов RW1P2), а i8080 SAY - вот только сейчас :lol:
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re: [SDK] Старая тема про nedoPC SDK (август 2004)

Post by Shaos »

Ещё надо добавить следующие утилиты:
  • NEW_PRJ - для создания пустого проекта в поддиректрии PRJ
  • OBJMAKER - для сборки перемещаемого объектного файла .O
  • OBJINFO - для распечатки информации о файле .O (декодирование хедеров)
А вообще первым делом хорошо бы BIN2TAP научить делать RK и RKS файлы...

P.S. В мелких утилитах вижу пару мест, которые на big-endian машинах будут неправильно работать - если буду переносить весь пакет на PowerPC G3/G4, то надо будет подчистить (большие проги там вроде всегда работали типа rasm или robbyc)...
Я тут за главного - если что шлите мыло на me собака shaos точка net
User avatar
Shaos
Admin
Posts: 23676
Joined: 09 Jan 2003 06:22
Location: Silicon Valley
Contact:

Re:

Post by Shaos »

На первой странице этого топика я почти 10 лет назад писал следующее:
Shaos wrote:Ещё одна проблема с RW1P2 была в том, что все переменные и операции 2-байтовые, даже если надо хранить и оперировать однобайтовыми величинами. Есть мысль как это победить (т.е. не кодогенерить лишнего кода если работа идёт с однобайтовыми величинами) - для начала заведём макросы для работы с половинками слов:

Code: Select all

@lobyte(1)=((@1) & #00FF)
@hibyte(1)=(((@1)>>8) & #00FF)
@setlobyte(2)=@1=(@1 & #FF00)|((@2) & #00FF )
@sethibyte(2)=@1=(@1 & #00FF)|((@2) << 8)
lobyte и hibyte будут вытаскивать соответствующий байт из слова, а setlobyte и sethibyte будут устанавливать соответствующий байт слова - тогда при интерпретации оно будет работать как написано, а при кодогенерации можно детектировать соответствующие последовательности байткодов и заменять на более простой код целевой платформы:

// lobyte(var)
#F5 PUSH
#??
#??
#F3 LOAD
#F5 PUSH 255
#FF
#00
#C0 &
// прочитать байт по адресу ????

// hibyte(var)
#F5 PUSH
#??
#??
#F3 LOAD
#F5 PUSH 8
#08
#00
#D0 >>
#F5 PUSH 255
#FF
#00
#C0 &
// прочитать байт по адресу ????+1

// setlobyte(var,expression)
#F5 PUSH
#??
#??
#F5 PUSH
#??
#??
#F3 LOAD
#F5 PUSH #FF00
#00
#FF
#C0 &
.......
#F5 PUSH #00FF
#FF
#00
#C0 &
#C1 |
#F4 SAVE
// произвести вычисления и сохранить однобайтный результат по адресу ????

// sethibyte(var,expression)
#F5 PUSH
#??
#??
#F5 PUSH
#??
#??
#F3 LOAD
#F5 PUSH #00FF
#FF
#00
#C0 &
.......
#F5 PUSH 8
#08
#00
#D1 <<
#C1 |
#F4 SAVE
// произвести вычисления и сохранить однобайтный результат по адресу ????+1

P.S. Причём вычисления внутри setlobyte/sethibyte можно делать однобайтовыми (и беззнаковыми?) - как минимум сложение, вычитание и логические операции...
А можно пойти по пути, по которому пошли другие продвинутые компиляторы сей для 8080 - пробегание специальным оптимизатором по сгенерённому ассемблерному исходнику с заменой распознанных последовательностей инструкций на более оптимальные эквиваленты (см. https://en.wikipedia.org/wiki/Peephole_optimization) - например xm=@hibyte(xm) сейчас скомпилируется вот в такой исходный код Robby:

Code: Select all

XM=(((XM)>>8) & #00FF)
который через Robby-байткод скомпилируется вот в такой 8080 код:

Code: Select all

\ *0x40
_j0024:
\ 0xF5
        PUSH_H
        LXI_H,  #0000
\ 0xF5
        PUSH_H
        LXI_H,  #0000
\ 0xF3
        CALL    _X_GET
\ 0xF5
        PUSH_H
        LXI_H,  #0008
\ 0xD0
        POP_D
        CALL SHIFTR
\ 0xF5
        PUSH_H
        LXI_H,  #00FF
\ 0xC0
        POP_D
        MOV_A,D
        ANA_H
        MOV_H,A
        MOV_A,E
        ANA_L
        MOV_L,A
\ 0xF4
        POP_D
        XCHG
        LXI_B, @BASE
        MVI_A,  #FF
        SUB_H
        JNZ     _l0004
        MOV_H,A
        LXI_B, @REGS
_l0004:
        CALL    _V_SET
        POP_H
тут например сразу же видно, что вот тут:

Code: Select all

        LXI_H,  #0000
\ 0xF5
        PUSH_H
        LXI_H,  #0000
можно опустить второй LXI_H, #0000 т.к. в HL уже 0 и далее:

Code: Select all

\ 0xF5
        PUSH_H
        LXI_H,  #00FF
\ 0xC0
        POP_D
        MOV_A,D
        ANA_H
        MOV_H,A
        MOV_A,E
        ANA_L
        MOV_L,A
можно заменить на

Code: Select all

MVI_H, 0
Первый PUSH_H и последний POP_H тоже можно убрать т.к. они бессмысленны...

P.S. Также можно опционально делать оптимизацию по размеру в ущерб скорости (скажем если надо утолкать большую программу Robby в небольшую память микрокомпьютера и на быстродействие наплевать), когда устойчивые конструкции типа:

Code: Select all

        MOV_A,D
        ANA_H
        MOV_H,A
        MOV_A,E
        ANA_L
        MOV_L,A
будут заменяться на вызов подпрограмм типа CALL HL_AND_DE

P.P.S. Хотя наверное будет проще научить ROBBYCC распознавать паттерны в длинных выражениях (коды операций не совпадают с кодами команд поэтому теоретически их можно отнести к одному классу и работать с ними единообразно), а для опциональной оптимизации по размеру добавить в __RULES условную компиляцию, чтобы для каждой команды одновременно описывались бы быстрая версия и компактная версия...
Я тут за главного - если что шлите мыло на me собака shaos точка net
Post Reply