Чип NXH5104

[Dmitriy40]

kotenok gav в сообщении #1471461 писал(а):

Ну смотрите. Есть данные в ОЗУ, и есть данные в отдельной памяти, которые перемешанны (ну, не совсем) с кодом. Команды доступа туда и туда разные.

Почему разные? Если разные, тогда это не фон Неймана. Неважно ОЗУ там, ПЗУ, Flash или EEPROM, или SSD/HDD, или вообще магнитная лента, важно одни и те же команды или разные, отличия архитектур для программиста в этом (и в физическом разделении шин, но это программисту не часто важно).
Вообще архитектуры фон Неймана и Гарвардская отличаются практически одним параметром: вместе с данными хранится код (и потому позволяет себя читать и перезаписывать как обычные данные) или отдельно. Не физически, а логически, с точки зрения программиста. Как это будет реализовано аппаратно — уже детали, частности, там возможных вариантов море.

Если рассмотреть обычный компьютер (фон Неймана, не забываем), то там да, обычно и данные и код хранятся на HDD (или SSD, в данном случае неважно) и соответственно (потому что нет аппаратных средств выполнять код прямо с HDD или получать с него данные командами доступа к памяти) для обработки/выполнения дублируются в ОЗУ компьютера и лишь оттуда доступны процессору. Но бывают и исключения из этого правила, например ничто не мешает SSD включить в адресное пространство процессора через шину PCI/PCIe (ну, насколько я понимаю их работу). И даже с поддержкой (контроллером диска) операций записи. Получится такое вот медленное ОЗУ где-то в адресном пространстве, ничего сверхудивительного (например память видеокарт именно так доступна процессору, если не ошибаюсь и это не грохнули "во имя прогресса"). В некоторых специфичных применениях это даже будет удобнее/быстрее стандартного механизма подключения SSD.
А можно научить процессор исполнять код и читать данные прямо с HDD (или с SD карты, что кстати проще) ... Сложно, но можно. И не нужно будет вообще ОЗУ и дублирование в нём кода и данных. Непонятно только зачем. Ведь при этом почти гарантированно (за исключительно редким исключением очень специфичных задач) убьётся вся производительность и получите не современный Core-i7 3ГГц, а скажем сорокалетний i8086 5МГц наверное в сотню тысяч раз медленнее.
Так что варианты есть разные, и сделать можно много чего, вопрос лишь как именно и какой ценой (за счёт чего). И собственно зачем.

[kotenok gav]

Dmitriy40 в сообщении #1471468 писал(а):

и соответственно (потому что нет аппаратных средств выполнять код прямо с HDD или получать с него данные командами доступа к памяти) для обработки/выполнения дублируются в ОЗУ компьютера и лишь оттуда доступны процессору.

А, теперь понял.

[Dmitriy40]

Хм, да, я как-то подразумевал что Вы уже ознакомились хотя бы с азами архитектуры компьютеров (ну там процессор, память, устройства ввода-вывода, внешние устройства, линии связи) и понимаете что процессор подключен лишь к памяти и портам устройств ввода-вывода и не имеет команд загрузки jpeg картинки или exe файла с url адреса в интернете по wifi (или не может прочитать код команды из архива zip с ftp сервера в локальной сети) ... Потому и никак не мог понять Вашего вопроса, для меня процессор априори может обращаться лишь к памяти (ну и нескольким портам) и точка, что и как лежит на HDD его вообще никак не касается, он даже не знает о самом существовании HDD, это всё дело ОС. И хотя и знаю про исключения, но не подумал что именно о них и спрашиваете.

[kotenok gav]

Хотя... я не уверен, что я понял. Правильно ли я понимаю, что обычные компьютеры работают как-то так?:

1. BIOS (которая находится в процессоре/другой части материнской платы) заранее знает местонахождение загрузочного сектора на HDD.
2. BIOS копирует загрузочный сектор в RAM.
3. Загрузочный сектор запускается, и копирует что-то там (ну, запуск ОС, и прочее) с HDD в RAM.
4. Что-то там запускается.
При этом, когда любая часть пытается прочитать/записать что-то в HDD, оно читает/записывает это что-то в RAM, которое синхронизирует это с HDD. Когда оно пытается прочесть/записать что-то в RAM, то все и так ясно.

Я правильно понимаю?

[kotenok gav]

Dmitriy40 в сообщении #1471442 писал(а):

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

Сделано.

Dmitriy40 в сообщении #1471442 писал(а):

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

Насколько я понял, имелись в виду циклические сдвиги через перенос? Тогда тоже сделано.

Dmitriy40 в сообщении #1471442 писал(а):

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

Пока не стал делать, может быть, потом.

Еще сделал обычные циклические сдвиги. Итого 7 сдвигов (формально арифиметический и логический сдвиги влево различны, но фактически выполнится одна и та же цепь, так что формально возможных сдвигов там 8).

-- 01 июл 2020, 22:21 --

