avr-gcc, ОБРТЙНЕТ

[Nickita A Startcev]

Привет, All !

а помогите плиз с кривым вопросом.
любой компилятор с/с++ никогда не использует вообще все возможные инструкции
нижележащей платформы. я сейчас опять играюсь с фпга и хочу "наколхозить" ядро,
очень похожее на авр (простая 8-битка, зачастую больше и не надо). код под это
ядро, естественно, писать на си (или посоветуйте иное ядро с исходниками на
верилоге, под которое есть хорошие компиляторы си). а если используемый
компилятор использует не все инструкции, то можно съэкономить и на разработке и
на площади ядра, и чуть-чуть на скорости работы, просто не реализуя эти
инструкции.

так вот, вопрос. где-как кроме тупого брутфорса можно добыть инфу о том, какие
инструкции реально генерирует, например, avr-gcc при компиляции под некий любой
конкретный кристалл?


. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... башни-виртуалы

[Nickita A Startcev]

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

кстати, а насколько эффективно гцц умеет использовать стопицот регистров? а
если урезать их число, то эффективность гцц-кода сильно упадет, или не очень?

[Valentin Nechayev]

Hi,

>>>> Nickita A Startcev wrote:

NAS> так вот, вопрос. где-как кроме тупого брутфорса можно добыть инфу о
NAS> том, какие инструкции реально генерирует, например, avr-gcc при
NAS> компиляции под некий любой конкретный кристалл? или, может быть, есть
NAS> какие-то хитрые тесты для гцц, чтоб синтезировать примерно все
NAS> возможные ассемблерные инструкции и их вариации?

Если есть исходники генератора машкода этой версии из RTL - все, что там есть
:)
Для x86 там, например, нет xchg (ибо SSA), rcl, rcr.

NAS> кстати, а насколько эффективно гцц умеет использовать стопицот
NAS> регистров? а если урезать их число, то эффективность гцц-кода сильно
NAS> упадет, или не очень?

Упадёт, но не очень. При SSA это всего лишь вопрос, какие значения кэшировать в
регистрах.


-netch-

... Бойся данайцев, данайцы - ребята простые.

[Nickita A Startcev]

Привет, Valentin !


10 Aug 16 , 13:51 Valentin Nechayev писал к Nickita A Startcev:

NAS>> так вот, вопрос. где-как кроме тупого брутфорса можно добыть

NAS>> инфу о том, какие инструкции реально генерирует, например,
NAS>> avr-gcc при компиляции под некий любой конкретный кристалл? или,
NAS>> может быть, есть какие-то хитрые тесты для гцц, чтоб
NAS>> синтезировать примерно все возможные ассемблерные инструкции и
NAS>> их вариации?

VN> Если есть исходники генератора машкода этой версии из RTL - все, что
VN> там есть :) Для x86 там, например, нет xchg (ибо SSA), rcl, rcr.

ээ.. не совсем понял. исходники авр-гцц скачать могу, собрать могу, итд итп.
куда примерно в них смотреть? или есть цланг или еще что вменяемое под эти
восьмибитки?
да, интересно avr (atmel/atmega)

NAS>> кстати, а насколько эффективно гцц умеет использовать стопицот
NAS>> регистров? а если урезать их число, то эффективность гцц-кода

NAS>> сильно упадет, или не очень?

VN> Упадёт, но не очень. При SSA это всего лишь вопрос, какие значения
VN> кэшировать в регистрах.

хм. то есть, сильно резать число регистров - не стоит, если рядом же придется
творить рам/ром заметного размера.

и да, для ориентира, ядро типа z80/avr занимает порядка 5к-80к "транзисторов",
что очень даже соизмеримо с 1-10к байт динамической памяти.

и да. я как-то не очень понимаю из каких соображений avr делали именно такую
систему команд, где опкод местами размазан вокруг параметров, а не
сконцентрирован одной кучей? или я где-то что-то не просёк, или у них довольно
абсурдная местами логика декодирования опкодов, хотя, казалось бы, если делать
всё с нуля, то можно эту логику сделать более примитивной, а значит более
быстрой и/или энергоэкономичной.

. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev

... Кариес - это от слова кара?

[Valentin Nechayev]

Hi,

>>>> Nickita A Startcev wrote:

VN>> Если есть исходники генератора машкода этой версии из RTL - все,

VN>> что там есть :) Для x86 там, например, нет xchg (ибо SSA), rcl,
VN>> rcr.

NAS> ээ.. не совсем понял. исходники авр-гцц скачать могу, собрать могу,
NAS> итд итп. куда примерно в них смотреть? или есть цланг или еще что
NAS> вменяемое под эти восьмибитки? да, интересно avr (atmel/atmega)

Если соблюдены стандартные правила на размещение файлов, будет каталог
config/avr, а в нём *.md файлы. Там язык - LISPоподобный, тебе нужны функции
типа define_insn. Вот короткий пример для x86:

(define_insn "*movsi_xor"
[(set (match_operand:SI 0 "register_operand" "=r")
(match_operand:SI 1 "const0_operand" "i"))
(clobber (reg:CC FLAGS_REG))]
"reload_completed && (!TARGET_USE_MOV0 || optimize_size)"
"xor{l}\t{%0, %0|%0, %0}"
[(set_attr "type" "alu1")
(set_attr "mode" "SI")
(set_attr "length_immediate" "0")])

