Алан Кокс представил Unix-подобную ОС Fuzix, ядро которой потребляет около 40 Кб ОЗУ

[Eltaron]

Отлаживал урезанный вариант ls, нашёл неслабую ошибку в библиотеке. Файл readdir.c должен оканчиваться так:

Ого, классная бага! Запушил Алану http://github.com/EtchedPixels/FUZIX/pull/22

[Advertiser]

[b2m]

Если честно, я бы вместо len-2 поставил константу MAXNAMLEN - и быстрее, и надёжнее. Мало ли что вернёт система Сейчас она всегда возвращает 32.

[b2m]

Глядя на то, как медленно и печально грузится ls, мне пришла в голову мысль, что основную часть библиотеки libc нужно бы разместить в ПЗУ. Варианта, естесственно, три:
1. вместо BASIC48
2. вместо TRDOS
3. вместо RESET SERVICE
В первом варианте теряем возможность запускать игрушки, во втором - запускать дисковые игрушки, третий вроде подходит, но нужно будет обращаться через 3Dxx, к тому-же будут открыты порты BDI.

Что думает по этому поводу уважаемый Eltaron?

[Eltaron]

Что думает по этому поводу уважаемый Eltaron?

Я ничего не знаю про RESET SERVICE, но идея разделяемой либы, конечно, хорошая. С точки зрения маппинга будут проблемы - нужно сохранять/восстанавливать не только страницу ОЗУ, но и ПЗУ. Но это решаемо.

У меня была другая идея - выделить под либу одну из страниц ОЗУ. Но тут не только с маппингом пришлось бы попрыгать, но и с вызовом библиотечных функций. Новый RST городить, или ещё какую-нибудь точку входа ниже #C000.

[b2m]

Я ничего не знаю про RESET SERVICE

Это когда ставят 256Кб 64Кб ПЗУ, в которой и BASIC48, и BASIC128, и TRDOS в одной м/с. Насколько я понял, там остаётся ещё одна свободная страница, которая включается после сброса, если BDI настроен на автоматическое включение TRDOS после сброса.

С точки зрения маппинга будут проблемы - нужно сохранять/восстанавливать не только страницу ОЗУ, но и ПЗУ.

Там всё просто: для ядра - ядро, для режима пользователя - либа. RST, конечно, надо в либе реализовать, также как и обработку прерывания в режиме пользователя.

У меня была другая идея - выделить под либу одну из страниц ОЗУ.

А как быть с адресами данных, которые по любому в другой странице ОЗУ вместе с программой?

У меня была аналогичная идея, но я думал освободить непереключаемое ОЗУ для libc и других разделяемых библиотек, практически полностью перенеся ядро в переключаемые страницы. Много занимают буфера, но перенеся их в другие страницы мы усложняем загрузку файлов в область программы. А если, например, код ядра и буфера будут в разных страницах, то тут могут другие сложности возникнуть.

Вобщем libc в ПЗУ - наиболее простое решение.

[solegstar]

Это когда ставят 256Кб ПЗУ

ну ПЗУ ставят на самом деле 64кб (27С512), 4 страницы по 16кб. первые 16 кб или свободны или используются под свои нужды - командеры, менюшки, либы как в вашем случае, вторая страница используется под ТРДОС, третьи 16кб используется под бейсик 128, который часто меняют опять же на командеры или какой-то альтернативный менюшке софт, и последняя 4я страница это прошивка бейсик 48кб для 128 машин, его менять само собой нельзя. т.е. если разобраться в вашем распоряжении могут быть две страницы по 16 кб - это 1я и 3я (считаем с 1й).

[b2m]

ну ПЗУ ставят на самом деле 64кб (27С512)

Ой, пардон, разрядность зашкалила

---------- Post added at 22:34 ---------- Previous post was at 22:30 ----------

Ту страницу, что под бейсик 128, мы уже используем как часть ядра. Остаётся самая первая страница (её обычно вроде reset service называют?)

[Sergey]

Я, конечно, не отказываюсь от идеи переписать либы на асме, но всё-таки. Может быть попробовать скомпилить FUZIX IAR`ом?
Кстати, кто-нибудь объяснит, где взять правильный stdint.h и почему его нет в дистрибутиве?

[Eltaron]

Я, конечно, не отказываюсь от идеи переписать либы на асме, но всё-таки. Может быть попробовать скомпилить FUZIX IAR`ом?

Муторно это, всю инфраструктуру переделывать надо. И все .s фиксить.

Кстати, кто-нибудь объяснит, где взять правильный stdint.h и почему его нет в дистрибутиве?

Это часть sdcc. /opt/sdcc/include

[Sergey]

Это часть sdcc. /opt/sdcc/include

Досадно. В IAR такого файла нет.