> Сколько в таком случае "информационной емкости" профукано, когда мы пользуемся десятичной
> системой счисления и пишем цифры в клетки в тетрадке?

baseN с N > 10 расходовал бы площадь эффективнее. Но у обезьян 10 пальцев! Впрочем я HEX оперирую, мне норм.

> что должен сделать Паскаль в своей "Паскалине", чтобы перейти от неполной дестяичной

Ему двоичная система в ТОМ виде ни к чему. В тч по площади бумаги и письму. Это оптимизация под ДРУГИЕ нужды. HEX, вероятно появился поэтому.

> меньших секторов делений. В чем проблема? В схематехнике нынешней проблема может
> быть только в устойчивости 3-го состояния,

Промежуточное состояние триггера из 2 симметричных половинок это что?! Активна либо 1 половина либо 2-я. By design. И так много с чем еще.

> хотя и три-стейт реализации тоже имеются. Тип такого

Сделать можно что угодно. Вопрос в соотношениях. В целом удобнее всего в железе то. Впрочем это не отменяет существования странных вещиц. Например, простые RF протоколы порой кодируют биты как 001 -> 0 и 110 -> 1. Т.е. 3-в-1. Это для гарантии перепадов в каждом бите. Или бывает PAM3/PAM5. Но он есть только между трансиверами эзернета и проч. Остальные ЭТО не видят. Как раз для их удобства это изничтожается как можно раньше.

> технике? Он же самый простой схематически. :) Не то чтобы усложнять,
> они еще любители и переусложнять я бы сказал ;)

В очень сильно частных случаях - могут и (пере)усложнить во имя каких-то понятных goal'ов. Но вбить махровый якорь? В самое core? Везде, по всей площади? Во имя луны? Не дождетесь.

> Это должно быть доказано. Эт как в алгоритмах, к примеру,

Методом от противного:
1) покажте что-то проще инвертора с 2 комплементарными MOSFET?
2) то же самое для триггера из 2 половинок (транзисторов или лог элементов). Эта структура by design защелкивается либо в 1 половине либо в другой. Все что сверх этого - нехилые костыли.

> чеж мы унарную систему не используем ? Сложить ведь два унарных
> числа - обычная операция.

То было самой простой системой счисления которая позволяет то же что другие, но проста для реализации "в железе". Оттуда же и регистры фиксированой ширины, с максимально простым сплевом этого в шины и проч по возможности без парсинга.

> А кто сказал (доказал), что эффективно хранить допустим 3 бита в 8 битном регистре?

Эффективность штука многофакторная. Например есть характерный tradeoff в скорости VS "потребление памяти". Оперировать юнитами 1 размера быстрее, но порой больше памяти ест.

Это можно ощутить и в софте, поюзав bit fields в С (struct) например. Операции менее минимального юнита ведут к оверхеду от read-modify-write.

> Почему это не эффективно иметь для каждой длины собственный регистр?

Потребуется больше регистров и обвязки из шин/интерконектов, а также логика которая трекает длину операнда, что не халявно ни по площади ни по скорости. Самые простые cpu core RISC с фиксированой шириной команды, так декодер проще всего (заодно и быстрый).

> Эффективно в RISC-V иметь отдельный регистр для нуля ("железный нуль")?

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

> Ок, условились, как мне теперь реальзовать полную систему счисления?

Ваши трудности. Той задачи никто не ставил. Существующая система счисления работает не хуже любой иной, на ней держится вся планета с кучей абстракций, и в целом всем ОК оказалось.

> У меня 8 битов (ячеек, клеток, корзин) и два значения 0 и 1, одно
> из которых (0) заведомо лежит во всех битах.

В регистре НЕ ОБЯЗАНЫ быть нули после ресета. ROM вообще содержит что угодно. Всегда. Если это чем-то лучше. Но у ROM тоже только 0 и 1. Перемычка (диод в древних дискретных, ...) есть или нет. Так проше всего. Если логическая функция дурацкая, входов немного, сделать ROM table вместо лобовой реализации вариант. Или как и почему в CISC появился uCode ROM.

> В регистры А и Б положили некоторые числа в полной системе счисления, подали на
> вход сумматору (полному) и он записал в регистр В результат. И
> как мне понять какое число представлено в В?

К регистру стандартно проводов по числу разрядов и подключение к шине простейшая коммутация. Без парсинга. Так проще всего. Все IO по возможности шириной в шину/регистр и без парсинга.