тут генерируется xor, а также проверяются предусловия на операнды, ставятся
признаки, что она меняет, с кем вместе шедулится, и т.п.

NAS>>> кстати, а насколько эффективно гцц умеет использовать стопицот
NAS>>> регистров? а если урезать их число, то эффективность гцц-кода
NAS>>> сильно упадет, или не очень?

VN>> Упадёт, но не очень. При SSA это всего лишь вопрос, какие значения
VN>> кэшировать в регистрах.

NAS> хм. то есть, сильно резать число регистров - не стоит, если рядом же
NAS> придется творить рам/ром заметного размера.

Сравни цену общения с регистром и с памятью. При малом количестве регистров
надо будет вытеснять данные в стек/память.

NAS> и да, для ориентира, ядро типа z80/avr занимает порядка 5к-80к
NAS> "транзисторов", что очень даже соизмеримо с 1-10к байт динамической
NAS> памяти.

А на сколько оно меняется от увеличения количества регистров?

NAS> и да. я как-то не очень понимаю из каких соображений avr делали именно
NAS> такую систему команд, где опкод местами размазан вокруг параметров, а
NAS> не сконцентрирован одной кучей? или я где-то что-то не просёк, или у
NAS> них довольно абсурдная местами логика декодирования опкодов, хотя,
NAS> казалось бы, если делать всё с нуля, то можно эту логику сделать более
NAS> примитивной, а значит более быстрой и/или энергоэкономичной.

Приведи пару примеров. А вообще "концентрировать" опкод в начале далеко не
полезно, полезнее задавать то, что определяет размер команды, параметров и так
далее.

Вот пример такого ляпа для x86. Команды основной арифметической группы, типа
ADD, имеют в первом байте двухбитовое поле варианта 8/16 бит и m*r->r или
m*r->m. Прочтя этот байт (условно говоря, такт) и декодировав (ещё такт), надо
прочесть второй, декодировать его (уже 4такта) и после этого понять режим
адресации (регистр, память без смещения, 8 или 16-битное смещение).
Если же вместо этого поле MOD вынести в первый байт, а разрядность операции и
порядок операндов - вместо поля MOD во второй, то на чтение и декодирование
потребуется не 4, а 3 такта, потому что одновременно с чтением второго можно
будет решить, потребуется ли вычитывать дальше смещение аргумента в памяти.
(А в современных x86 такой задержки нет, но логика построения команды резко
усложняет блок разбора.)

Скорее всего, AVRовцы уже видели проход по таким граблям.


-netch-

... Мы союз полночных лунатиков. До Луны дорога нам скатертью!

[Nickita A Startcev]

Привет, Valentin !


12 Aug 16 , 09:20 Valentin Nechayev писал к Nickita A Startcev:

VN>>> Если есть исходники генератора машкода этой версии из RTL - все,
VN>>> что там есть :) Для x86 там, например, нет xchg (ибо SSA), rcl,
VN>>> rcr.

NAS>> ээ.. не совсем понял. исходники авр-гцц скачать могу, собрать

NAS>> могу, итд итп. куда примерно в них смотреть? или есть цланг или
NAS>> еще что вменяемое под эти восьмибитки? да, интересно avr
NAS>> (atmel/atmega)

VN> Если соблюдены стандартные правила на размещение файлов, будет каталог
VN> config/avr, а в нём *.md файлы. Там язык - LISPоподобный, тебе нужны
VN> функции типа define_insn. Вот короткий пример для x86:

VN> (define_insn "*movsi_xor"
VN> [(set (match_operand:SI 0 "register_operand" "=r")
VN> (match_operand:SI 1 "const0_operand" "i"))
VN> (clobber (reg:CC FLAGS_REG))]
VN> "reload_completed && (!TARGET_USE_MOV0 || optimize_size)"
VN> "xor{l}\t{%0, %0|%0, %0}"
VN> [(set_attr "type" "alu1")
VN> (set_attr "mode" "SI")
VN> (set_attr "length_immediate" "0")])

VN> тут генерируется xor, а также проверяются предусловия на операнды,
VN> ставятся признаки, что она меняет, с кем вместе шедулится, и т.п.

ага, спасибо. направление поисков понятно: используются только помянутые там
инструкции и их методы адресации.

NAS>>>> кстати, а насколько эффективно гцц умеет использовать стопицот
NAS>>>> регистров? а если урезать их число, то эффективность гцц-кода
NAS>>>> сильно упадет, или не очень?

VN>>> Упадёт, но не очень. При SSA это всего лишь вопрос, какие

VN>>> значения кэшировать в регистрах.

NAS>> хм. то есть, сильно резать число регистров - не стоит, если

NAS>> рядом же придется творить рам/ром заметного размера.

VN> Сравни цену общения с регистром и с памятью. При малом количестве
VN> регистров надо будет вытеснять данные в стек/память.

да, но при этом для регистров нужен мультиплексор, размер которого растет
примерно как квадрат числа регистров (плюс домножить на разрядность)

NAS>> и да, для ориентира, ядро типа z80/avr занимает порядка 5к-80к
NAS>> "транзисторов", что очень даже соизмеримо с 1-10к байт

NAS>> динамической памяти.

