Так как в итоге решилась проблема с генерацией этой таблицы? Или осталось в варианте нахождения абсолютных адресов разностью двух бинарных кусков?
Вид для печати
Генерится из двух бинарных файлов. Отсюда и ограничение на адрес загрузки кратный 256
Релоцируемые исполняемые файлы были ещё в MPM (многопользовательская цпм). Там такая же таблица 256 байт в конце файла. так что ничего нового не изобретено.
А вот как бы вы предложили связать SDCC и движок типа Nirvana, привязанный к определённому адресу в памяти?
[скомпилированный Си-код] [00 00 00 много нулей 00 00 00] [Nirvana]
Си-код растёт, уменьшая размер пустого блока нулей.
Самое простое, что можно придумать - загружать код и движок отдельными блоками - LOAD ""CODE 2 раза.
Решил набросать утилитку, которая будет сливать два бинаря с указанием их адресов в один блок, показывать размер пустого блока нулей между ними. И если Си-код, растущий вверх, наполз на начало следующего блока (отрицательный размер буфера нулей), сигнализировать об этом.
Может есть ещё какие-то варианты? (хочется только один LOAD ""CODE)
Это будет сильно зависеть от того какая используется ОС (ну или хотя бы окружение) и особенностей компилятора. Там ведь не только С-код растет в область нулей, с ним то как раз проще всего. Обычно выше кода еще размещается куча, рост и освобождение которой в процессе выполнения кода конечно можно просчитать, но довольно муторно. А навстречу куче с верхнего предела пользовательской области растет стек который в таком случае тоже надо бы по-хорошему контролировать (или просчитать).
Поэтому например в CP/M лет пятьдесят назад было принято такие "драйвера" загружать так. В начале адресного пространства стояло 2 JMP на начало (огрубляю для упрощения) BIOS и BDOS ОС (их ставила ОС - она занимала верхние адреса ОЗУ). С-код при своей инициализации по ним всегда определял верхнюю границу пользовательской памяти и далее назначал кучу и стек. Т.е. было достаточно перед стартом C-кода под потолком пользовательского ОЗУ (т.е. ниже реального начала ОС) разместить тот "драйвер" (который включает в начале своего кода JMP BDOS; JMP BIOS) и переназначить те 2 адреса в начале адресного пространства на переходы в начале кода "драйвера". Далее при старте С-кода всё происходило само и не было никаких привязок ни к размеру пользовательского ОЗУ, ни к размеру того "драйвера", ни к размеру C-кода, ни необходимости чего-то просчитывать: С-процессу тупо либо хватало места в ОЗУ, либо нет (т.е. при достаточности ОЗУ никогда ничего ни на что не наползало).
Оффтопик. В связи с тем, что github был куплен микрософтом, а всё, что покупает микрософт, превращается в *****, я переезжаю на gitlab: https://gitlab.com/salextpuru/
В порядке бреда: а почему ещё тут нет репозитория? Тогда все спекпроекты могли бы сюда кидать и к вики привязывать. Достоинства просты: люди видели бы что делают другие и ничего бы не терялось. ну это так.. мыслищи вслух...
Тишина. Сразу видно, лето наступило) Народ разбежался)
срочно ищи компилер!
Что с твоей уверенностью?) Кто её так?)
Пока что бессвязное, но уже всё-таки хоть какое-то описание исходников инвитры для CSP2018. Вдруг кому поможет в чём-нибудь. https://github.com/salextpuru/sdcc-n...018invitro.pdf