Пожелания:
• Использовать дефолтной палитрой pulsar/sRGB вместо alone. Есть множество исследований, которые показывают, что они намного ближе к оригинальной картинке.
• Использовать бордер, задуманный авторами. Сейчас в статье везде чёрный, на Events есть белые.
Если Вы уж взялись за проектирование архитектур процессоров, то считай катитесь по стенкам воронки.
В любом случае я сперва напишу эмулятор, оформлю архитектуру видеочипа и т.п., а главное — софт разный под это дело напишу — тогда только буду задумываться всерьёз насчёт физических реализаций. У меня в самом деле с детства очень напряжённые отношения с паяльником и сидеть травить платы и подпаивать сотни проводков — не вызывает энтузиазма вообще. Я не железячник, я больше по софту.
Паяльник и не предлагаю, нет-нет! Посмотрите как в Digital приятно симулировать архитектуру, в данном случае к корке 6502 на verilog подцеплена графическая память и на Verilog доделан модуль ускорителя графики. Удобно, интересно и никаких паяльников. Причем как только перестанет хватать скорости симулятора, можно уйти в реальную железку (без какой либо пайки) и продолжить жить в собтвенной архитектуре на огромных скоростях. Например вышеупомянутая корка 6502 живет на 50МГц в довольно слабом Spartan-6.
Если Вы уж взялись за проектирование архитектур процессоров, то считай катитесь по стенкам воронки. Да и грех себе отказывать в таком удовольствие до самой пенсии. Может оформите как продолжение статьи? Я бы помог разобраться :)
Есть желание перебросить процессор в Verilog, откатать на визуальном симуляторе цепей Digital и потом в FPGA?!
Сам я далёк от паяльника и программатора сильно, но отладив в эмуляторе реализовать в железе — весьма завлекательная идея.
Но лично сам — если только много лет спустя на пенсии, ибо сейчас изучение нового мира схемотехники для меня неподъёмный груз в рамках хобби.
Но если кому то опытному будет любопытно реализовать — я только за. В принципе архитектура open source-ная так что хоть форки делать со своими расширениями команд. :)
Здравствуй трех адресный PDP-11 :) Неплохо! Очень!
Есть желание перебросить процессор в Verilog, откатать на визуальном симуляторе цепей Digital и потом в FPGA?! Для Digital можно даже IDE с боку прицепить что бы красиво отлаживать с точками останова и пошагово.
Мне сейчас уже синтаксисом заниматься неохота особо — я реально на нём попробовал как он есть и меня реально устроило. Даже как то понравилось когда ассемблерный текст растягивается в ширину с чётко выделенными пробелами всеми абсолютно местами.
Как я понял это дело привычки, поэтому тратить на это время уже не хочу.
Чем буду в свободное от других хобби время далее заниматься — это миграцией под SDL чтобы сделать прообраз виртуального ПК с клавиатурой и дисплеем и на нём реально пробовать что там со сдвигами применительно к скроллингам всяким и парсер сложных compile-time выражений.
Хотя еще наверное преобразую парсер самого ассемблера к варианту с паттерн-матчингом — при нём проще будет новые синтаксисы внедрять, кстати.
да, [pc] конечно, что-то перемкнуло меня) главное, что ты понял верно
по сдвигам надо бы всё тщательно взвесить, одинарный сдвиг для быстрой арифметики маловато
насчёт асма, на мой взгляд, задятые достаточно заметно отделяют операнды (особенно на шрифтах фиксированной ширины), ну, и если хочется, никто же после них пробелы не запрещает! и второе, нужны ли вообще квадратные скобки? префикс в большинстве случаев лаконичней:
1) куча пробелов выглядит хуже пары запятых и занимает больше места в исходнике
Тут забавно — изначально я просто «по быстрячку» (а исходники Simpleton-ов всегда развивались таким путём) воспользовался вводом строк из потоков C++, которые ведут себя именно таким образом — просто вводят от текущей позиции до следующих пробельных символов.
И думал что в режиме теста так проковыляю какое то время, а потом заменю на типовую схему. Однако уже и есть функция extraсtLexem, но… мне так понравилось! :)
Во первых я всегда следую (и в данном случае — всем рекомендую) орфографической традиции — после знаков препинания типа точек или запятых ставить пробелы. Это естественно как дышать и видно даже на этом самом тексте. Поэтому запятые только добавляют один символ к разделителю-пробелу в массе случаев. Их настоящая нужда в мейнстриме — это помощь с отделением друг от друга аргументов со сложными выражениями, что встречается относительно нечасто и может быть разрулено явными скобками.
Ну и просто попробовав я как то втянулся. Функцию extractLexem конечно можно переписать и получить более привычное поведение хотя бы со скобками, но мне после такой практики на это совершенно не хочется тратить время. :)
2) интересный вопрос, как устанавливаются флаги, когда приёмник — psw (как регистр) :)
Действительно отличный вопрос! Сейчас в эмуляторе АЛУ сперва обновляет биты арифметико-логических флагов как бы «напрямую» как если имеет в регистр флагов прямой вход через заднюю дверь (что весьма правдоподобно звучит для схемотехники, не зря он находится «с краю» регистрового файла), а уже после этого основное ядро извлекает результат из АЛУ и пишет его в регистровый файл. Т.е. запись в PSW ведёт себя довольно практично — изменение арифметических флагов будет забыто и операция вида «and psw psw маска» изменит только желаемый бит.
Однако возможно что ради скорости в схемотехнике эти операции могут происходить параллельно и результат сохранения в арфметико-логические флаги будет неопределён. Это может иметь некоторые последствия при обработке прерываний, но обдумав я нахожу что реальных проблем не будет. Поэтому на данный момент наверное лучше исходить из такого предположения.
> 3) не хватает прокрутки ЧЕРЕЗ перенос, а также сдвигов — для ускорения арифметики и возможной битовой графики
Я поэтому замер пока на операциях прокрутки и думаю какие лучше инструкции разместить в оставшейся части.
Во первых — по заветам MSP-430 операции ADD и ADC можно использовать как сдвиг и прокрутку влево:
add r0 r0 r0; сложение само с собой это умножение на 2 и сдвиг на 1 бит влево со вновь входящим нулевым битом
adc r0 r0 r0; сложение с переносом это сдвиг на 1 бит влево со входящим Carry и тут же исходящим Carry, т.е. идёт прокрутка влево через Carry, причём _через_ перенос.
Поэтому тот же MSP-430 не вводил аналогичных команд прокрутки и я не собираюсь.
Но вот прокрутка вправо уже должна быть в явном виде и чтобы побороть несколько проблем я пока решил сделать число прокручиваемых бит настраиваемым, а саму прокрутку — циклической с занесением в Carry, но не ЧЕРЕЗ Carry.
Почему так — потому что можно имитировать еще полезную команду SWAP BYTES просто прокрутив на 8 бит. Байты в слове поменялись местами.
Может быть полезно для упаковки и совместимости с типовыми файлами.
С другой стороны прокрутка вправо на 15 бит это же и прокрутка влево на 1 бит. Появляется взаимозаменяемость.
Далее — если кровь из носа нужен сдвиг влево/вправо на программируемое число бит мы можем подстроить счётчик чтобы нужные биты прокрутились куда требуется, а потом обнулением по «AND маска» занулить ненужные биты.
Так что как минимум беззнаковое деление на степени двойки делается. А если предварительно сделать условный переход по биту знака и в этой ветке сделать «OR маска», то и знаковые числа тоже можно будет делить и сдвигать таким образом.
Вот на этих размышлениях я пока подвис и пока еще думаю. Нужна практика наверное реального программирования на Simpleton 4 чтобы почувствовать что нужно остро и кровь из носу, а что достаточно сэмулировать серией базовых команд.
Тот же Gigatron вообще сдвиги делал через лукап-таблицы (!).
4) хорошо бы еще один регистр с автоинкрементами — для шитого кода (мб включать автоинкременты для регистров спецфлагами?)
Регистров в духе 8-биток тут немного, поэтому специализированного регистра точно не будет. А вот сделать в регистре флагов на первые 4 регистра по два флажка — «пост-инкремент» и «пре-декремент» — это интересная мысль, за неё спасибо. Её надо обдумать, хотя есть минусы. Например при входе в прерывания эти флаги надо обнулять и потом восстанавливать. Но! То как я планирую сделать вход в прерывания с этим похоже что прекрасно справляется. Да да да… Интересно…
5) зачем тратить опкод на отдельную команду cmp? когда можно принять запись в [psw] за игнор результата
А вот это супер-идея! Спасибо! Только и косвенное чтение и косвенная запись в PSW в Simpleton 4 уже заняты — это режим адресации immediate address с помощью которого можно вообще не загрязнять регистры:
[ $1000 ] = [ $1001 ] +s [ $1002 ] ; ни один регистр (включая флаги) кроме PC не изменился
Однако! Еще с Simpleton 3 была запрещена косвенная запись в PC! Здесь этот запрет сохранился, но я его не упомянул.
Пытаться писать прямо в поток выполняемых команд — это как минимум странно. :) Поэтому именно за [ PC ] в поле R и логично закрепить новый смысл — «игнорирование записи результата из АЛУ в файловый регистр или память». Гениально! :D
Действительно высвобождается специализированная инструкция CMP с одной стороны, а с другой стороны появляются булевы тесты и, например, такая экзотичка, как с помощью команды из одного слова — RRCI поместить в Carry любой на выбор бит из операнда. xD
Блин, это прикольная идея! Прям спасибо!
просмотрел очень бегло, но сразу же несколько замечаний и предложений:
1) куча пробелов выглядит хуже пары запятых и занимает больше места в исходнике
2) интересный вопрос, как устанавливаются флаги, когда приёмник — psw (как регистр) :)
3) не хватает прокрутки ЧЕРЕЗ перенос, а также сдвигов — для ускорения арифметики и возможной битовой графики
4) хорошо бы еще один регистр с автоинкрементами — для шитого кода (мб включать автоинкременты для регистров спецфлагами?)
5) зачем тратить опкод на отдельную команду cmp? когда можно принять запись в [psw] за игнор результата, и она появляется «бесплатно», так же как test и прочие логические аналоги (плюс тогда мб даже имеет смысл сделать сохраняющие результат обычные and/or/xor не устанавливающими флаги)
Так чего прощать — я согласен, так и есть. Нормально снять на видео происходящее на экране осциллографа — проблематично. По крайней мере на мою Sony NEX7. Та же проблема была с Vectrex'ом — я там даже отбросил сразу несколько идей которые я точно знал, на видео не будут смотреться от слова совсем.
А вот я категорически не согласен с местами 1 и 2. На обеих лица неузнаваемы, потерялось именно характерное. Ящитаю, первые два места за 3 и 5 — даже несмотря на то, что к 5 таки есть за что придраться (изменена форма лица), всё равно она осталась самой похожей. Насчёт третьего места возможны варианты, но тоже не 1 и 2 скорее всего.
Не голосовал, есичо — как-то пропустил, завертевшись, хотя объявление раньше видел.
Да простит меня автор статьи, тот случай, когда скриншот круче видео с работой. Ничуть не умаляю технической сложности, но в динамике разглядеть и понять очень сложно. В статике — 3D абстракция, что прикольно для осциллографа и такого размера интро.
Обзор как всегда прекрасный и самобытный. Спасибо shuran33 !
У меня вопрос и просьба к авторам, поделитесь пожалуйста информацией, в чём и на чем вы рисуете все эти восхитительные работы?
Про себя могу сказать:
работа 9 — liv1 была нарисована в приложении для iPad PixelStudio и сконвертирована из png в scr с помощью Multipaint
работа 8 — liv2 была нарисована в Photoshop и сконвертирована из png в scr с помощью Multipaint (рисовал в photoshop, чтобы записать видео рисовки полностью, на десктопе это делать гораздо проще)
По 4 месту. Tyler не случайно заменена на tailor :)
Насколько я понял, картинка родилась как вольная сюжетная интерпретация имени Лив Тайлер. Был бы интересно узнать историю создания.
• Использовать дефолтной палитрой pulsar/sRGB вместо alone. Есть множество исследований, которые показывают, что они намного ближе к оригинальной картинке.
• Использовать бордер, задуманный авторами. Сейчас в статье везде чёрный, на Events есть белые.
Как всегда, очень клевый!
Кто еще не проголосовал, есть возможность успеть это сделать на events
В любом случае я сперва напишу эмулятор, оформлю архитектуру видеочипа и т.п., а главное — софт разный под это дело напишу — тогда только буду задумываться всерьёз насчёт физических реализаций. У меня в самом деле с детства очень напряжённые отношения с паяльником и сидеть травить платы и подпаивать сотни проводков — не вызывает энтузиазма вообще. Я не железячник, я больше по софту.
Если Вы уж взялись за проектирование архитектур процессоров, то считай катитесь по стенкам воронки. Да и грех себе отказывать в таком удовольствие до самой пенсии. Может оформите как продолжение статьи? Я бы помог разобраться :)
Но лично сам — если только много лет спустя на пенсии, ибо сейчас изучение нового мира схемотехники для меня неподъёмный груз в рамках хобби.
Но если кому то опытному будет любопытно реализовать — я только за. В принципе архитектура open source-ная так что хоть форки делать со своими расширениями команд. :)
Есть желание перебросить процессор в Verilog, откатать на визуальном симуляторе цепей Digital и потом в FPGA?! Для Digital можно даже IDE с боку прицепить что бы красиво отлаживать с точками останова и пошагово.
Как я понял это дело привычки, поэтому тратить на это время уже не хочу.
Чем буду в свободное от других хобби время далее заниматься — это миграцией под SDL чтобы сделать прообраз виртуального ПК с клавиатурой и дисплеем и на нём реально пробовать что там со сдвигами применительно к скроллингам всяким и парсер сложных compile-time выражений.
Хотя еще наверное преобразую парсер самого ассемблера к варианту с паттерн-матчингом — при нём проще будет новые синтаксисы внедрять, кстати.
по сдвигам надо бы всё тщательно взвесить, одинарный сдвиг для быстрой арифметики маловато
насчёт асма, на мой взгляд, задятые достаточно заметно отделяют операнды (особенно на шрифтах фиксированной ширины), ну, и если хочется, никто же после них пробелы не запрещает! и второе, нужны ли вообще квадратные скобки? префикс в большинстве случаев лаконичней:
скобки только для сложных выражений:
хотя при наличии запятых необязательны и они, префикc действует на всё выражение:
также, void как по мне длинновато, может, применять какой-то другой значок или даже «пустое выражение»?
ну, или просто псевдами выражать (те же cmp, test...)
Реализовал псевдорегистр 'void' и поведение с косвенной записью в PC. Теперь освободился еще один опкод — CMP.
Теперь сравнение делается так:
побитовые тесты (любые в OR/XOR/AND):
… или сравнение числа с константой в диапазоне -8..+7 за инструкцию в одно слово (inplace immediate):
… или проверка i-ого бита операнда через занос его в CF операцией RRCI:
Ляпота! Еще раз спасибо за идею! :)
И думал что в режиме теста так проковыляю какое то время, а потом заменю на типовую схему. Однако уже и есть функция extraсtLexem, но… мне так понравилось! :)
Во первых я всегда следую (и в данном случае — всем рекомендую) орфографической традиции — после знаков препинания типа точек или запятых ставить пробелы. Это естественно как дышать и видно даже на этом самом тексте. Поэтому запятые только добавляют один символ к разделителю-пробелу в массе случаев. Их настоящая нужда в мейнстриме — это помощь с отделением друг от друга аргументов со сложными выражениями, что встречается относительно нечасто и может быть разрулено явными скобками.
Ну и просто попробовав я как то втянулся. Функцию extractLexem конечно можно переписать и получить более привычное поведение хотя бы со скобками, но мне после такой практики на это совершенно не хочется тратить время. :)
Действительно отличный вопрос! Сейчас в эмуляторе АЛУ сперва обновляет биты арифметико-логических флагов как бы «напрямую» как если имеет в регистр флагов прямой вход через заднюю дверь (что весьма правдоподобно звучит для схемотехники, не зря он находится «с краю» регистрового файла), а уже после этого основное ядро извлекает результат из АЛУ и пишет его в регистровый файл. Т.е. запись в PSW ведёт себя довольно практично — изменение арифметических флагов будет забыто и операция вида «and psw psw маска» изменит только желаемый бит.
Однако возможно что ради скорости в схемотехнике эти операции могут происходить параллельно и результат сохранения в арфметико-логические флаги будет неопределён. Это может иметь некоторые последствия при обработке прерываний, но обдумав я нахожу что реальных проблем не будет. Поэтому на данный момент наверное лучше исходить из такого предположения.
> 3) не хватает прокрутки ЧЕРЕЗ перенос, а также сдвигов — для ускорения арифметики и возможной битовой графики
Я поэтому замер пока на операциях прокрутки и думаю какие лучше инструкции разместить в оставшейся части.
Во первых — по заветам MSP-430 операции ADD и ADC можно использовать как сдвиг и прокрутку влево:
add r0 r0 r0; сложение само с собой это умножение на 2 и сдвиг на 1 бит влево со вновь входящим нулевым битом
adc r0 r0 r0; сложение с переносом это сдвиг на 1 бит влево со входящим Carry и тут же исходящим Carry, т.е. идёт прокрутка влево через Carry, причём _через_ перенос.
Поэтому тот же MSP-430 не вводил аналогичных команд прокрутки и я не собираюсь.
Но вот прокрутка вправо уже должна быть в явном виде и чтобы побороть несколько проблем я пока решил сделать число прокручиваемых бит настраиваемым, а саму прокрутку — циклической с занесением в Carry, но не ЧЕРЕЗ Carry.
Почему так — потому что можно имитировать еще полезную команду SWAP BYTES просто прокрутив на 8 бит. Байты в слове поменялись местами.
Может быть полезно для упаковки и совместимости с типовыми файлами.
С другой стороны прокрутка вправо на 15 бит это же и прокрутка влево на 1 бит. Появляется взаимозаменяемость.
Далее — если кровь из носа нужен сдвиг влево/вправо на программируемое число бит мы можем подстроить счётчик чтобы нужные биты прокрутились куда требуется, а потом обнулением по «AND маска» занулить ненужные биты.
Так что как минимум беззнаковое деление на степени двойки делается. А если предварительно сделать условный переход по биту знака и в этой ветке сделать «OR маска», то и знаковые числа тоже можно будет делить и сдвигать таким образом.
Вот на этих размышлениях я пока подвис и пока еще думаю. Нужна практика наверное реального программирования на Simpleton 4 чтобы почувствовать что нужно остро и кровь из носу, а что достаточно сэмулировать серией базовых команд.
Тот же Gigatron вообще сдвиги делал через лукап-таблицы (!).
Регистров в духе 8-биток тут немного, поэтому специализированного регистра точно не будет. А вот сделать в регистре флагов на первые 4 регистра по два флажка — «пост-инкремент» и «пре-декремент» — это интересная мысль, за неё спасибо. Её надо обдумать, хотя есть минусы. Например при входе в прерывания эти флаги надо обнулять и потом восстанавливать. Но! То как я планирую сделать вход в прерывания с этим похоже что прекрасно справляется. Да да да… Интересно…
А вот это супер-идея! Спасибо! Только и косвенное чтение и косвенная запись в PSW в Simpleton 4 уже заняты — это режим адресации immediate address с помощью которого можно вообще не загрязнять регистры:
Однако! Еще с Simpleton 3 была запрещена косвенная запись в PC! Здесь этот запрет сохранился, но я его не упомянул.
Пытаться писать прямо в поток выполняемых команд — это как минимум странно. :) Поэтому именно за [ PC ] в поле R и логично закрепить новый смысл — «игнорирование записи результата из АЛУ в файловый регистр или память». Гениально! :D
Действительно высвобождается специализированная инструкция CMP с одной стороны, а с другой стороны появляются булевы тесты и, например, такая экзотичка, как с помощью команды из одного слова — RRCI поместить в Carry любой на выбор бит из операнда. xD
Блин, это прикольная идея! Прям спасибо!
1) куча пробелов выглядит хуже пары запятых и занимает больше места в исходнике
2) интересный вопрос, как устанавливаются флаги, когда приёмник — psw (как регистр) :)
3) не хватает прокрутки ЧЕРЕЗ перенос, а также сдвигов — для ускорения арифметики и возможной битовой графики
4) хорошо бы еще один регистр с автоинкрементами — для шитого кода (мб включать автоинкременты для регистров спецфлагами?)
5) зачем тратить опкод на отдельную команду cmp? когда можно принять запись в [psw] за игнор результата, и она появляется «бесплатно», так же как test и прочие логические аналоги (плюс тогда мб даже имеет смысл сделать сохраняющие результат обычные and/or/xor не устанавливающими флаги)
Не голосовал, есичо — как-то пропустил, завертевшись, хотя объявление раньше видел.
У меня вопрос и просьба к авторам, поделитесь пожалуйста информацией, в чём и на чем вы рисуете все эти восхитительные работы?
Про себя могу сказать:
работа 9 — liv1 была нарисована в приложении для iPad PixelStudio и сконвертирована из png в scr с помощью Multipaint
работа 8 — liv2 была нарисована в Photoshop и сконвертирована из png в scr с помощью Multipaint (рисовал в photoshop, чтобы записать видео рисовки полностью, на десктопе это делать гораздо проще)
Насколько я понял, картинка родилась как вольная сюжетная интерпретация имени Лив Тайлер. Был бы интересно узнать историю создания.