VN> А на сколько оно меняется от увеличения количества регистров?

порядка 6 транзисторов на 1 бит SRAM, плюс (де)мультиплексоры для доступа ко
всем регистрам, а они растут примерно как квадрат числа вариантов.

кстати, у z80 алу 4-битное, что заметно экономит транзисторы, но увеличивает
такты. но, типично, внешняя память и так требует 2 и более тактов (для
регистров же можно по одному фронту считать, по второму записать, итого 1
такт). итого, в принципе интересно сделать узкое АЛУ на повышенной частоте. или
даже не повышенной, учитывая что типичная память сейчас хоть и дофига герц, но
и очень дофига тактов.

NAS>> и да. я как-то не очень понимаю из каких соображений avr делали

NAS>> именно такую систему команд, где опкод местами размазан вокруг
NAS>> параметров, а не сконцентрирован одной кучей? или я где-то
NAS>> что-то не просёк, или у них довольно абсурдная местами логика
NAS>> декодирования опкодов, хотя, казалось бы, если делать всё с
NAS>> нуля, то можно эту логику сделать более примитивной, а значит
NAS>> более быстрой и/или энергоэкономичной.

VN> Приведи пару примеров.

у АВР система опкодов, в первом приближении, красивая - почти все инструкции
ровно 16 бит, у некоторых после этих 16 бит идет еще 16 бит операнда (длинные
переходы, загрузка непосредственного значения в регистр, итп).
то есть, логика кристалла обязатеьно вычитывает первые 16 бит, обрабатывает их,
опционально читает еще 16 бит. типовая растактовка - 1 такт для 1-словных
инструкций, 2 такта для 2-словных, доп.пенальти для переходов (конвейер
сбивается).

итого, весь опкод всегда или почти всегда сидит в первых 16 бит, которые
вычитываются на первом такте, но при этом, например, у
cpc/sbc/add/adc/rol опкод сидит в первых 6 битах и потом 10 битов операндов,
часть двухрегистровых команд (допустимы не для всех регистров) имеют 4 бита
операнда и 4+4+4 битов для 2 орегистров и еще imm.

при этом у заметной части инструкций опкод - это не первые 3-8-12 бит, а первые
5-6 плюс последние 3-4, что немного нелогично на мой взгляд.

VN> А вообще "концентрировать" опкод в начале
VN> далеко не полезно, полезнее задавать то, что определяет размер
VN> команды, параметров и так далее.

VN> Вот пример такого ляпа для x86.

у х86 длина опкода от 1 и до чуть ли не 10 байт со всеми остановками, (а потом
чуть ли не до 3*64 бит адресов/смещений) сегментными префиксами, mod/reg/rm
байтами, итп. это немного экономит память, но сильно осложняет декодирование. у
АВР опкод всегда (ну, по крайней мере в сериях атмега/аттини) в первых 16
битах, а команда итого или вот эти 16 бит, или 16 бит плюс еще 16 бит имм
операнд.

VN> Команды основной арифметической
VN> группы, типа ADD, имеют в первом байте двухбитовое поле варианта 8/16
VN> бит и m*r->r или m*r->m. Прочтя этот байт (условно говоря, такт) и
VN> декодировав (ещё такт), надо прочесть второй, декодировать его (уже
VN> 4такта) и после этого понять режим адресации (регистр, память без
VN> смещения, 8 или 16-битное смещение). Если же вместо этого поле MOD
VN> вынести в первый байт, а разрядность операции и порядок операндов -
VN> вместо поля MOD во второй, то на чтение и декодирование потребуется не
VN> 4, а 3 такта, потому что одновременно с чтением второго можно будет
VN> решить, потребуется ли вычитывать дальше смещение аргумента в памяти.
VN> (А в современных x86 такой задержки нет, но логика построения команды
VN> резко усложняет блок разбора.)

да, я примерно представляю х86 - там надо декодировать от 1 до чуть ли не 20
байт, чтоб опознать инструкцию, а у АВРок почти ровно два варианта - или 16 бит
инструкция, или 16+16 инструкция+операнд.

VN> Скорее всего, AVRовцы уже видели проход по таким граблям.

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

я бы, например, весь "опкод" пихал в старшие биты первого слова, а в младших
тупо-одинаково размещал операнды. а у них и операнды то 4 то 5 бит, и их
расположение в опкоде разное. то есть, нельзя из опкода тупо вынести 4, 4+4, 5,
5+5, 4+4+4 бит операндов тупо на внутренние шины и адресовать ими "регистры"

. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev

... Книга Жалоб была очень жалобной

[Alexander Krotov]

Valentin Nechayev <Valentin...@p300.f68.n463.z2.fidonet.org> wrote:
VN> Если есть исходники генератора машкода этой версии из RTL - все, что там есть
VN> :)
VN> Для x86 там, например, нет xchg (ибо SSA), rcl, rcr.
VN>

xchg там таки есть, но использовать нужное правило gcc отказывается даже под пытками.
Провошкался минут пятнадцать - так и не смог заставить его сгенерировать эту
инструкцию для исходника на C. (и SSA тут непричем).

NAS>> кстати, а насколько эффективно гцц умеет использовать стопицот
NAS>> регистров? а если урезать их число, то эффективность гцц-кода сильно
NAS>> упадет, или не очень?

