Вид для печати
Должно быть, psb имел ввиду программы, скомпилированные с языков высокого уровня (например, Си), где локальные переменные с динамически выделяемой для них памятью (из стека) в порядке вещей.Цитата:
Сообщение от haywire
Тогда как для обычного ассемблериста пишущего под Z80 (и другие восьмибитки) такой подход неудобен. Индексной адресации по стеку нет, да и вообще ассемблерщики мыслят иначе.
Не. Локальных переменных много не надо. А ребята, которые пишутЦитата:
Должно быть, psb имел ввиду программы, скомпилированные с языков высокого уровня (например, Си), где локальные переменные с динамически выделяемой для них памятью (из стека) в порядке вещей.
int func (a)
char a;
{
int b[60000];
}
- должны гореть в аду. Но в аду им не позволит гореть современный компилятор. Он выправит этот код. Можете проверить.
Цитата:
Сообщение от 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 - несовременный компилятор", ожидаю примеры генерации кода с упомянутой оптимизацией и указанием используемого компилятора и его версии.Код:gcc версия 4.8.2 (GCC)
Да - эту историю знаю.Цитата:
А знаете ли вы, что создатели Z80 - бывшие топ менеджеры Intel
но я и предлагаю это проэмулировать.Цитата:
20-и битной шины адреса процессора.
Вы поймите что 8086 тоже адресует одновременно не 1мб. а 64к помноженное на количество сегментных регистров CS, DS, SS ES = 256кб. А дальше ему нужно модифицировать эти регистры.
Тоже самое получится и у нас - адресуемые сразу 256 кб. а через модификацию этих регистров - хоть все 4мб.
Hacker Grey, авторы процессоров з80 и8080 мос6502 сидели и считали такты, логические элементы и эффективность своих устройств.
может лучше сразу создать на основе ZXEvo устройство с 24 битной адресацией?
а не городить кадавров?
именно так.Цитата:
Сообщение от Titus
это утрированный пример. а на деле почему не может быть нескольких лок. массивов байт на 500? как их делать, если они нужны? а если вложенность подпрограмм приличная? всяко может быть.Цитата:
Сообщение от haywire
Если идёт речь о простой программе, то чаще всего да, так и есть, а, например, если мы говорим о ядре ОС, то как обеспечить реентерабельность? Хранить в структурах подобных стеку - один из вариантов. Насколько я знаю, msdos большую часть переменных хранит именно так.Цитата:
Сообщение от haywire
Конечно, возможно. Не вы первый, кому эта идея пришла в голову. Я думал о подобной надстройке еще в 1995-96 годах где-то. Тогда еще ФПГА массово не использовались - думал делать логику на ЛА3 и РТ4.Цитата:
Сообщение от Hacker Grey
Основной довод "против" уже высказал Jerri: сделать подобную аппаратную довеску несложно. Ну, месяц потрудишься - и получится в конце концов. Но проблема ведь не в аппаратуре. Проблема в софте, которого под эту конфигурацию нет. На создание софта уйдет значительно больше человеко-часов, чем на создание аппаратной части. У вас есть столько времени и желания писать софт? А если нет у вас лично - может кого-нибудь знаете, у кого есть?
С тем же успехом можно заменить Z80 каким-нибудь 32-битным процессором. И все, проблемы с адресацией уйдут. Почему никто этого не делает? А если кто и делает, то такие компы уже не назваются "Спектрумами"? В чем тут принципиальная разница - взять совершенно другой проц или оставить прежний, но приделать к нему кучу костылей? Для программистов-то между этими двумя вещами разницы нет. Старые программы не смогут поддерживать новые возможности.
Тогда уж лучше сделать аппаратный ускоритель блочной пересылки или, еще лучше, - блиттер, как на Амиге, который обрабатывает прямоугольные блоки. Ведь LDI и LDIR жутко медленные. Даже если составить последовательность чтения-записи памяти на шине Z80 из трехтактовых циклов, т.е. минимального времени, за которое Z80 может обратиться к памяти, то получится 6 тактов на пересылку байта - против 16 для LDI или 21 для LDIR.Цитата:
Сообщение от Hacker Grey
Сочувствую. Я видел и хорошие примеры использования рекурсии, и сам ее иногда использовал с большой эффективностью.Цитата:
Сообщение от haywire
Рекурсия иногда нужна. Как и любой другой инструмент, она занимает свое место в мастерской программиста. При использовании ее по назначению все прекрасно - и у программиста, и у компьютера. Стек не переполняется. А не по назначению - это как гвозди забивать микроскопом. Конечно, получается фиаско.
Почему это? Что ты предлагаешь делать, если нужен временный массив на 60 (или даже 6000) килобайт? malloc? Так это же неэффективно. Работа менеджера кучи сложнее, чем стека, и впоследствии возможна фрагментация памяти. Для подобных применений стек лучше.Цитата:
Сообщение от haywire
Если он действительно такой нужен, то и времени на обработку потратишь столько, что работа с ним менеджера кучи будет просто незаметна и ничтожна на этом фоне.Цитата:
Сообщение от Barmaley_m
вот только на стеке оно точно автоматом удалится при выходе, а про кучу можно забыть. +память в куче фрагментируется.
короче, неоднозначный выбор.