Введение сегментов стэка и данных.

[Hacker Grey]

Уже давно не ново использование диспетчера памяти с подключением любой 16 кб страницы в любое окно адресного пространства. Когда то на ZX128 о таком диспетчере только мечтали, но АТМ2, Cпринтер, PentEvo сделали такие режимы адресации обыденными. Однако кто пробовал их использовать в реальных программах, осознавали? что использовать все преимущество от них все время что то мешает. То стэк, то малый размер одной страницы для кода. То обработчики прерываний. А ведь если задуматься, то все упиралось в объем адресуемой памяти z80 - все те же 64к.
В свое время, осваивая ассемблер 8086 я замечал, как много общего у него с z80. И вроде z80 может почти все тоже самое. Я даже назвал бы z80 не 8-битным а полу 16-битным процессором, так как он вполне спокойно справляется с 16 битными арифметическими командами. И тут напрашивается мысль, которая давно веяла. но её всегда отгоняли, думая что это невозможно в принципе, потому что не может быть. Чего не хватает для адресации более чем 64к ? Сегментных регистров. Но их то мы в реальный z80 ни как не впихнем, а переходить на другой тип процессора - это уже сильный шаг в сторону от концепции Спектрума.

И вот у меня такие вопросы для программистов конфигураций на Альтере. Возможно ли то что я предлагаю? и на сколько вам эта идей кажется интересной?

Вопрос. Может ли Альтера отловить коды команд (например опросить шину данных при М1)? Я думаю что по этому принципу сделан ускоритель в Спринтере.
Если это возможно, то есть такая идея, - ввести в конфигурацию режим сегментации. 2 сегмента данных для IX IY и сегмент стэка для SP.
Это сделало бы удобным и быстрым программирование при обработке больших объемов данных. А если возможно отловить работу со стэком, то и упростило бы написание многозадачных ОС.

Понадобится 12 портов (при жесткой 16 бит дешифрации, думаю не проблема)
4 порта - карта памяти для IX
4 порта - карта памяти для IY
4 порта - карта памяти для SP

можно не порты, а разместить ячейки их в диспетчере памяти.
При обработке команд чтения/записи памяти (с косвенной адресацией) через сегментные регистры IX, IY обращаться не к основной карте памяти, а к страницам,указанным в этих портах.
Ну и если это возможно, то вообще было бы супер отследить работу со стэком и подставлять тоже свою карту памяти.


Прошу не пинать за столь изощренную идею.
Просто представьте, что в этом режиме z80 адресует сразу 256 кб адресного пространства.
64 основные, 64 через IX, 64 через IY, 64 через SP. И это все сразу одновременно без щелканья страниц.

1. Нужно будет отловить все команды работы со стэком (pop push), команды вызова подпрограмм call, rst и возвратов из прерываний, ну и циклы обработки прерывания.
2. отловить команды ld a/r,(ix/iy+n), ld (ix/iy+n),a/r , и арифметические add/adc/sub/sbc a,(ix/iy+n) , inc/dec работы с битам.
В общем тут, думаю надо плясать от префиксов при M1 , и кода операции, что бы отловить только косвенную адресацию, а не загрузку в сами регистры ix, iy.

Думаю памяти альтеры должно хватить, И при выявлении закономерности в отлавливаемых командах (по маске) проверок будет не так уж и много.
На акслератор спринтера ушло не меньше проверок.

Ну и естественно этот режим расширенной адресации должен программно включаться и отключаться.

Ну что ? Как вам идея? Возможно все это реализовать?
А иначе смысл всяких супер видеорежимов, аппаратных спрайтов и тд, если процессор не видит сразу все адресное пространство видеопамяти?

З.Ы. Ну и буду совсем наглым, раз уж пошла такая пьянка, то можно ещё до кучи и обработать команды LDI и LDIR - сделать перед ними префекс из неиспользуемых команд, что бы чтение шло их сегмента IX а запись в сегмент IY

[jerri]

поддержка всего этого тебе где нужна?

[Hacker Grey]

В смысле ?
Аппаратная ? Хотелось бы во всех конфигурациях с 4-мя окнами
атм, эво, ts. Везде где возможно реализовать. Т.Е. я предлагаю разработать и ввести стандарт реального режима адресации 256кб.

Программная, где будет полезна? Это просто сделает более гибким и удобным программирование. Ну например:
За стековый сегмент скажут спасибо, кто будет писать диспетчер быстрого переключения задач или резидентные подпрограммы. У любой библиотеке (например резидентной в 0 банке и переключающей все страницы) возникнет заминка со стэком. Нужно будет потратить кучу тактов на определение - в каком окне стэк.

