Отлаживал урезанный вариант ls, нашёл неслабую ошибку в библиотеке. Файл readdir.c должен оканчиваться так:
Раньше обнулялся байт по смещению len-1, в результате портилась цепочка свободной памяти.Код:strncpy(buf->d_name, (char *) direntry.d_name, len - 2);
buf->d_name[len - 2] = 0;
return buf;
Прикладываю также свои варианты ssh и ls. Шелл на пару Кб больше, чем у SfS, зато функциональность не пострадала. В ls закомментировал сортировку и вывод времени.
Ого, классная бага! Запушил Алану http://github.com/EtchedPixels/FUZIX/pull/22Цитата:
Сообщение от b2m
Если честно, я бы вместо len-2 поставил константу MAXNAMLEN - и быстрее, и надёжнее. Мало ли что вернёт система :) Сейчас она всегда возвращает 32.
Глядя на то, как медленно и печально грузится ls, мне пришла в голову мысль, что основную часть библиотеки libc нужно бы разместить в ПЗУ. Варианта, естесственно, три:
1. вместо BASIC48
2. вместо TRDOS
3. вместо RESET SERVICE
В первом варианте теряем возможность запускать игрушки, во втором - запускать дисковые игрушки, третий вроде подходит, но нужно будет обращаться через 3Dxx, к тому-же будут открыты порты BDI.
Что думает по этому поводу уважаемый Eltaron? :)
Я ничего не знаю про RESET SERVICE, но идея разделяемой либы, конечно, хорошая. С точки зрения маппинга будут проблемы - нужно сохранять/восстанавливать не только страницу ОЗУ, но и ПЗУ. Но это решаемо.Цитата:
Сообщение от b2m
У меня была другая идея - выделить под либу одну из страниц ОЗУ. Но тут не только с маппингом пришлось бы попрыгать, но и с вызовом библиотечных функций. Новый RST городить, или ещё какую-нибудь точку входа ниже #C000.
Это когда ставятЦитата:
Сообщение от Eltaron
256Кб64Кб ПЗУ, в которой и BASIC48, и BASIC128, и TRDOS в одной м/с. Насколько я понял, там остаётся ещё одна свободная страница, которая включается после сброса, если BDI настроен на автоматическое включение TRDOS после сброса.
Там всё просто: для ядра - ядро, для режима пользователя - либа. RST, конечно, надо в либе реализовать, также как и обработку прерывания в режиме пользователя.Цитата:
Сообщение от Eltaron
А как быть с адресами данных, которые по любому в другой странице ОЗУ вместе с программой?Цитата:
Сообщение от Eltaron
У меня была аналогичная идея, но я думал освободить непереключаемое ОЗУ для libc и других разделяемых библиотек, практически полностью перенеся ядро в переключаемые страницы. Много занимают буфера, но перенеся их в другие страницы мы усложняем загрузку файлов в область программы. А если, например, код ядра и буфера будут в разных страницах, то тут могут другие сложности возникнуть.
Вобщем libc в ПЗУ - наиболее простое решение.
ну ПЗУ ставят на самом деле 64кб (27С512), 4 страницы по 16кб. первые 16 кб или свободны или используются под свои нужды - командеры, менюшки, либы как в вашем случае, вторая страница используется под ТРДОС, третьи 16кб используется под бейсик 128, который часто меняют опять же на командеры или какой-то альтернативный менюшке софт, и последняя 4я страница это прошивка бейсик 48кб для 128 машин, его менять само собой нельзя. т.е. если разобраться в вашем распоряжении могут быть две страницы по 16 кб - это 1я и 3я (считаем с 1й).Цитата:
Сообщение от b2m
Ой, пардон, разрядность зашкалила :)Цитата:
Сообщение от solegstar
---------- Post added at 22:34 ---------- Previous post was at 22:30 ----------
Ту страницу, что под бейсик 128, мы уже используем как часть ядра. Остаётся самая первая страница (её обычно вроде reset service называют?)
Я, конечно, не отказываюсь от идеи переписать либы на асме, но всё-таки. Может быть попробовать скомпилить FUZIX IAR`ом?
Кстати, кто-нибудь объяснит, где взять правильный stdint.h и почему его нет в дистрибутиве?
Муторно это, всю инфраструктуру переделывать надо. И все .s фиксить.Цитата:
Сообщение от Sergey
Это часть sdcc. /opt/sdcc/includeЦитата:
Кстати, кто-нибудь объяснит, где взять правильный stdint.h и почему его нет в дистрибутиве?