Вопрос касательно программирования

Или не программирования? Черт знает.

В общем, хочу написать эмулятор собственного 16-битного процессора. Я его в каком-то плане сделал, он умеет читать сделанные мною бинарники и делать простейшие операции в этом бинарнике прописанные.

Но у меня есть вопрос касательно достаточно фундаментальной вещи - насчет инструкций.

 

Вот у нас есть регистровая память, вот RAM. Не будем рассматривать кэш и прочее.

По факту мы можем использовать инструкцию, например, mov, как: из регистра в регистр, из регистра в память, из памяти в регистр, из памяти в память.

 

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

тут тебе помогут лучше, расскажут и подскажут (не пиар сайта) 

Ответь на вопрос зачем тебе это все?если до тебя уже все придумал ты тупо тратишь время зря,это все очень сложно или чисто для себя?

Kagon сказал(а):↑

Если говорить об обычном процессоре, то это разные инструкции, или одна и та же

Нажмите, чтобы раскрыть...

инструкция одна и та же.

PS. Только ты забываешь о том что есть инструкции и есть мнемоники (то что ты назвал инструкцией), и вот не всегда мнемоника соотвествует одной и той же инструкции.

Мне бы хотел увидеть "реализацию" как ты говоришь твоего CPU, если ты не справился с довольно таки простой вещью.

Спойлер: "описание"

 

Возьмем вариант попроще:

Есть регистры - r1-r4

Есть опкоды, скажем add/mux по умолчанию ВСЕ инструкции работают только с регистровой памятью, то есть в простом случае мы всегда должны пред-загрузить value из RАМ. 

Тут всё просто, но что делать с константами?

Тут есть два варианта, делать отдельный регистр zr (zero register), или научить наши опкоды быть полиморфными,, на уровне трансляции.

Путь опкоды заданы 16 битным словом (это для простоты) - где первая половина это номер опкода:

0x00 - nop

0x01 - add

0x02 - mux и

так далее

Тогда второй байт мы можем использовать для указания того, какие у нас будут аргументы, так как команды могут принимать от 1 до 3 аргументов (пока наши простые), определим для каждого дуплета битов свою схему:

01 - регистр

00 - константа

10 - зарезервируем до лучших времен (просто будет сделать подобие х86 с предзагрузкой)

Теперь нужно в опкодах сделать пометки для аргументов:

# - константа

r1 - регистр

@ - прямой адрес (для jmp например на будущее)

 

и поехали:

add r1, #7, r4 - содержимое r1 добавь к 7-ми и положи в r4 (0000 0001 0100 0100 - твой bin опкода)

mux #12, r4, @255 - умнож 12 на r4 и положи в память по адресу 0xFE(0000 0010 0001 1000 - твой bin опкода)

 

Разные.

saw_tooth сказал(а):↑

инструкция одна и та же.

PS. Только ты забываешь о том что есть инструкции и есть мнемоники (то что ты назвал инструкцией), и вот не всегда мнемоника соотвествует одной и той же инструкции.

Нажмите, чтобы раскрыть...

Ну это мнемоника языка ассемблера, а я именно про процессорную инструкцию спросил.

VersuTa228 сказал(а):↑

Ответь на вопрос зачем тебе это все?если до тебя уже все придумал ты тупо тратишь время зря,это все очень сложно или чисто для себя?

Нажмите, чтобы раскрыть...

Просто хочу, это же классно. Нужно же мне убить свое время, верно?

dist_ сказал(а):↑

Разные.

Нажмите, чтобы раскрыть...

Спасибо, ответ получен. Значит, разные.

Я плохо помню свою практику по ассемблеру, но писали мы как раз под 16-тиразрядный i8086 и там нельзя было из памяти в память.

BezMozg сказал(а):↑

Я плохо помню свою практику по ассемблеру, но писали мы как раз под 16-тиразрядный i8086 и там нельзя было из памяти в память.