А сегменты данных вообще везде, даже в простом блокноте - ограничение текста 64 кб. Но при его редактировании если он разбит на банки по 16 кб, возникает вопрос раздвигания текста. Приходится извращаться, через буфер в другом банке перебрасывать весь текст.
При обработке Сэмплов в редакторе MOD-ов или s3m. Там по стандарту ограничение сэмпла - 64 кб. Как ого через 16 кб окошки листать, удобно? А так ерз один регистр доступпен сразу весь сэмпл. Сколько времени сэкономим на проверке на переход граница окна в 16кб ?
А работа с большими экранами, занимающими более 16 кб? При такой адресации видеопамять можно вообще не подключать в общие окна. Т.е все 64 к могут быть заняты линейным кодом программы, данные в сегменте IX, экран в сегменте IY, как угодно их перекидываем туда сюда и не боимся запороть стэк.

[jerri]

Хорошо
1 будут ли эти возможности поддержаны на стандартном спеке?
2 кто будет писать под эти возможности?

[Hacker Grey]

1 будут ли эти возможности поддержаны на стандартном спеке?
В теории это возможно, если подвесить дешифратор команд и машинных циклов (например на альтере) На практике - конечно же нет, как и любая страница в любые 4 окна. и куча доп.графических режимов.

кто будет писать под эти возможности?
Если их ввести в актуальные сейчас конфигурации, то все кто пишут под zxevo, реверс, смогут их использовать, А один раз попробовав - уже не оттащишь.

Для экономии логики можно можно уменьшить количество дешифруемых команд.
например вводится 2 префекся дальней адресации (для двух сегментов) из двух команд (неиспользуемых типа ld l,l) и любая следующая команда читает/пишет в сегментную страницу.
Со стэком и прерываниями конечно сложнее. Но там тоже есть закономерность.
Все Push и Pop call & ret & rst проверяются одной маской 11xxxxxx ,
ну и отловить запись в стэк при int/nmi

Режим стандартно спектрума ни кто не отменял.
А чем аппаратные спрайты, адресация 4 окон, 256 цветов на точку лучше ?
И все эти навороты с адресаций только в 64к очень неудобно программировать.

[jerri]

ну вобщем ты хочешь пойти по пути ИБМ
и поддержать старые раскладки на новом железе.
это уже было
придумай новое.

[bigral]

Предлагается сделать из z80 проц недо8088-Z80. Если рассмотреть историю вопроса то подобная проблема стояла перед DEC-ом в 1972-ом и они её решили применив две разных концепции воплощенных в 1975 году в pdp-11/70 с его MMU (преобразование старших разрядов шины адреса в большее количество адресных сигналов через таблицу размещенную в статическом ОЗУ видимую как спец-регистры процессора) и I/D (разделение памяти на instruction/data сегменты, эта идея из гарвардской архитектуры, она позволяет расширить в 2 раза ОБЩЕЕ адресное пространство но не каждое по отдельности).

Идея проверенная intel-ом на том же i8088, считаю её глупой и "странной", видимо они думали убить сразу 2-х зайцев и получить что-то среднее дающие преимущества и MMU и I/D... оказалось что простого варианта использования сегментных регистров просто нет! и это наложило свой дикий отпечаток и на программы и на железо в последующие годы. Дошло до анекдота, когда в 386-ом сделали возможность обьявить сегменты размером в полное физически адресуемое пространство то эту фичу обьявили не иначе как прорыв и супер достижение и профанация достигла апогея. Наконец-то проц смог адресовать напрямую всю память... (никакой маркетолог естественно не заметил что i8080 так же как и pdp11/20 это могли в самом начале)

[Hacker Grey]

Понятно - закидали камнями и палками.
Давайте будем продолжать мучится со страницами по 16к.
И накладывать ограничения в эти 16к на все форматы.
Хочется написать редактор MOD - на тебе ограничение сэмпла в 16к хотя в стандартном - 64, хочется простой текстовый редактор - на тебе ограничение текста в 16к. Хочется в расширенном графическом режиме вывести картинку сразу на весь экран, на тебе окно в 16к. и листай его потихоньку.

Конечно что с этим всем тоже можно жить, устраивать кучи проверок на пересечение границ страниц, тормозить при сэмплировании, при раздвигании текста. Но как ещё кроме сегментов раздвинуть адресуемое пространство?
В предлагаемом варианте сразу адресуем 256 к. Можно уже и звуки красивые обрабатывать и картинки большие. А без этого и ZX48к за глаза хватало - самая логичная и проста адресация.