VN> Упадёт, но не очень. При SSA это всего лишь вопрос, какие значения кэшировать в
VN> регистрах.

Давно не лазил к нему внутрь, но раньше регистры gcc распределял сильно после
того как забыл все SSA.

--
-ank

[Valentin Nechayev]

Hi,

>>>> Nickita A Startcev wrote:

VN>> Сравни цену общения с регистром и с памятью. При малом количестве
VN>> регистров надо будет вытеснять данные в стек/память.

NAS> да, но при этом для регистров нужен мультиплексор, размер которого
NAS> растет примерно как квадрат числа регистров (плюс домножить на
NAS> разрядность)

Почему как квадрат - я не понял. Количество шин фиксировано (грубо говоря, если
копирование между регистрами тоже через АЛУ, то по одной на операнд и
результат, то есть 3). Мультиплексор - по одному входу или выходу на каждый
регистр и ширина по количеству бит адреса, итого O(n*log(n)), а не
O(n^2*log(n)).

NAS> кстати, у z80 алу 4-битное, что заметно экономит транзисторы, но
NAS> увеличивает такты. но, типично, внешняя память и так требует 2 и более
NAS> тактов

От организации зависит, у 6502, например, проходило за 1 такт. Хотя у него по
сравнению с ровесниками-аналогами частота была в 2-4 раза ниже.

NAS> (для регистров же можно по одному фронту считать, по второму
NAS> записать, итого 1 такт). итого, в принципе интересно сделать узкое
NAS> АЛУ
NAS> на повышенной частоте. или даже не повышенной, учитывая что типичная
NAS> память сейчас хоть и дофига герц, но и очень дофига тактов.

Это DRAM. А перед этим говорили про SRAM.

NAS> у АВР система опкодов, в первом приближении, красивая - почти все
NAS> инструкции ровно 16 бит, у некоторых после этих 16 бит идет еще 16 бит
NAS> операнда (длинные переходы, загрузка непосредственного значения в
NAS> регистр, итп). то есть, логика кристалла обязатеьно вычитывает первые
NAS> 16 бит, обрабатывает их, опционально читает еще 16 бит. типовая
NAS> растактовка - 1 такт для 1-словных инструкций, 2 такта для 2-словных,
NAS> доп.пенальти для переходов (конвейер сбивается).

То есть какой-то конвейер есть? Иначе такие малые числа не получатся, и вообще,
ты говорил, что память это "2 и более" тактов. (Или это другая память?)

NAS> итого, весь опкод всегда или почти всегда сидит в первых 16 бит,
NAS> которые вычитываются на первом такте, но при этом, например,
NAS> у cpc/sbc/add/adc/rol опкод сидит в первых 6 битах и потом 10 битов
NAS> операндов, часть двухрегистровых команд (допустимы не для всех
NAS> регистров) имеют 4 бита операнда и 4+4+4 битов для 2 орегистров и еще
NAS> imm.

Главное, чтобы первый чанк указывал длину команды. Это выполняется.

NAS> при этом у заметной части инструкций опкод - это не первые 3-8-12 бит,
NAS> а первые 5-6 плюс последние 3-4, что немного нелогично на мой взгляд.

Ты ещё на RISC-V посмотри. Там ещё хуже - кроме кода операции, который разрезан
на 2-3 части, immediate может быть разорвано до 4 частей. Зато они описывают,
что этим экономят на мультиплексорах в декодере.

А ещё погугли Chen-Ho encoding.

NAS> у х86 длина опкода от 1 и до чуть ли не 10 байт со всеми остановками,
NAS> (а потом чуть ли не до 3*64 бит адресов/смещений) сегментными
NAS> префиксами, mod/reg/rm байтами, итп. это немного экономит память, но
NAS> сильно осложняет декодирование.

Именно.

NAS> я бы, например, весь "опкод" пихал в старшие биты первого слова, а в
NAS> младших тупо-одинаково размещал операнды. а у них и операнды то 4 то 5
NAS> бит, и их расположение в опкоде разное. то есть, нельзя из опкода тупо
NAS> вынести 4, 4+4, 5, 5+5, 4+4+4 бит операндов тупо на внутренние шины и
NAS> адресовать ими "регистры"

Думаю, они наоборот упростили внутреннюю разводку.


-netch-

... Это не ключевой момент, а дополнительная неприятность.

[Valentin Nechayev]

Hi,

>>>> Alexander Krotov wrote:

VN>> что там есть :) Для x86 там, например, нет xchg (ибо SSA), rcl,
VN>> rcr.

AK> xchg там таки есть, но использовать нужное правило gcc отказывается
AK> даже под пытками. Провошкался минут пятнадцать - так и не смог
AK> заставить его сгенерировать эту инструкцию для исходника на C. (и SSA
AK> тут непричем).

SSA очень даже при чём: в его логику не ложится никакой обмен значениями. А
"правило есть" это на уровне *swapsi определена, но нигде не вызывается, так
что если её урезать оттуда, то ничего не изменится.


-netch-

... Программная система "Медуза". Переименования файлов нет.
... Удаления файлов нет. Заполнена NOPами.

[Nickita A Startcev]

Привет, Valentin !


14 Aug 16 , 07:30 Valentin Nechayev писал к Nickita A Startcev:

