Serguey Zefirov (thesz) wrote,
Serguey Zefirov
thesz

Categories:

Не могу молчать.

Итак, как конфигурируется память в FPGA. Память в FPGA двухпортовая, то есть, в неё можно читать и писать одновременно. Что прикольней, у неё можно конфигурировать ширину входов (на запись) и выходов (на чтение). То есть, я могу записывать, допустим, два байта, а читать четыре. При этом на запись есть маски, чтобы можно было записать один из байтов, не трогая другой.

Если это доступно на FPGA, то это доступно и на ASIC. Потому, что это почти тривиально.

Представим себе, что мы можем писать и читать сразу 8 регистров. В восемь регистров можно уложить счетчик команд, указатель стека возвратов, указатель стека данных, регистр с вершиной стека, и ещё четыре регистра на разные нужды. Это означает, что мы можем за один такт выполнить, практически, одну команду стековой машины.

Если у нас 64 регистра, то мы можем вести 7 таких машин на одном RISC ядре. Это означает, что мы можем иметь глубину конвейера у ядра в 7 шагов и полностью загрузить наше ядро. Мы, также, можем добавить признаки готовности к нашим машинам и у нас получится приятное OOO для стекового кода.

Почему 7 машин? Потому, что одно окно будет занято обычными регистрами RISC, включая регистр с константой 0.

Что это даст?

Во-первых, компактность кода. Код для стековой машины в стиле Форт в 2+ раз компактней кода однооперандной регистровой машины типа x86. При этом код x86 (не x86-64) в два+ раз компактней кода типичного RISC.

Те, кто хотят сослаться на Dalvik vs JVM, прошу заметить, что JVM стековая машина, но код в ней не в стиле Форта. Единственный возможный вызов в JVM это вызов метода, поэтому там нет вынесения одинакового кода в подпрограмму, как это принято в Форте.

Плюс, выполняя команды RISC в определенном окне стековой машины, мы можем сэкономить на адресации регистров - 3 бита вместо 6. Это 9 бит, то есть, 23 бита при сохранении кодирования вместо 32. Четверть код урезана просто так. Principled Thumb, так сказать.

Во-вторых, чрезвычайно дешевые зеленые нити и "hyperthreading". Дешевле, чем у библиотеки времени поддержки ghc. Переключение контекста в пяток тактов - самое то.

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

В-четвертых, стековая машина чрезвычайно удобна для выполнения языков программирования с ленивой семантикой. См. TIGRE и Reduceron. ;)

Потребуется более сложный кэш данных - на два запроса (выборка команд и чтение/запись операндов/результата) одновременно.

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

И напоследок можно это всё отлакировать сверху векторной машиной. С векторами слов в 128-256. Тогда стековая машина будет всего лишь управлять векторной, на которую и падёт проблема обеспечения производительности. По идее, это ещё и сократит размер кода.
Tags: risc, идеи, процессоры, стековые машины
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 7 comments