[jerri]

Hacker Grey, ты не предлагаешь ничего нового.
Если у тебя есть какие то свежие идеи ты можешь реализовать их написав собственную конфигурацию, как это сделал ТС Лаб.

Она может быть как совместимой со спеком, так и несовместимой. Причем если несовместимой то тогда можешь в ней реализовать самые сокровенные фантазии. Новый суперэффективный проц, видеосистема эталонного вида.

А ты предлагаешь к паровозу скотчем приклеить крышки от кастрюль и назвать это самолетом. И при этом обижаешься на конструктивную критику. Баловство это.

[Hacker Grey]

при этом обижаешься на конструктивную критику
Как и большинство авторов, я считаю свою идею гениальной и думаю что она просто должна сразу всех восхитить.

А серьезно - то что я предлагаю, очень облегчит жизнь программистам, которых часто останавливают перед началом чего нибудь интересного эти ограничения в 16кб.
На счет - написать сам - да запросто, но я предлагаю введение стандарта и разработку его на общее обсуждение. Писать одному для себя уж слишком грустно.

[Titus]

А серьезно - то что я предлагаю, очень облегчит жизнь программистам, которых часто останавливают перед началом чего нибудь интересного эти ограничения в 16кб.
Чего-то ни разу не останавливало) Нехватка общей памяти - да, но ее сегментация - нет.

[psb]

А серьезно - то что я предлагаю, очень облегчит жизнь программистам, которых часто останавливают перед началом чего нибудь интересного эти ограничения в 16кб.
голосую: мне это не надо.

[ZEK]

я предлагаю, очень облегчит жизнь программистам
в атм никто всовывать не будет, сильно компр резать надо, в ts-conf места нет, остается только baseconf, спроси у lvd что он думает о этой идее, откроешь новый мир

[psb]

откроешь новый мир
:v2_lol:

[haywire]

В свое время, осваивая ассемблер 8086 я замечал, как много общего у него с z80.


ЛОЛ ! А знаете ли вы, что создатели Z80 - бывшие топ менеджеры Intel, не поделившие что-то и создавшие отдельную кампанию ? Было бы странно, если бы Z80 не был бы слегка модернизированной копией i8080, а 8086 не взял бы что-то от предшественника.



Я даже назвал бы z80 не 8-битным а полу 16-битным процессором, так как он вполне спокойно справляется с 16 битными арифметическими командами.


Это терминологически неверно. Разрядность процессора - это разрядность его машинного слова. 486-й процессор справляется с 80-и битными операндами, это не делает его 80-и разрядным процессором.



быть. Чего не хватает для адресации более чем 64к ?


20-и битной шины адреса процессора.

/thread.

---------- Post added at 19:51 ---------- Previous post was at 19:21 ----------



и сегмент стэка для SP.


Чисто пофлеймить :-) Зачем сегмент стека вообще нужен - никогда не понимал. Человечески написанная программа не требует более 256-512-1024 байтов стека в зависимости от разрядности, которые всегда можно найти и которые критической роли не сыграют. Если, конечно, не увлекаться рекурсией. Но если ей увлекаться, то стек выжирает мегабайты.

[Alex Rider]

Зачем сегмент стека вообще нужен - никогда не понимал.
У 8086 он нужен был потому что указатель стека был 16-битный, а адресация памяти - 20-битная. Иначе стек мог бы жить только в первых 64 Кб. В защищинном режиме он нужен для того, чтобы не натолкать туда код и не запустить его. В идее ТС он мог бы пригодиться для копирования стеком в неактивную в данный момент область памяти.

---------- Post added at 20:24 ---------- Previous post was at 20:24 ----------

Ну и да - рекурсивные алгоритмы тоже имеют право на жизнь.

[psb]

Человечески написанная программа не требует более 256-512-1024 байтов стека в зависимости от разрядности
да-да, а 640 кило хватит всем. куда девать локальные переменные? в кучу складывать?

[haywire]

да-да, а 640 кило хватит всем. куда девать локальные переменные? в кучу складывать?


Локальных переменных много не надо. Человеческий мозг не мыслит так. Я анализировал размер стека. Более ~256 байт при 16-и разрядном коде не надо, надо значительно меньше.

---------- Post added at 21:10 ---------- Previous post was at 21:08 ----------



Ну и да - рекурсивные алгоритмы тоже имеют право на жизнь.


Имеют. Наверное. Но им не хватает стека и на современном железе. Из чего я делаю вывод, что не имеют они права на жизнь нифига.

[Alex Rider]

