Войти
ФлеймФорумЖелезо

Мой виртуальный 16-битный процессор Simpleton (3 стр)

Страницы: 1 2 3 4 Следующая »
#30
(Правка: 8:14) 8:14, 28 дек. 2019

Delfigamer
> А загружать через Current Instruction Address PPC не умеет

Ааа, ну если такие проблемы, то тогда понятно. Ущербненько... Странно даже, такая зрелая архитектура, а такой простой логичной вещи не умеет. Тупак.


#31
(Правка: 12:27) 12:21, 28 дек. 2019

=A=L=X=
> TO - (two operand instruction) - флаг двухоперандной инструкции - если этот бит
> 0, то АЛУ не нуждается во втором аргументе и его не надо грузить (тратить на
> это время)

Этот момент смущает. Если 16 битная шина данных между процом и памятью, то данные второго аргумента придут из памяти один хрен. Для 8 битной это действительно имеет смысл.

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

#32
(Правка: 1 янв. 2020, 18:54) 15:55, 28 дек. 2019

=A=L=X=
> Ааа, ну если такие проблемы, то тогда понятно. Ущербненько... Странно даже,
> такая зрелая архитектура, а такой простой логичной вещи не умеет. Тупак.
Там оно и не нужно, r2 таки решает задачу.
А, и я только что сообразил, что nia таки можно получить легально, хоть и немного нетривиально:

    bl _next
_next:
    mflr r3
    ld r3, (static_data - _next)(r3)
    lr = next_instruction_address(); goto _next;
_next:
    r3 = lr;
    r3 = *(int64_t*)(static_data - _next + r3);
#33
11:24, 29 дек. 2019

Delfigamer
> bl _next
> _next:
> mflr r3

Хех, в точности так же как position independent code реализовывался на x86 до x86-64 - call на следующую инструкцию + pop eax и далее по списку.

#34
13:09, 1 янв. 2020

Что планируется делать под этот 16-битный процессор?  Свою игровую приставку или компьютер?  Кто будет писать софт под него?  В виде дизайна для FPGA планируется ?

Почему 16 битный?  32-битный будет красивее, а если заложить параллелизм и сделать 64...128 регистров общего назначения - это будет сказка!

Вот например, TMS320C6745 может заниматься отрисовкой буфера : оперирует 8 байтами сразу : возможно работать с блоками 4x4 пиксела -

+ Показать

#35
(Правка: 13:16) 13:10, 1 янв. 2020

Про графический движок консоли BlackPrism на TMS320C6745 здесь расписал:

https://electronix.ru/forum/index.php?app=forums&module=forums&co… pic&id=154937

Есть два встроенных RISC-сопроцессора помимо DSP: работают на тактовой частоте вдвое ниже основного ядра.  Зато могут MEMORY BURST, особо эта вкусность используется когда надо перекинуть буфер на дисплей - там же и ожидание по VSYNC можно сделать отложенное - по факту параллельно выполняем логику игр и отрисовку на экран предыдущего кадра с VSYNC без ожидания его основным CPU!  ПК отдыхает! )))

+ Показать

Обратите внимание на развитость команд - много операндов, и регистров общего назначения - тьма!  В самом DSP ещё и параллельность инструкций (параллельные выполнения - помечены значком ||  в асм-коде).  Даёшь вот такой процессор!! ))

#36
21:46, 1 янв. 2020

Gradius
> Почему 16 битный?  32-битный будет красивее, а если заложить параллелизм и сделать 64...128 регистров общего назначения - это будет сказка!
> Вот например, TMS320C6745

Похоже на VLIW.

#37
23:33, 1 янв. 2020

Среди операций почему-то нет сдвигов. Как без них делать умножения?

#38
(Правка: 1:50) 1:48, 2 янв. 2020

Dmitry_Milk
> Среди операций почему-то нет сдвигов.
Видимо потому что
> ...реализованные сейчас...

NetSpider
> Этот момент смущает. Если 16 битная шина данных между процом и памятью, то
> данные второго аргумента придут из памяти один хрен. Для 8 битной это
> действительно имеет смысл.
>
> Процессоры количество операндов определяют по самой инструкции. Но если для
> обозначения этого выделен отдельный бит, это неплохо. Только на быстродействие
> в лучшую сторону это не повлияет

Если второй операнд используется только для записи, а в АЛУ как аргумент не поступает, то его не надо считывать в начале инструкции, а особенно для памяти это дорогая операция, поэтому экономия тут реальная.

#39
4:43, 2 янв. 2020

Kollect3D
> Если второй операнд используется только для записи, а в АЛУ как аргумент не
> поступает, то его не надо считывать в начале инструкции, а особенно для памяти
> это дорогая операция, поэтому экономия тут реальная.
Я думаю, с тем CISCом, что тут есть, проблемы с памятью возникнут в самую последнюю очередь.

#40
(Правка: 4:49) 4:47, 2 янв. 2020

Delfigamer
> Я думаю, с тем CISCом, что тут есть, проблемы с памятью возникнут в самую
> последнюю очередь.

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

#41
0:19, 6 янв. 2020

Ладно, с jmp/call/ret, в принципе понятно. А как прерывания разрешать/запрещать/генерировать?

#42
6:55, 6 янв. 2020

0iStalker
> А как прерывания разрешать/запрещать/генерировать?
Битами в flags и прямым джампом по вектору прерывания, например.

#43
7:20, 6 янв. 2020

0iStalker
> А как прерывания разрешать/запрещать/генерировать?

Запрещать/разрешать действительно записью во flags, причём чтобы не портить другие флаги это делается двоичной классикой:

flags |= ENABLE_INTERRUPTS_BIT ; enable
flags &= ~ENABLE_INTERRUPTS_BIT; disable
Правда оператора ~ для констант пока нет, так что в ассемблере инверсию пока надо запекать в отдельный идентификатор.
Команду эквивалентную HALT в Z80 - т.е. замереть ожидая наступления аппаратного прерывания можно так же реализовать битом во флагах - т.е. некий бит напрямую стопорит процессор и по наступлению прерывания автоматически сбрасывается. Но пока даже не факт что такое понадобится как и концепция софтварных прерываний. В том же спектруме софтварные прерывания использовались как экономия на спичках - мне такое не особо нравится.
Поэтому единственное что тут мне не нравится - это то, что аппаратное прерывание должно сразу пару инструкций выполнять
[ sp ] =+2 pc
pc = IRQ_VECTOR
Т.е. аппаратно тут не очень просто должно быть в кишках всё, что не особо мне нравится действительно.

#44
7:36, 6 янв. 2020

Gradius
> Что планируется делать под этот 16-битный процессор? Свою игровую приставку или
> компьютер? Кто будет писать софт под него? В виде дизайна для FPGA
> планируется ?

Да это просто концепт возникший от обдумывания некой минималистичной, но удобной системы команд для некоего процессора с очень мощным духом ретро.
Ввиду сравнительной простоты сам не заметил как запрограммировал эмулятор, а проверяя эмулятор не заметил как написал ассемблер просто для удобства - сперва команды загонялись в память очевидными макросами которые очень быстро обросли emitInstruction( const std::string& asm_line ).
Но сейчас уже на таком этапе когда впору делать эмуляцию не только процессора но и какой то машины с видео и звуком, но это уже сильно сложнее, так что пока ничего не обещаю.
Про FPGA действительно мысль мелкала, но точно не сейчас, а если только на пенсии когда делать нечего будет совсем.

Страницы: 1 2 3 4 Следующая »
ФлеймФорумЖелезо