Так как в итоге решилась проблема с генерацией этой таблицы? Или осталось в варианте нахождения абсолютных адресов разностью двух бинарных кусков?Сообщение от SfS
Так как в итоге решилась проблема с генерацией этой таблицы? Или осталось в варианте нахождения абсолютных адресов разностью двух бинарных кусков?
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Генерится из двух бинарных файлов. Отсюда и ограничение на адрес загрузки кратный 256
Релоцируемые исполняемые файлы были ещё в MPM (многопользовательская цпм). Там такая же таблица 256 байт в конце файла. так что ничего нового не изобретено.
1. Таблица столько байт, сколько надо. Не обязательно 256.
2. Адрес загрузки кратен 256 (например 0x8000, 0x8100, 0xC200 и так далее).
3. Целью было не "изобрести", а реализовать возможность загрузки библиотек.
А вот как бы вы предложили связать SDCC и движок типа Nirvana, привязанный к определённому адресу в памяти?
[скомпилированный Си-код] [00 00 00 много нулей 00 00 00] [Nirvana]
Си-код растёт, уменьшая размер пустого блока нулей.
Самое простое, что можно придумать - загружать код и движок отдельными блоками - LOAD ""CODE 2 раза.
Решил набросать утилитку, которая будет сливать два бинаря с указанием их адресов в один блок, показывать размер пустого блока нулей между ними. И если Си-код, растущий вверх, наполз на начало следующего блока (отрицательный размер буфера нулей), сигнализировать об этом.
Может есть ещё какие-то варианты? (хочется только один LOAD ""CODE)
После загрузки раздвинуть блоки LDIR-ом.
Или другие, более продвинутые методы упаковки.
Думаю, что тут поможет только подход аля evosdk. ДУмаю, что в любом случае без изменений тут не обойтись. Придётся в исходники лезть и править вызов тех функций, которые будут распиханы по страницам.
Да, так можно. Заодно и упаковать код - хорошая мысль.После загрузки раздвинуть блоки LDIR-ом.
Или другие, более продвинутые методы упаковки.
Если линкер SDCC нормально поддерживает секции с абсолютным адресом, можно бинарник конвертнуть в rel формат и линковать как и все остальное,
Описать точки входа и создать хидер
- - - Добавлено - - -
Для совсем прозрачного, нужна прослойка с маршалингом параметров
Это будет сильно зависеть от того какая используется ОС (ну или хотя бы окружение) и особенностей компилятора. Там ведь не только С-код растет в область нулей, с ним то как раз проще всего. Обычно выше кода еще размещается куча, рост и освобождение которой в процессе выполнения кода конечно можно просчитать, но довольно муторно. А навстречу куче с верхнего предела пользовательской области растет стек который в таком случае тоже надо бы по-хорошему контролировать (или просчитать).
Поэтому например в CP/M лет пятьдесят назад было принято такие "драйвера" загружать так. В начале адресного пространства стояло 2 JMP на начало (огрубляю для упрощения) BIOS и BDOS ОС (их ставила ОС - она занимала верхние адреса ОЗУ). С-код при своей инициализации по ним всегда определял верхнюю границу пользовательской памяти и далее назначал кучу и стек. Т.е. было достаточно перед стартом C-кода под потолком пользовательского ОЗУ (т.е. ниже реального начала ОС) разместить тот "драйвер" (который включает в начале своего кода JMP BDOS; JMP BIOS) и переназначить те 2 адреса в начале адресного пространства на переходы в начале кода "драйвера". Далее при старте С-кода всё происходило само и не было никаких привязок ни к размеру пользовательского ОЗУ, ни к размеру того "драйвера", ни к размеру C-кода, ни необходимости чего-то просчитывать: С-процессу тупо либо хватало места в ОЗУ, либо нет (т.е. при достаточности ОЗУ никогда ничего ни на что не наползало).
Последний раз редактировалось Error404; 05.06.2018 в 11:41.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