Из чего я делаю вывод, что не имеют они права на жизнь нифига.
Вы не любите собак? Да вы просто не умеете их готовить!

[haywire]

Вы не любите собак? Да вы просто не умеете их готовить!


Да я много чего не умею. Но восхищение возникает от людей, которые умеют. Вот людей (программ), умеющих эффективно использовать рекурсию, я не видел пока что. Только эпические падения *****кода.

[Titus]

Локальных переменных много не надо. Человеческий мозг не мыслит так. Я анализировал размер стека. Более ~256 байт при 16-и разрядном коде не надо, надо значительно меньше.

Должно быть, psb имел ввиду программы, скомпилированные с языков высокого уровня (например, Си), где локальные переменные с динамически выделяемой для них памятью (из стека) в порядке вещей.
Тогда как для обычного ассемблериста пишущего под Z80 (и другие восьмибитки) такой подход неудобен. Индексной адресации по стеку нет, да и вообще ассемблерщики мыслят иначе.

[haywire]

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


Не. Локальных переменных много не надо. А ребята, которые пишут
int func (a)
char a;
{
int b[60000];
}
- должны гореть в аду. Но в аду им не позволит гореть современный компилятор. Он выправит этот код. Можете проверить.

[Vitamin]

Но в аду им не позволит гореть современный компилятор. Он выправит этот код. Можете проверить.


#include <stdio.h>

int func (a)
char a;.
{
int b[60000];
int i;
for (i =a; i != 60000; ++i)
printf("%i: %c\n", i, b[i]);
}

int main()
{
a('a');
}




gcc -O2 -c test.c
objdump -d -M intel test.o




Дизассемблирование раздела .text:

0000000000000000 <func>:
0: 53 push rbx
1: 40 0f be df movsx ebx,dil
5: 48 81 ec 80 a9 03 00 sub rsp,0x3a980
c: 0f 1f 40 00 nop DWORD PTR [rax+0x0]
10: 48 63 c3 movsxd rax,ebx
13: 89 de mov esi,ebx
15: bf 00 00 00 00 mov edi,0x0
1a: 8b 14 84 mov edx,DWORD PTR [rsp+rax*4]
1d: 83 c3 01 add ebx,0x1
20: 31 c0 xor eax,eax
22: e8 00 00 00 00 call 27 <func+0x27>
27: 81 fb 60 ea 00 00 cmp ebx,0xea60
2d: 75 e1 jne 10 <func+0x10>
2f: 48 81 c4 80 a9 03 00 add rsp,0x3a980
36: 5b pop rbx
37: c3 ret

Дизассемблирование раздела .text.startup:

0000000000000000 <main>:
0: bf 61 00 00 00 mov edi,0x61
5: 31 c0 xor eax,eax
7: e9 00 00 00 00 jmp c <main+0xc>




gcc версия 4.8.2 (GCC)


Дабы предотвратить разговоры в стиле "gcc - несовременный компилятор", ожидаю примеры генерации кода с упомянутой оптимизацией и указанием используемого компилятора и его версии.

[Hacker Grey]

А знаете ли вы, что создатели Z80 - бывшие топ менеджеры IntelДа - эту историю знаю.

20-и битной шины адреса процессора.
но я и предлагаю это проэмулировать.
Вы поймите что 8086 тоже адресует одновременно не 1мб. а 64к помноженное на количество сегментных регистров CS, DS, SS ES = 256кб. А дальше ему нужно модифицировать эти регистры.
Тоже самое получится и у нас - адресуемые сразу 256 кб. а через модификацию этих регистров - хоть все 4мб.

[jerri]

Hacker Grey, авторы процессоров з80 и8080 мос6502 сидели и считали такты, логические элементы и эффективность своих устройств.

может лучше сразу создать на основе ZXEvo устройство с 24 битной адресацией?
а не городить кадавров?

[psb]

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


А ребята, которые пишут
это утрированный пример. а на деле почему не может быть нескольких лок. массивов байт на 500? как их делать, если они нужны? а если вложенность подпрограмм приличная? всяко может быть.

[Vadim]

Человечески написанная программа не требует более 256-512-1024 байтов стека в зависимости от разрядности, которые всегда можно найти и которые критической роли не сыграют.
Если идёт речь о простой программе, то чаще всего да, так и есть, а, например, если мы говорим о ядре ОС, то как обеспечить реентерабельность? Хранить в структурах подобных стеку - один из вариантов. Насколько я знаю, msdos большую часть переменных хранит именно так.

[Barmaley_m]