>>>>> Nickita A Startcev wrote:

VN>>> Сравни цену общения с регистром и с памятью. При малом

VN>>> количестве регистров надо будет вытеснять данные в стек/память.

NAS>> да, но при этом для регистров нужен мультиплексор, размер

NAS>> которого растет примерно как квадрат числа регистров (плюс
NAS>> домножить на разрядность)

VN> Почему как квадрат - я не понял.

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

VN> Количество шин фиксировано (грубо
VN> говоря, если копирование между регистрами тоже через АЛУ, то по одной
VN> на операнд и результат, то есть 3). Мультиплексор - по одному входу
VN> или выходу на каждый регистр и ширина по количеству бит адреса, итого
VN> O(n*log(n)), а не O(n^2*log(n)).

навскидку, (де)мультиплексор на N+1 входов делается из N (де)мультиплексоров на
2 входа, не меньше. но у него выбор выхода разряженный, а разряжение делаем
дешифратором этак примерно как произведение ширины входа на ширину выхода то
есть, N*2^N по числу регистров (на часть битов широкое или-не, его выход и
остальные биты на широкое И. таких блоков примерно по числу выходов).

то есть, для 2^A регистров/шин по Б бит надо порядка 4*(Б*А-1)*2^A транзисторов
обвязки, если Ъ-и-не / Ъ-или-не / Ъ-и / Ъ-или требуют 4*Ъ транзисторов (2*Ъ
комплементарных пар).

но я не очень настоящий сварщик.

NAS>> кстати, у z80 алу 4-битное, что заметно экономит транзисторы, но
NAS>> увеличивает такты. но, типично, внешняя память и так требует 2 и

NAS>> более тактов

VN> От организации зависит, у 6502, например, проходило за 1 такт. Хотя у
VN> него по сравнению с ровесниками-аналогами частота была в 2-4 раза
VN> ниже.

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

первые "негонящиеся" z80 были nMOS, а те, которые не 3.5 а до этак 14МГц -
CMOS.

можно сделать АЛУ на 8 бит и считать операции типа 8+8 за 1 такт,
а можно АЛУ на 4 бита и считать раза в два дольше по тактам, но зато экономить
площадь и чуть поднять тактовую.

NAS>> (для регистров же можно по одному фронту считать, по второму
NAS>> записать, итого 1 такт). итого, в принципе интересно сделать

NAS>> узкое АЛУ на повышенной частоте. или даже не повышенной,
NAS>> учитывая что типичная память сейчас хоть и дофига герц, но и
NAS>> очень дофига тактов.

VN> Это DRAM. А перед этим говорили про SRAM.

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

и да, срам - порядка 6х транзисторов по сравнению с драм.

NAS>> у АВР система опкодов, в первом приближении, красивая - почти

NAS>> все инструкции ровно 16 бит, у некоторых после этих 16 бит идет
NAS>> еще 16 бит операнда (длинные переходы, загрузка
NAS>> непосредственного значения в регистр, итп). то есть, логика
NAS>> кристалла обязатеьно вычитывает первые 16 бит, обрабатывает их,
NAS>> опционально читает еще 16 бит. типовая растактовка - 1 такт для
NAS>> 1-словных инструкций, 2 такта для 2-словных, доп.пенальти для
NAS>> переходов (конвейер сбивается).

VN> То есть какой-то конвейер есть?

навскидку, там тупо по 1 такту на выборку очередного слова команд, итого
короткие за такт, длинные за два.
и да, в оригинале в атмегах конвейер из 2 стадий - выборка и выполнение.

VN> Иначе такие малые числа не получатся,

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

плюс, опционально, линии типа wait, которые стопорят что-то если где-то не
успеваем (например, если запись еще не прошла, или чтение из медленной внешней
памяти)

VN> и вообще, ты говорил, что память это "2 и более" тактов. (Или это
VN> другая память?)

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

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

NAS>> итого, весь опкод всегда или почти всегда сидит в первых 16 бит,
NAS>> которые вычитываются на первом такте, но при этом, например,
NAS>> у cpc/sbc/add/adc/rol опкод сидит в первых 6 битах и потом 10

NAS>> битов операндов, часть двухрегистровых команд (допустимы не для
NAS>> всех регистров) имеют 4 бита операнда и 4+4+4 битов для 2
NAS>> орегистров и еще imm.

VN> Главное, чтобы первый чанк указывал длину команды. Это выполняется.

NAS>> при этом у заметной части инструкций опкод - это не первые

NAS>> 3-8-12 бит, а первые 5-6 плюс последние 3-4, что немного
NAS>> нелогично на мой взгляд.

VN> Ты ещё на RISC-V посмотри. Там ещё хуже - кроме кода операции, который
VN> разрезан на 2-3 части, immediate может быть разорвано до 4 частей.

а там это случайно не тяжкое наследство, типа как 386PM режим имеет в
наследство от 286РМ ряд рудиментов (типа порезаных битовых полей в регистрах)?

VN> Зато они описывают, что этим экономят на мультиплексорах в декодере.

VN> А ещё погугли Chen-Ho encoding.

спасибо за наводки

NAS>> у х86 длина опкода от 1 и до чуть ли не 10 байт со всеми

