Проект ОС

[NovaStorm]

>с чипом R800 летает. изучите для начала суть вопроса...
Я пробовал в blueMSX ставить 20МГц R800, тормозил даже вывод в консоль. Может конечно, я её готовить не умею, за реальной MSX только раз сидел.

[Advertiser]

[Sayman]

в blueMSX даже при эмуляции MSX2+ с частотой 10мгц достаточно быстро работает. при эмуляции турбоР на тех же частотах летает. естественно, что я ставил юзикс на винт. с дискеты ясно понятно тормоз...
а вапще ваше дело..продолжайте спорить.

[impressed]

>и эмуляцией старых стандартов для Legacy-систем
У пентэвы, которая и есть наверное самый раскрученный и актуальный стандарт, ведь уже есть 4 банка по 16к, мельчить до 4к наверное уже не стоит. Да и другие машины тоже 16к банками пользуются. Меньшие страницы только в менеджере памяти нужны будут.

16k многовато, или надо строить дополнительный слой абстракции на уровне самой ОС, т.е городить аллокатор памяти, запоминающий текущее состояние распределения памяти ( в принципе почему бы и нет, не такой уж и плохой вариант кстати).

Был у меня проект, там пришлось несколько модифицировать компилятор C, чтобы тот вместо непосредственного обращения к RAM дергал функцию из самопальной RTL которая и работала с блоками выделенной памяти. В этом случае, максимально адресуемый объем памяти ( под данные, а возможно и под код) ограничивается только полетом фантазии разработчика. Физически, мы работаем с куском памяти 4-16kB отображенным диспетчером памяти в адресное пространство CPU, движение этого окна прозрачно для программы ( в обе стороны, как вверх так и вниз, т.к она использует относительную адресацию в пределах -32768 + 32767 байт от текущей точки исполнения), правда нужно запоминать несколько предыдущих положений окна отображения, но на это я отводил место в системном контексте ( где и сохранял регистры, положение указателя стека и программного счетчика) который обслуживается ядром ОС.

[alone]

impressed, как примерно выглядел код a[i] и код вызова функции?

[impressed]

impressed, как примерно выглядел код a[i] и код вызова функции?

надо глянуть в моих архивах...

это был GCC я модифицировал RTL-представление, в той частии где генерируется код для адресации через База[Смещение].
1. Загрузка из памяти в регистр-назначения (mov REG, word ptr VAR[OFFS] в нотации для x86) заменяло на( примерный код, пишу по памяти)
push bx
push si
push ax
mov bx,<segaddr>
mov si,<offset>
mov ax,<val16>
call getData16 ; На выходе в AX наше слово из памяти
mov REG,ax
pop ax
pop si
pop bx

У функции записи слова в память по адресу X сигнатура аналогична только название другое
Сами функции я положил в crtbegin.o который GCC при линковке автоматом добавляет в бинарник.

[bigral]

impressed, как примерно выглядел код a[i] и код вызова функции?

Могу сказать что я видел подобную реализацию в Watcom C для модели HUGE, было года 4 назад, я брал openwatcom и генерил в asm простую прогу типа:

int main() {
  int i[500000];
  for (long j=0; j<500000; j++) {i[j] = 0xff;}
  return 0;
}

выяснилось что все указатели компилер держит 32bit-ные и в теории он вообще бы мог адресовать аж 4GB таким способом (физически там будь бы у него EMS до 32Mb мог бы поддержать, а если применить HDD swap!!! ) но логика работы с указателями точно как у самого контроллера шины i8086 (т.е. к старшему 16bit слову дописывается справа 4bit-а нулей, полученное число складывается с младшим словом формируя 20bit-ный адрес)

[alone]

Для Спектрума тормозновато получится. Надо чтобы компилятор находил случаи перебора элементов массива (как?) и генерил что-то вроде INC L:CALL Z,nextseg
Где nextseg делает INC H и по необходимости переключает странички.

[impressed]

Для Спектрума тормозновато получится. Надо чтобы компилятор находил случаи перебора элементов массива (как?) и генерил что-то вроде INC L:CALL Z,nextseg
Где nextseg делает INC H и по необходимости переключает странички.

C перебором по идее тоже проблем нет. Можно использовать 32-битные смещения, а расчеты возложить на getData. Также можно на стадии работы с AST определять с чем мы имеем дело ( типы токенов хранятся в AST) и если это массив то менять поведение.

[bigral]

alone, ей богу интересовался этим вопросом последние лет 10 (в более широком смысле - как компилировать "современные исходники" рассчитанные на мегабайты памяти для систем с ограниченным в 64кб адресным пространством) и пришел к выводу что есть некие подходы которые впрочем все трудоемкие:

Радикальный (требующий от программиста переписать 32bit исходник): отказаться от идеи работы с 32bit виртуальным пространством и переделать все алгоритмы на работу с куском памяти который гарантированно есть, использовать внешнюю память для временного хранения обработанных данных если они сильно большие. Так работает hitech c в CP/M, результат хороший он в процессе компиляции пишет на диск много временных файлов и может обрабатывать очень длинные исходники. Так работает немецкая MODULA2 для pdp11 систем, которая зная что размер страницы у pdp11 максимум 4kW никогда не дает обьявлять массивы большей длинны и никогда не генерит код более 4kW длинны. Передача параметров между вызовами функций как я понимаю идет тоже блоками с максимальной длинной 4kW. У pdp11 MMU есть 8 окон по 4 kW так что если все алгоритмы подогнать под работу с кусками в 4kW то можно легко довольно использовать все адресуемые 2mW. Обязательно использовать оверлеи суть которых не поменялась со времен первых mainframe-ов IBM у которых тоже было маленькое адресное, т.е. link-ер exe-шника вставляет код диспечера вызовов(этот код естественно может использовать MMU на полную катушку и внешний swap-file) и использует файл-overlay-map который ему показывает на какое место какой obj помещается и кто кого перекрывает в каких адресах\страницах. Все эти оверлейные технологии достигли вершины на pdp11 в тех же 2.9BSD 2.11BSD ну и Демос (среди разработчиков которого считалось что "нормальная" программа должна превышать в 5...6 раз виртуальное адресное пространство pdp11 а иначе это так себе, слабенькая утилитка а не программа).

Традиционный: подключение наружных 32bit risc сопроцессоров (пример - интерфейс TUBE на Acorn BBC model B к которому можно вешать "second processor option"), при этом естественно основной комп используется уже как terminal и I/O co-processor или расширение основного процессора другим с большим виртуальным адресом (пример - vax-11/780, appleIIGS, amd64 и т.д.)

---------- Post added at 17:29 ---------- Previous post was at 17:19 ----------

Для Спектрума тормозновато получится. Надо чтобы компилятор находил случаи перебора элементов массива (как?) и генерил что-то вроде INC L:CALL Z,nextseg
Где nextseg делает INC H и по необходимости переключает странички.

Оно и для i8086 у них тормознуто вышло, так как все операции с указателями в модели HUGE требуют пересчета через "целую функцию", для сравнения работа с near указателями это обычные inc, dec, add команды или смещения с иcпользованием index-ных регистров.

[shurik-ua]

по теме интересное чтиво - http://habrahabr.ru/post/228049/