Вот, кстати, логическое описание сдвигов (копирую свою же строчку из пояснения там к схеме - "S2S1S0 is 000 - logic shift to the left. 001 - logic shift to the right. 010 - arithmetical shift to the left. 011 - arithmetical shift to the right. 100 - cyclic shift to the left. 101 - cyclic shift to the right. 110 - cyclic shift with the carry to the left. 111 - cyclic shift with the carry to the right."):
new a0 = [s0 && a1, [[a7, a1][s0], [cf, a1][s0]][s1]][s2]
new a_i = [a_{i-1}, a_{i+1}][s0]
new a7 = [[a6, s1 && a7][s0], [[a6, a0][s0], [a6, cf][s0]][s1]][s2]
new cf = [1, s1][s2] && [a7, a0][s0]
[x, y][z] - мое обозначение мультиплексора, оно значит (x && not z) || (y && z).

-- 01 июл 2020, 22:28 --

Кстати, а стоит ли сделать там изменение флага переноса (как и в основном ALU, которое меняет оба флага только после) только после начала очередного такта?

-- 01 июл 2020, 22:42 --

(И еще там есть специальный параметр контрольной логики, который устанавливает, менять ли флаги после операции сложения/вычитания)

[Dmitriy40]

kotenok gav в сообщении #1471517 писал(а):

Хотя... я не уверен, что я понял. Правильно ли я понимаю, что обычные компьютеры работают как-то так?:
1. BIOS (которая находится в процессоре/другой части материнской платы) заранее знает местонахождение загрузочного сектора на HDD.
2. BIOS копирует загрузочный сектор в RAM.
3. Загрузочный сектор запускается, и копирует что-то там (ну, запуск ОС, и прочее) с HDD в RAM.
4. Что-то там запускается.

На практике да, всё так и есть.
Только вторая часть 3 пункта и 4-й уже лишние, программа из загрузочного сектора может делать что ей угодно, например играть в тетрис (если код поместится в сектор). Так что обязательными являются лишь первые два пункта, с уточнением что "загрузочный сектор" не обязательно один, не обязательно на HDD (как минимум BIOS умеет его получать и с USB накопителей, и даже из локальной сети).
И все эти 4 пункта вообще никак не относятся к процессору и его проектированию. Всё что знает процессор — что при обращении за командами по адресу RESET он гарантированно получит код команды. Из ПЗУ. В котором может быть и BIOS (знающий о HDD/SDD, USB flash, SD card, LAN или ещё что-то), но может и быть просто произвольная программа (хоть игра Doom если влезет). Всё что будет происходить дальше, что за команду процессор получит первой после сброса, куда она его пошлёт, что там будет, ПЗУ или ОЗУ или ещё что — не его дело, это уже проблемы проектировщика системы, не процессора. Процессор умеет выдать адрес и получить по нему данные (или код команды), ну или записать по нему данные, и больше его ничего не волнует, остальное дело чипсета, материнской платы, программистов BIOSа и ОС. В настольных компьютерах принята последовательность как вы привели, но это вовсе не догма, и уж тем более она никак не увязана на процессор.
А, да, BIOS находится не в процессоре, это просто ПЗУ на материнской плате, которое выдаёт байты при обращении по адресу, по которому обращается процессор после сброса или включения питания. Процессор об нём ничего не знает, кроме единственного факта: при обращении за первой командой после включения питания он её получит. Из ПЗУ или с ручных тумблеров или с фотодиодов перфоленты или ещё как угодно (это всё оставляется чипсету и/или материнской плате), ему без разницы, главное просто её получить. А тот кто её туда положил уже отвечает головой чтобы и команда была правильной, и делала именно то что нужно (например это может быть начало процедуры чтения загрузочного сектора с HDD №0, размещённой в ПЗУ и называемой BIOS; или процедура инициализации видеокарты чтобы показать заставку игры Doom и запустить её).

Это всё если говорим об обычных универсальных процессорах. Потому что в микроконтроллерах например прямо в микросхему интегрированы и ПЗУ, и ОЗУ, и таймеры, и порты ввода-вывода, и аппаратные блоки разных протоколов (SPI, UART, I2C, CAN, LAN, контроллеры LCD и TFT, и прочее). Но и там вычислительное ядро ничего об этом всём богатстве обычно не знает, его дело читать команды из памяти, и выполняя их читать и писать данные из/в память. Всё. Попытка запихнуть в процессор всё-что-только-можно-и-плюс-всё-что-нельзя изначально тупиковая. Иерархический принцип организации доказал своё удобство и надёжность.

kotenok gav в сообщении #1471517 писал(а):

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

И это тоже к процессору никак не относится, это уже дело ОС, как она работает с HDD и памятью. Процессор всегда всё пишет только исключительно в память (ну или регистры ввода-вывода если они отделены от памяти), а дальше дело уже программиста куда это потом направить и надо ли вообще.
В процессоре нет понятия "записать в HDD", он просто не знает ничего про HDD (как и про USB и про WiFi и про LAN и т.д.), записать в HDD может захотеть программа, а тогда это уже её (и BIOS+ОС) проблемы, как и куда она это запишет.

kotenok gav в сообщении #1471546 писал(а):

Еще сделал обычные циклические сдвиги.

Хм, да, про них походу забыл.

kotenok gav в сообщении #1471546 писал(а):