NAS>> остановками, (а потом чуть ли не до 3*64 бит адресов/смещений)
NAS>> сегментными префиксами, mod/reg/rm байтами, итп. это немного
NAS>> экономит память, но сильно осложняет декодирование.

VN> Именно.

NAS>> я бы, например, весь "опкод" пихал в старшие биты первого слова,

NAS>> а в младших тупо-одинаково размещал операнды. а у них и операнды
NAS>> то 4 то 5 бит, и их расположение в опкоде разное. то есть,
NAS>> нельзя из опкода тупо вынести 4, 4+4, 5, 5+5, 4+4+4 бит
NAS>> операндов тупо на внутренние шины и адресовать ими "регистры"

VN> Думаю, они наоборот упростили внутреннюю разводку.

как именно это упрощает мне не очень понятно.

. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev

... с конями жить - по конски ржать

[Valentin Nechayev]

Hi,

>>>> Nickita A Startcev wrote:

VN>> Почему как квадрат - я не понял.

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

Hу даже так у тебя вертикальных по количеству шин, а не регистров.
В нормальной реализации можно обойтись где-то двумя входными и одной выходной
для АЛУ и одной транзитной для параллельных пересылок.

VN>> Количество шин фиксировано (грубо
VN>> говоря, если копирование между регистрами тоже через АЛУ, то по

VN>> одной на операнд и результат, то есть 3). Мультиплексор - по
VN>> одному входу или выходу на каждый регистр и ширина по количеству
VN>> бит адреса, итого O(n*log(n)), а не O(n^2*log(n)).

NAS> навскидку, (де)мультиплексор на N+1 входов делается из N
NAS> (де)мультиплексоров на 2 входа, не меньше. но у него выбор выхода
NAS> разряженный, а разряжение делаем дешифратором этак примерно как
NAS> произведение ширины входа на ширину выхода то есть, N*2^N по числу
NAS> регистров (на часть битов широкое или-не, его выход и остальные биты
NAS> на широкое И. таких блоков примерно по числу выходов).

Мнэээ... тут же шины. Если выход с Z-состоянием (а сейчас такое делается
влёгкую), просто на каждый бит каждого регистра на каждую шину нужно "включено"
или "выключено", с тем, что только один имеет право быть "включено".
Тогда получается один такой шлюз по биту на регистр, а дополнительно
управляющий блок с демультиплексором для генерации этих управляющих разрешений
- размер которого не зависит от количества регистров, а только для каждой шины.
(Вот если Z нельзя - тогда сложнее.)

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

А коммутационная матрица полного N*N, мне кажется, совсем не в тему.

NAS>>> кстати, у z80 алу 4-битное, что заметно экономит транзисторы, но
NAS>>> увеличивает такты. но, типично, внешняя память и так требует 2 и
NAS>>> более тактов

VN>> От организации зависит, у 6502, например, проходило за 1 такт.

VN>> Хотя у него по сравнению с ровесниками-аналогами частота была в
VN>> 2-4 раза ниже.

NAS> а тут надо аккуратно смотреть
NAS> есть nMOS, а есть CMOS - втрое требует примерно вдвое больше
NAS> транзисторов, но зато радикально быстрее (во втором - перезаряжаем
NAS> паразитные емкости через открытый канал, а в первом тупо вкл/выкл тока
NAS> в резисторе-подтяжке и перезарядка через резистор).

Мнэээ. Во-первых, как я слышал, nMOS заведомо быстрее именно из за того, что он
n-only (дырочная проводимость раз в 5 медленнее электронной), именно потому
существуют CMOS и nMOS, но только псих стал бы сейчас делать pMOS - CMOS и чуть
быстрее pMOS, и в разы холоднее.
Во-вторых, как раз для nMOS есть реализации типа "при 1 на clock считаем, при 0
на clock заряжаем", и очень популярные (а для общей скорости в разных частях
схемы разная полярность clock).

NAS> первые "негонящиеся" z80 были nMOS, а те, которые не 3.5 а до этак
NAS> 14МГц - CMOS.

CMOS медленнее, это заведомый факт. Если такое соотношение скоростей - это
из-за техпроцесса, но, как я понял, CMOS версии были сильно позже.

NAS> можно сделать АЛУ на 8 бит и считать операции типа 8+8 за 1 такт,
NAS> а можно АЛУ на 4 бита и считать раза в два дольше по тактам, но зато
NAS> экономить площадь и чуть поднять тактовую.

Для средства типа Z80 два такта на операцию АЛУ ещё разумно. Для чего-то хотя
бы уровня начального 8086 - уже точно нет.

NAS>>> (для регистров же можно по одному фронту считать, по второму
NAS>>> записать, итого 1 такт). итого, в принципе интересно сделать
NAS>>> узкое АЛУ на повышенной частоте. или даже не повышенной,
NAS>>> учитывая что типичная память сейчас хоть и дофига герц, но и
NAS>>> очень дофига тактов.

VN>> Это DRAM. А перед этим говорили про SRAM.

NAS> "внешняя" срам обычно по одному фронту фиксирует адрес, а по
NAS> следующему только гарантирует валидность данных.

Hу так это 2 такта. А не ~30, как у DDR3 на переключение строки.

VN>> То есть какой-то конвейер есть?

