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

Вид для печати

30.11.2013, 01:52
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
30.11.2013, 09:34
jerri

поддержка всего этого тебе где нужна?
30.11.2013, 10:15
Hacker Grey

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

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

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

Хорошо
1 будут ли эти возможности поддержаны на стандартном спеке?
2 кто будет писать под эти возможности?
30.11.2013, 11:46
Hacker Grey

Цитата:

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

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

Цитата:

кто будет писать под эти возможности?

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

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

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

ну вобщем ты хочешь пойти по пути ИБМ
и поддержать старые раскладки на новом железе.
это уже было
придумай новое.
30.11.2013, 12:07
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 это могли в самом начале)
30.11.2013, 12:30
Hacker Grey

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

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

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

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

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

Цитата:

при этом обижаешься на конструктивную критику

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

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

Цитата:

Сообщение от Hacker Grey

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

Чего-то ни разу не останавливало) Нехватка общей памяти - да, но ее сегментация - нет.
30.11.2013, 15:32
psb

Цитата:

Сообщение от Hacker Grey

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

голосую: мне это не надо.
30.11.2013, 16:27
ZEK

Цитата:

Сообщение от Hacker Grey

я предлагаю, очень облегчит жизнь программистам

в атм никто всовывать не будет, сильно компр резать надо, в ts-conf места нет, остается только baseconf, спроси у lvd что он думает о этой идее, откроешь новый мир
30.11.2013, 18:25
psb

Цитата:

Сообщение от ZEK

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

:v2_lol:
30.11.2013, 19:51
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 байтов стека в зависимости от разрядности, которые всегда можно найти и которые критической роли не сыграют. Если, конечно, не увлекаться рекурсией. Но если ей увлекаться, то стек выжирает мегабайты.
30.11.2013, 20:24
Alex Rider

Цитата:

Сообщение от haywire

Зачем сегмент стека вообще нужен - никогда не понимал.

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

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

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

Цитата:

Сообщение от haywire

Человечески написанная программа не требует более 256-512-1024 байтов стека в зависимости от разрядности

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

Цитата:

Сообщение от psb

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

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

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

Цитата:

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

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

Цитата:

Сообщение от haywire

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

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

Цитата:

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

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

Цитата:

Сообщение от haywire

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

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

Цитата:

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

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

Цитата:

Сообщение от haywire

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

Код:

#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 - несовременный компилятор", ожидаю примеры генерации кода с упомянутой оптимизацией и указанием используемого компилятора и его версии.
30.11.2013, 21:57
Hacker Grey

Цитата:

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

Да - эту историю знаю.

Цитата:

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

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

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

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

Цитата:

Сообщение от Titus

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

именно так.

Цитата:

Сообщение от haywire

А ребята, которые пишут

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

Цитата:

Сообщение от haywire

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

Если идёт речь о простой программе, то чаще всего да, так и есть, а, например, если мы говорим о ядре ОС, то как обеспечить реентерабельность? Хранить в структурах подобных стеку - один из вариантов. Насколько я знаю, msdos большую часть переменных хранит именно так.
11.12.2013, 20:38
Barmaley_m

Цитата:

Сообщение от Hacker Grey

Ну что ? Как вам идея? Возможно все это реализовать?

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

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

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

Цитата:

Сообщение от Hacker Grey

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

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

Цитата:

Сообщение от haywire

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

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

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

Цитата:

Сообщение от haywire

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

Почему это? Что ты предлагаешь делать, если нужен временный массив на 60 (или даже 6000) килобайт? malloc? Так это же неэффективно. Работа менеджера кучи сложнее, чем стека, и впоследствии возможна фрагментация памяти. Для подобных применений стек лучше.
16.12.2013, 18:41
Lethargeek

Цитата:

Сообщение от Barmaley_m

если нужен временный массив на 60 (или даже 6000) килобайт?

Если он действительно такой нужен, то и времени на обработку потратишь столько, что работа с ним менеджера кучи будет просто незаметна и ничтожна на этом фоне.
16.12.2013, 23:14
psb

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

короче, неоднозначный выбор.
18.01.2015, 12:31
Nesser

А разве правильный стёк бывает больше 500 байт ? :)
18.01.2015, 22:37
shurik-ua

Цитата:

Сообщение от bigral

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

а можно поподробнее - сколько регистров и какие преобразования с адресом происходят ?
18.01.2015, 23:45
bigral

Цитата:

Сообщение от shurik-ua

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

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

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

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