Кстати, а стоит ли сделать там изменение флага переноса (как и в основном ALU, которое меняет оба флага только после) только после начала очередного такта?

Этого я не понимаю, в такие тонкости не вдавался. Обычно надо чтобы флаг результата одной команды был доступен следующей (три команды подряд сдвига трёх регистров через перенос правильно сдвинут все три регистра как будто один 24-х битный). Исключения бывают, но неудобны и требуют сильного обоснования.

kotenok gav в сообщении #1471546 писал(а):

(И еще там есть специальный параметр контрольной логики, который устанавливает, менять ли флаги после операции сложения/вычитания)

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

[kotenok gav]

Dmitriy40 в сообщении #1471555 писал(а):

Процессор умеет выдать адрес и получить по нему данные (или код команды), ну или записать по нему данные, и больше его ничего не волнует

Все, теперь понял окончательно.

Ладно, пойду делать умножение. Его сделать с помощью умножения двубитных чисел (это несложно) и двукратного алгоритма Карацубы?

[Sender]

Dmitriy40 в сообщении #1471503 писал(а):

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

Вот, кстати, да. При таких устремлениях было бы нелишне почитать более-менее систематическое изложение основ архитектуры ЭВМ. Вот, например:
http://arch32.cs.msu.su/

kotenok gav в сообщении #1471561 писал(а):

Ладно, пойду делать умножение. Его сделать с помощью умножения двубитных чисел (это несложно) и двукратного алгоритма Карацубы?

Тут тоже возможны варианты. Вот, можете ознакомиться с фундаментальным трудом Инго Вегенера. Там и умножение, и многое другое.
https://eccc.weizmann.ac.il/resources/pdf/cobf.pdf

[kotenok gav]

Sender в сообщении #1471564 писал(а):

Тут тоже возможны варианты.

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

-- 02 июл 2020, 01:29 --

Хм, у меня обнаружилась проблема( a+b и c+d в алгоритме Карацубы могут выйти не двубитными, а трехбитными числами, и тогда придется умножать трехбитные числа... Правда, в таком случае можно просто сменить знак ab или cd.

[kotenok gav]

kotenok gav в сообщении #1471575 писал(а):

Правда, в таком случае можно просто сменить знак ab или cd.

Хотя нет, так не получится... Или стоит реализовать так?: $0ab \times 0cd = ab \times cd$, $1ab \times 0cd = 0cd \times 1ab = ab \times cd + cd$, $1ab \times 1cd = ab \times cd + ab + cd$.

-- 05 июл 2020, 00:48 --

То есть, $xab \times ycd = ab \times cd + (y \wedge a)(y \wedge b) + (x \wedge c)(x \wedge d)$.

[Pphantom]

Тема перемещена из форума «Hardware» в форум «Карантин»
по следующим причинам:

- неправильно набраны формулы (краткие инструкции: «Краткий FAQ по тегу [math]» и видеоролик Как записывать формулы).

Исправьте все Ваши ошибки и сообщите об этом в теме Сообщение в карантине исправлено.
Настоятельно рекомендуется ознакомиться с темами Что такое карантин и что нужно делать, чтобы там оказаться и Правила научного форума.

[Pphantom]

Тема перемещена из форума «Карантин» в форум «Hardware»

[Dmitriy40]

kotenok gav
Какую именно операцию умножения реализуете (сколько битов на входе каждого множителя, сколько на выходе, в прямом коде или дополнительном или оба)?
На какой аппаратуре? Делать на дискретной логике глупо, есть же ПЗУ 256х8 и сумматоры, умножение 8х8=16 можно на десятке корпусов (4 ПЗУ и 5 сумматоров кажется достаточно) реализовать. Ну может ещё пара корпусов для умножения и в дополнительном коде.

[kotenok gav]

Dmitriy40 в сообщении #1472231 писал(а):

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

Пока делаю 4x4=8, с помощью его сделаю 8x8=16. В прямом.

Dmitriy40 в сообщении #1472231 писал(а):

Делать на дискретной логике глупо, есть же ПЗУ 256х8 и сумматоры, умножение 8х8=16 можно на десятке корпусов (4 ПЗУ и 5 сумматоров кажется достаточно) реализовать.

Сумматоры я использую. Использовать ПЗУ... из пушки по воробьям, мне кажется.

-- 05 июл 2020, 02:23 --

Схематика, кстати, немного упрощается, если учесть, что пятибитовый $ad+bc$ может быть лишь в случае $a=b=c=d=11$.

-- 05 июл 2020, 02:29 --

Так как тогда старшие два бита шестибитового $(a+b)(c+d)$ нужны только в этом случае, но... в этом случае они тоже не нужны.

[Dmitriy40]

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

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

И одно дело когда хочется разобраться как умножители устроены внутри, это удобно делать без привлечения хитрой математики и в базисе простейших функций (И, ИЛИ, НЕ, ИСКЛЮЧАЮЩЕЕ-ИЛИ, сумматор), если же задача практическая, то проще поставить что-то готовое или полуготовое (как ПЗУ 256х8 в качестве умножителя 4х4=8). Зачем здесь Карацуба вместо банального столбика мне видимо не понять.