Ну что ? Как вам идея? Возможно все это реализовать?
Конечно, возможно. Не вы первый, кому эта идея пришла в голову. Я думал о подобной надстройке еще в 1995-96 годах где-то. Тогда еще ФПГА массово не использовались - думал делать логику на ЛА3 и РТ4.

Основной довод "против" уже высказал Jerri: сделать подобную аппаратную довеску несложно. Ну, месяц потрудишься - и получится в конце концов. Но проблема ведь не в аппаратуре. Проблема в софте, которого под эту конфигурацию нет. На создание софта уйдет значительно больше человеко-часов, чем на создание аппаратной части. У вас есть столько времени и желания писать софт? А если нет у вас лично - может кого-нибудь знаете, у кого есть?

С тем же успехом можно заменить Z80 каким-нибудь 32-битным процессором. И все, проблемы с адресацией уйдут. Почему никто этого не делает? А если кто и делает, то такие компы уже не назваются "Спектрумами"? В чем тут принципиальная разница - взять совершенно другой проц или оставить прежний, но приделать к нему кучу костылей? Для программистов-то между этими двумя вещами разницы нет. Старые программы не смогут поддерживать новые возможности.

З.Ы. Ну и буду совсем наглым, раз уж пошла такая пьянка, то можно ещё до кучи и обработать команды LDI и LDIR
Тогда уж лучше сделать аппаратный ускоритель блочной пересылки или, еще лучше, - блиттер, как на Амиге, который обрабатывает прямоугольные блоки. Ведь LDI и LDIR жутко медленные. Даже если составить последовательность чтения-записи памяти на шине Z80 из трехтактовых циклов, т.е. минимального времени, за которое Z80 может обратиться к памяти, то получится 6 тактов на пересылку байта - против 16 для LDI или 21 для LDIR.

Вот людей (программ), умеющих эффективно использовать рекурсию, я не видел пока что. Только эпические падения *****кода.
Сочувствую. Я видел и хорошие примеры использования рекурсии, и сам ее иногда использовал с большой эффективностью.

Рекурсия иногда нужна. Как и любой другой инструмент, она занимает свое место в мастерской программиста. При использовании ее по назначению все прекрасно - и у программиста, и у компьютера. Стек не переполняется. А не по назначению - это как гвозди забивать микроскопом. Конечно, получается фиаско.

Не. Локальных переменных много не надо. А ребята, которые пишут
int func (a)
char a;
{
int b[60000];
}
- должны гореть в аду.
Почему это? Что ты предлагаешь делать, если нужен временный массив на 60 (или даже 6000) килобайт? malloc? Так это же неэффективно. Работа менеджера кучи сложнее, чем стека, и впоследствии возможна фрагментация памяти. Для подобных применений стек лучше.

[Lethargeek]

если нужен временный массив на 60 (или даже 6000) килобайт?
Если он действительно такой нужен, то и времени на обработку потратишь столько, что работа с ним менеджера кучи будет просто незаметна и ничтожна на этом фоне.

[psb]

вот только на стеке оно точно автоматом удалится при выходе, а про кучу можно забыть. +память в куче фрагментируется.

короче, неоднозначный выбор.

[Nesser]

А разве правильный стёк бывает больше 500 байт ? :)

[shurik-ua]

(преобразование старших разрядов шины адреса в большее количество адресных сигналов через таблицу размещенную в статическом ОЗУ видимую как спец-регистры процессора)
а можно поподробнее - сколько регистров и какие преобразования с адресом происходят ?

[bigral]

а можно поподробнее - сколько регистров и какие преобразования с адресом происходят ?

мы уже обсуждали это в тругой ветке начиная с поста http://zx-pk.ru/showpost.php?p=710767&postcount=55

[AzAtom]

256 КБ сразу вроде хорошо, но почему вы думаете, что это будет быстрее и удобнее?
Во первых, я не смогу туда разместить картинку даже 200 КБ, а если и размещу то всё равно буду думать "так, 64 КБ с этого поля скопировал, теперь следующие 64 КБ надо с другого".
Во вторых, если хватит 64 КБ в одном поле через IX, например, то это постоянное использование команды с префиксом, что замедляет работу программы и известными приёмами не ускорить то же копирование. Думаю, будет не быстрее, чем работа с окнами 16 КБ. Насчёт удобства тоже можно поспорить.

В общем случае расширение адресов, кроме как, через окна сложно сделать и менее эффективно. Ну разве что, отдельный 64 КБ блок для стека кому-то может пригодиться. Лучше тогда сделать либо окно 32 КБ, либо 2 окна по 16 КБ, тогда будет чуть проще работать.