У регистра, особенно 8 бит может не быть операции "частичной" записи. Вы всегда пишете 8 битов. В более широких возможны варианты. Но есть DSP которые принципиально видят мир - словами по 16. И только так! Адресовать байт не умеют принцпиально, даже "char" в си 16 битов. Компилер, конечно, сделает read-modify-write, претендуя что смог потрогать и отдельный байт, но это будет очень неэффективно в такой системе.

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

Логика обработки переменной длины, выборки битов и маскирования перевесит ту экономию с большим отрывом. И все тормознет. Особенно на битовом уровне. Если не жестить и ограничиться границами байтов, у CISC возможны команды переменной длины. Но сложный тормозной декодер как недостаток парадигмы возникает именно в этом месте, как и фееричные костыли. Оттуда же и потуги его оторвать (VLIW) или упростить структуру команд (RISC). Первое таки

> 111110001 - Вот так оно представленно в нынешней двоичной системе.
> *11110011 - А вот так оно представлено в полной двоичной системе.

Хранение "*" требует новое состояние памяти. И его рюхание. Везде. Усложнив ВСЕ схемы.

А теперь вот вам ROM. Координатная сетка и перемычки на пересечениях. Есть перемычка, 1. Нет - 0. А теперь запищите туда "*". Офигенно удобно, да? :)

> Что мы видим на первый взгляд? Разница в один бит, уже выигрыш
> какой-то, и та крайняя 1 (единица) (у этой записи 111110001) есть

На второй мы получим дофейхоа оверхеда для рюхания этой логики, который перевесит. Ну вот столь простая структура как ROM в этой парадигме как физически будет реализован допустим? Чтоб компактно и эффективно? Проверить наличие или отсутствие перемычки электрически не проблема. Но это 1 или 0. Без пространства "in between".

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

Мельник был собой хорош: потратил шиллинг, заработал грош.

> вы про карту "занятости" ячеек памяти во всяких аллокаторах?

Типа того. ASAN специфичный и особо дотошный вариант, но даже он смог скостить оверхед до 1/8 в этом месте.

> нынешних выч машинах бинарных.

Ну вот та система делана - под простоту реализации и скорость работы. Там не было задачи трекать "незанятые" ячейки. Игра ума это прекрасно, но там играли в сторону простоты и скорости реализации, в том числе и взяв систему счисления которая еще работает, но уже удобна для тех целей.

> (Чжэнь (Гром)) и все комбинации бинарной системы - значимы, нет понятия
> незначимых лидирующих нулей, что и есть полнота представления.

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

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

Скоростью ессно. Если кто не заметил, в начале были и 1-битные последовательные процы, а 4004 изначально 4-битный. Но в какой-то момент оказалось что повысть частоту в 8 раз для той же скорости - "душно". Тогда приходится расширяться в другие измерения. Например в число транзисторов. Сейчас та же история с ядрами. Частоты на 10ГГц обломались, пришлось оптимизировать ядра, пакуя больше ядер на кристалл.

> Что я теряю деля вольтаж между 0В и 1В на N частей?

1) Помехоустойчивость. Теперь и 1/N возмущения хватит чтобы сбить уровень. Главная причина хлипкости MLC/TLC/QLC флеша. "Distance between symbols" в сленге line coding.
2) Простоту коммутации, кодирования и декодирования.
3) Структуры CMOS нативно с этим не работают. Там открыт или нижний транзистор или верхний, и оно или 0 или Vcc. Равно как ROM, триггеры с активной 1 или 2 половиной и проч. Многие базовые вещи станут неприменимы.

> двоичную систему счисления" на два значения, то в качестве сумматора применим
> обычный сумматор "неполной двоичной системы" :) Вот вам и фокус, и
> ничего переизобретать не надо.

Остается вопрос "нафига все это было"? Вон те многочисленные аспекты это никак не отменяет же. Заодно сдвиг усложняет счет для людей.

> представления числа и сумматором, количество логических элементов которого равно сумматору
> "неполной двоичной системы" ;)

Теперь покажите мне ROM который вы к этому интерфейсить будете например и посмотрим что вы там сэкономить сможете :)

> А не оверхед всякие CE, SE, OE, буфера, линии задержек и т.д.?

"Электрически" биты не устаканиваются в нужное значение мгновенно - и поэтому совсем без этого нихрена не получится. Эти времянки - 1 из лимитирующих достижимую частоту факторов.

Но FYI быстрые последовательные шины появились в том числе и чтобы не заниматься выравнивнием времянок пачек битов. Что душно на более менее "длинном" проводе. Это однако совсем не халявный маневр и делать внутреннюю логику по таким принципам нафиг надо. Чисто внешние интерфейсы.