NAS> навскидку, там тупо по 1 такту на выборку очередного слова команд,
NAS> итого короткие за такт, длинные за два. и да, в оригинале в атмегах
NAS> конвейер из 2 стадий - выборка и выполнение.

Hу тогда память быстрая - по фронту получила адрес, по спаду ответила.
Hо всё равно тогда ещё пол-такта минимум, прежде чем процессор декодирует
команду до такой степени, чтобы смог выбирать, что дальше делать.
Тогда предвыборка следующего слова всегда тут есть, чтобы не терять такт.

VN>> Иначе такие малые числа не получатся,

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

1) Конвейер даже на одну предвыборку это таки не "самая тупая" :)
2) Это если всё АЛУ успевает отработать за это время. Видимо, команды простые
до ужаса.

VN>> и вообще, ты говорил, что память это "2 и более" тактов. (Или это
VN>> другая память?)

NAS> внутренние регистры - без такта, асинхронно, можно запихнуть в АЛУ.
NAS> весь (полу)такт оно будет устаканиваться. то есть, между любыми двумя
NAS> фронтами можно получить результат операции (по одному фронту/такту
NAS> активируем демультиплексор из регистров/шины в алу, по следующему
NAS> активируем мультиплексор из алу в регистры/шину).

NAS> чтение внешней памяти - такое заведомо недопустимо. итого, ввод
NAS> адреса, устаканивание адреса, защелкивание адреса*, вывод результата,
NAS> устаканивание результата, чтение* результата. типично, по (*) идет
NAS> какой-нибудь фронт тактового сигнала. обычно и там и там восходящий,
NAS> итого доп.задержка 1 такт.

То есть из этих двух 1 на чтение и 1 на АЛУ? Hу тогда ok.

VN>> Ты ещё на RISC-V посмотри. Там ещё хуже - кроме кода операции,

VN>> который разрезан на 2-3 части, immediate может быть разорвано до 4
VN>> частей.

NAS> а там это случайно не тяжкое наследство, типа как 386PM режим имеет в
NAS> наследство от 286РМ ряд рудиментов (типа порезаных битовых полей в
NAS> регистрах)?

Hет, они его с нуля нарисовали.

NAS>>> то 4 то 5 бит, и их расположение в опкоде разное. то есть,
NAS>>> нельзя из опкода тупо вынести 4, 4+4, 5, 5+5, 4+4+4 бит
NAS>>> операндов тупо на внутренние шины и адресовать ими "регистры"

VN>> Думаю, они наоборот упростили внутреннюю разводку.

NAS> как именно это упрощает мне не очень понятно.

Аналогично тому же Chen-Ho - меньше шин и демультиплексоров...


-netch-

... "Сам ты дятел!" - подумал Мюллер.

[Nickita A Startcev]

Привет, Valentin !


23 Aug 16 , 17:37 Valentin Nechayev писал к Nickita A Startcev:

>>>>> Nickita A Startcev wrote:

VN>>> Почему как квадрат - я не понял.

NAS>> на вход типа линиями по вертикали подаем линии от входной шины.
NAS>> на выход типа линиями по горизонтали подключаем линии от

NAS>> регистров. на каждом пересечении нужно иметь/неиметь соединение.

NAS>> это для однобитных регистров.
NAS>> для многобитных - тупо копипастим согласно разрядности.

VN> Hу даже так у тебя вертикальных по количеству шин, а не регистров.
VN> В нормальной реализации можно обойтись где-то двумя входными и одной
VN> выходной для АЛУ и одной транзитной для параллельных пересылок.

VN>>> Количество шин фиксировано (грубо
VN>>> говоря, если копирование между регистрами тоже через АЛУ, то по
VN>>> одной на операнд и результат, то есть 3). Мультиплексор - по
VN>>> одному входу или выходу на каждый регистр и ширина по количеству
VN>>> бит адреса, итого O(n*log(n)), а не O(n^2*log(n)).

NAS>> навскидку, (де)мультиплексор на N+1 входов делается из N
NAS>> (де)мультиплексоров на 2 входа, не меньше. но у него выбор

NAS>> выхода разряженный, а разряжение делаем дешифратором этак
NAS>> примерно как произведение ширины входа на ширину выхода то есть,
NAS>> N*2^N по числу регистров (на часть битов широкое или-не, его
NAS>> выход и остальные биты на широкое И. таких блоков примерно по
NAS>> числу выходов).

VN> Мнэээ... тут же шины.

всё равно чтоб "подать из/на шины из/на регистр" нужна кучка логики
подавать/неподавать с разрядностью лог2 от числе регистров.
но да, не квадрат, меньше.

NAS>> а тут надо аккуратно смотреть
NAS>> есть nMOS, а есть CMOS - втрое требует примерно вдвое больше
NAS>> транзисторов, но зато радикально быстрее (во втором -

NAS>> перезаряжаем паразитные емкости через открытый канал, а в первом
NAS>> тупо вкл/выкл тока в резисторе-подтяжке и перезарядка через
NAS>> резистор).

VN> Мнэээ. Во-первых, как я слышал, nMOS заведомо быстрее именно из за
VN> того, что он n-only (дырочная проводимость раз в 5 медленнее
VN> электронной),

но перезарядка емкости через резистор медленнее и теплее, чем через канал
транзистора.
отсюда, кстати, странные обычаи типа почаще держать на выводах 1, пореже 1,
индикаторы вешать между выходом и 0, а не выходом и 1.