Нажмите, чтобы раскрыть...

Ну, процессоры все-таки абсолютно разные бывают. Тот же RISC вроде не может напрямую инструкцию в память использовать (я имею ввиду, что ты не можешь взять ячейку памяти из RAM и прибавить к ней, допустим, 5 - тебе надо сначало поместить ее в регистр, к регистру прибавить и из регистра записать)

Kagon сказал(а):↑

Ну, процессоры все-таки абсолютно разные бывают. Тот же RISC вроде не может напрямую инструкцию в память использовать (я имею ввиду, что ты не можешь взять ячейку памяти из RAM и прибавить к ней, допустим, 5 - тебе надо сначало поместить ее в регистр, к регистру прибавить и из регистра записать)

Нажмите, чтобы раскрыть...

Именно так мы и делали... я проклял всё на свете с этим говнищем.

Kagon сказал(а):↑

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

Нажмите, чтобы раскрыть...

Kagon сказал(а):↑

а я именно про процессорную инструкцию спросил

Нажмите, чтобы раскрыть...

Обновил сообщение выше

saw_tooth сказал(а):↑

инструкция одна и та же.

PS. Только ты забываешь о том что есть инструкции и есть мнемоники (то что ты назвал инструкцией), и вот не всегда мнемоника соотвествует одной и той же инструкции.

Мне бы хотел увидеть "реализацию" как ты говоришь твоего CPU, если ты не справился с довольно таки простой вещью.

Спойлер: "описание"

 

Возьмем вариант попроще:

Есть регистры - r1-r4

Есть опкоды, скажем add/mux по умолчанию ВСЕ инструкции работают только с регистровой памятью, то есть в простом случае мы всегда должны пред-загрузить value из RАМ. 

Тут всё просто, но что делать с константами?

Тут есть два варианта, делать отдельный регистр zr (zero register), или научить наши опкоды быть полиморфными,, на уровне трансляции.

Путь опкоды заданы 16 битным словом (это для простоты) - где первая половина это номер опкода:

0x00 - nop

0x01 - add

0x02 - mux и

так далее

Тогда второй байт мы можем использовать для указания того, какие у нас будут аргументы, так как команды могут принимать от 1 до 3 аргументов (пока наши простые), определим для каждого дуплета битов свою схему:

01 - регистр

00 - константа

10 - зарезервируем до лучших времен (просто будет сделать подобие х86 с предзагрузкой)

Теперь нужно в опкодах сделать пометки для аргументов:

# - константа

r1 - регистр

@ - прямой адрес (для jmp например на будущее)

 

и поехали:

add r1, #7, r4 - содержимое r1 добавь к 7-ми и положи в r4 (0000 0001 0100 0100 - твой bin опкода)

mux #12, r4, @255 - умнож 12 на r4 и положи в память по адресу 0xFE(0000 0010 0001 1000 - твой bin опкода)

 

Нажмите, чтобы раскрыть...

А ведь достаточно простая идея. Ну, я слишком тупой чтобы до нее сам дойти. Спасибо.

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

Щас бы вернуться на пару по Ассемблеру в 8 утра в субботу...

Kagon сказал(а):↑

А ведь достаточно простая идея.

Нажмите, чтобы раскрыть...

Нужно было просто немного подумать.

Для реализации полной полиморфности, тебе нужен отдельный модуль памяти, который равноправный с модулями ALU, и вот тогда на уровне конвеера, твоя условная

add @0xFF @0xFA @0xAA

Распадется на неявные:

ld @0xFF, r1

ld @0xFA, r2 

add r1, r2, r3

ld r3, @0xAA

 

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

Да и модули типа ALU/FPU усложняются, так как должны будут уметь работать с адресами, по крайней мере их хранить, и передавать на MMU

Спойлер: "ирония судьбы"

не знаю случайность ли это, или ты меня преследуешь, но недавно я сам писал реализацию CPU с линейным MMU на python,  а тут ты со своей темой.