видать вот эти вот 5 раз весьма пересекаются с потерями на резисторах.

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

VN> именно потому существуют CMOS и nMOS, но только псих
VN> стал бы сейчас делать pMOS - CMOS и чуть быстрее pMOS, и в разы
VN> холоднее. Во-вторых, как раз для nMOS есть реализации типа "при 1 на
VN> clock считаем, при 0 на clock заряжаем", и очень популярные (а для
VN> общей скорости в разных частях схемы разная полярность clock).

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

NAS>> первые "негонящиеся" z80 были nMOS, а те, которые не 3.5 а до

NAS>> этак 14МГц - CMOS.

VN> CMOS медленнее, это заведомый факт. Если такое соотношение скоростей -

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

VN> это из-за техпроцесса, но, как я понял, CMOS версии были сильно
VN> позже.

NAS>> можно сделать АЛУ на 8 бит и считать операции типа 8+8 за 1

NAS>> такт, а можно АЛУ на 4 бита и считать раза в два дольше по
NAS>> тактам, но зато экономить площадь и чуть поднять тактовую.

VN> Для средства типа Z80 два такта на операцию АЛУ ещё разумно. Для
VN> чего-то хотя бы уровня начального 8086 - уже точно нет.

так z80 он весьма вкусный был по командам/регистрам при довольно скромном числе
транзисторов.

NAS>> "внешняя" срам обычно по одному фронту фиксирует адрес, а по
NAS>> следующему только гарантирует валидность данных.

VN> Hу так это 2 такта. А не ~30, как у DDR3 на переключение строки.

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

VN>>> То есть какой-то конвейер есть?

NAS>> навскидку, там тупо по 1 такту на выборку очередного слова

NAS>> команд, итого короткие за такт, длинные за два. и да, в
NAS>> оригинале в атмегах конвейер из 2 стадий - выборка и выполнение.

VN> Hу тогда память быстрая - по фронту получила адрес, по спаду ответила.
VN> Hо всё равно тогда ещё пол-такта минимум, прежде чем процессор
VN> декодирует команду до такой степени, чтобы смог выбирать, что дальше
VN> делать. Тогда предвыборка следующего слова всегда тут есть, чтобы не
VN> терять такт.

у простых команд и декодирование и выполнение в полтакта укладывается.

VN>>> Иначе такие малые числа не получатся,
NAS>> самая тупая реализация процессора. по одному фронту берет

NAS>> команду с шины памяти команд, асинхронно пихает в разбор и
NAS>> исполняющие устройства, а по второму фронту пихает результат
NAS>> исполняющих устройств на выход. декодирование идет одновременно
NAS>> с распихиванием по исполняющим устройствам, а результат можно,
NAS>> например, защелкнуть в триггерах, из которых вытолкнуть наружу
NAS>> не сразу, а с задержкой.

VN> 1) Конвейер даже на одну предвыборку это таки не "самая тупая" :)

не, там прямо с битов опкода на всякие внутренние селекторы.

VN> 2) Это если всё АЛУ успевает отработать за это время. Видимо, команды
VN> простые до ужаса.

угу. без деления и умножения, с отдельным сдвигатором.

VN>>> и вообще, ты говорил, что память это "2 и более" тактов. (Или

VN>>> это другая память?)

NAS>> внутренние регистры - без такта, асинхронно, можно запихнуть в

NAS>> АЛУ. весь (полу)такт оно будет устаканиваться. то есть, между
NAS>> любыми двумя фронтами можно получить результат операции (по
NAS>> одному фронту/такту активируем демультиплексор из регистров/шины
NAS>> в алу, по следующему активируем мультиплексор из алу в
NAS>> регистры/шину).

NAS>> чтение внешней памяти - такое заведомо недопустимо. итого, ввод
NAS>> адреса, устаканивание адреса, защелкивание адреса*, вывод

NAS>> результата, устаканивание результата, чтение* результата.
NAS>> типично, по (*) идет какой-нибудь фронт тактового сигнала.
NAS>> обычно и там и там восходящий, итого доп.задержка 1 такт.

VN> То есть из этих двух 1 на чтение и 1 на АЛУ? Hу тогда ok.

ага.

VN>>> Ты ещё на RISC-V посмотри. Там ещё хуже - кроме кода операции,
VN>>> который разрезан на 2-3 части, immediate может быть разорвано до

VN>>> 4 частей.

NAS>> а там это случайно не тяжкое наследство, типа как 386PM режим

NAS>> имеет в наследство от 286РМ ряд рудиментов (типа порезаных
NAS>> битовых полей в регистрах)?

VN> Hет, они его с нуля нарисовали.

NAS>>>> то 4 то 5 бит, и их расположение в опкоде разное. то есть,
NAS>>>> нельзя из опкода тупо вынести 4, 4+4, 5, 5+5, 4+4+4 бит
NAS>>>> операндов тупо на внутренние шины и адресовать ими "регистры"

VN>>> Думаю, они наоборот упростили внутреннюю разводку.

NAS>> как именно это упрощает мне не очень понятно.

VN> Аналогично тому же Chen-Ho - меньше шин и демультиплексоров...

хм. странно. надо обмозговать.

. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev

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