EC ЭВМ и ДВК. Решение о клонировании IBM и PDP - причины и последствия

Г.М.>> Преимущественно все же МиГ-15бис с ВК-1, разве не так?
Aaz> Вот за что я люблю форумы, так это за то, что можно залепить что угодно "от фонаря" - а оппонент должен отвечать аргументированно.
Aaz> Отвечу в том же стиле: если и так, то что это меняет?

В сущности - ничего, тем более после Вашего комментария о РД-45 и ВК-1 (Кстати: спасибо, интересно было почитать!).

Просто мелкое (я бы даже сказал "мелочное" ) уточнение.

3-62> Только я не очень себе представляю, как адрес памяти впихнуть в "одно машинное слово". А таких команд должно быть несколько.
3-62>

?

Память делится на "кванты" - байты, и "атомы" - слова, которые из 4-х байт.
Слова как раз достаточно для адресации 4 Гб.

Слово (на мой тупой взгляд) имеет (или должно иметь) тот же уровень "легитимности", что и байт.

П.З.> ?

В случае, когда команда адресует память, адрес памяти "ппиклеен" к коду операции. И эта конструкция - точно не поместиться в байт.

П.З.> Память делится на "кванты" - байты, и "атомы" - слова, которые из 4-х байт.

Атомы - это биты. Кстати. А слова - это, скорее, разрядность регистров или АЛУ.

П.З.> Слова как раз достаточно для адресации 4 Гб.

Зависит от разрядности шины адреса.

П.З.> Слово (на мой тупой взгляд) имеет (или должно иметь) тот же уровень "легитимности", что и байт.

Дело не в легитимности, а в недорогом удобстве. ИМХО.
Адресуешь каждый бит - плати увеличенной разрядностью адресов.
Адресуешь слова по 64 бита - ковыряйся с извлечением нужного тебе "куска" меньшей длины. Или теряй память попусту, если сразу в 64 бита запихиваешь 32 там или вовсе 8.

3-62> В случае, когда команда адресует память, адрес памяти "ппиклеен" к коду операции. И эта конструкция - точно не поместиться в байт.

В байт можно уместить команду, но это... э... изврат, тк.скть

3-62> Атомы - это биты.

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

3-62> А слова - это, скорее, разрядность регистров или АЛУ.

Да.
Это как раз к легитимизации.

П.З.>> Слова как раз достаточно для адресации 4 Гб.
3-62> Зависит от разрядности шины адреса.

Но слова достаточно

П.З.>> Слово (на мой тупой взгляд) имеет (или должно иметь) тот же уровень "легитимности", что и байт.
3-62> Дело не в легитимности, а в недорогом удобстве. ИМХО.

Дык отсюда и легитимация

3-62> Адресуешь каждый бит - плати увеличенной разрядностью адресов.
3-62> Адресуешь слова по 64 бита - ковыряйся с извлечением нужного тебе "куска" меньшей длины. Или теряй память попусту, если сразу в 64 бита запихиваешь 32 там или вовсе 8.

Учитывая преемственность и на основе послезнания "я бы" строил архитектуру на основе 4-х байтового слова (с байтной, естественно, адресацией) с выделением полутора-адресного ядра множества команд (один из адресов - регистр).
Код операции - байт, старший разряд КОП - определитель "многобайтного кода" для расширений (то есть, всего 128 базовых кодов).

"Старшие" команды - "составные" (многословные).

Это ядро неизменно во всех процессорах "ряда", старшие модели содержат всяческие его расширения.

"Как-то такЪ"

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

П.З.> В байт можно уместить команду, но это... э... изврат, тк.скть

Ну что вы сразу о таком-то думаете?
Стэковая машина. Бывает. Работает. НЯЗ.
х87 так устроен, кстати.

П.З.> Квант меньше атома, квант - элементарная частица, а атом это целая конструкция.

Ужос. Призрак гуманитария за вашей спиной вижу я!
Квант - это "порция". То есть антитеза "непрерывности".

П.З.> Но слова достаточно

Вот в 8086 - недостаточно. Там слово 16 бит. И адресует 64 к. Всего. Со сдвинутым на 4 бита "сегментом" - 1 Мб.

П.З.> Дык отсюда и легитимация

Легитимность тает как туман, когда дело доходит до практической схемотехники.

П.З.> Нууууууу, "рассмотрел бы такую возможность".

Сегодня - это лишнее. ИМХО. Сегодня хотелось бы "стандартного стандарта без махры"

3-62> Ну что вы сразу о таком-то думаете?

Вопрос
3-62> В случае, когда команда адресует память, адрес памяти "ппиклеен" к коду операции. И эта конструкция - точно не поместиться в байт.

Ответ:
поместиться, если память короткая (16 регистров)

П.З.>> Квант меньше атома, квант - элементарная частица, а атом это целая конструкция.
3-62> Ужос. Призрак гуманитария за вашей спиной вижу я!
3-62> Квант - это "порция". То есть антитеза "непрерывности".

Википедия:

Кванты некоторых полей имеют специальные названия:

фотон — квант электромагнитного поля;
глюон — квант векторного (глюонного) поля в квантовой хромодинамике (обеспечивает сильное взаимодействие);
гравитон — гипотетический квант гравитационного поля;
бозон Хиггса — квант поля Хиггса;
фонон — квант колебательного движения кристалла.
хронон — гипотетический квант времени

 

Хабр

Но это фотоны, которые, не имея массы, обязаны двигаться со скоростью света и E = p c. Что насчёт частиц с массой, вроде электронов? Электроны – это кванты электрического поля, и, как и фотоны, их можно испускать, поглощать, отражать или передавать как единое целое. У них есть определённые энергия и импульс, $ E² = (pc)² + (m_e c²)² $, где me — это масса электрона. Отличие электронов от фотонов в том, что они движутся медленнее света, поэтому могут и покоиться.
...
Так что, да, на самом деле кванты ведут себя очень похоже на частицы, и потому называть электроны, кварки, нейтрино, фотоны, глюоны, W-частицы и частицы Хиггса «частицами» не будет катастрофическим обманом. Но слово «квант» подходит для этого лучше – потому что это именно кванты.

 

Ещё неизвестно, кто здесь гуманитарий!

П.З.>> Дык отсюда и легитимация
3-62> Легитимность тает как туман, когда дело доходит до практической схемотехники.

С.ка, и ведь не только в России!

3-62> Сегодня - это лишнее.

Ну, я в основном на тему альтернативной истории.

3-62> Сегодня хотелось бы "стандартного стандарта без махры"

Ошибки признавать никогда не поздно.

П.З.> Учитывая преемственность и на основе послезнания "я бы" строил архитектуру на основе 4-х байтового слова (с байтной, естественно, адресацией) с выделением полутора-адресного ядра множества команд (один из адресов - регистр).
Ну так ARM (Начало проекта - 1983, первые чипы через пару лет)
Простой набор команд - два байта, полный - четыре.

Дем> Ну так ARM (Начало проекта - 1983, первые чипы через пару лет)
Дем> Простой набор команд - два байта, полный - четыре.

PIC-и. Середина 70. Вот там, НЯП, принцип "слово под размер команды" - реализован.
12 бит слово. 14 бит слово. Плата - система из 35 команд. И выкручивайтесь ими. Других-новых не будет.

Но тут тоже 8 бит не хватило.
А байт-то он есть такой, какой есть.

3-62> PIC-и. Середина 70.

Хотя бы.
А лучше бы начало.

muxel>> Все суперы 70-80-х работали на ЭСЛ и у нас для Эльбрусов и Ко передовая ЭСЛ тоже была стянута А то MOS, да MOS...
Pu239> Да, ЕС-1045 на 500 серии. И согласующие резисторные сборки 50 Ом в DIP корпусах, рядами. Потребление ого. Не знаю, были ли у нас с водяным охлажденим. На западе точно были.

ЕС-1046 была на водяном охлаждении.
"сегодня ЭВМ не работает так как нет воды" - у нас такая табличка в машзале была реальная

П.З.> Ещё неизвестно, кто здесь гуманитарий!

Немножко про гуманитарность.
Вы с хабра принесли: "Электроны – это кванты электрического поля"
Будете на хабре - спросите их "а может ли квант взаимодействовать с квантом?"

Ну и сами поразмышляйте над этой философской темой.

Б.г.> Скорее нельзя. Текст содержит большие и маленькие буквы, а в коде Бодо нет возможности переключить регистры.
Довесили бы дополнений. Не в первой же, его и так раздували понемногу.

Татарин>> Ну, сначала примем как факт, что практически везде сначала было 5, а потом 7 бит.
Б.г.> А потом внезапно 5 1/3 бита. RADIX-50. Вся эта экономия происходила из-за того, что биты были дороги - и в хранении, и в передаче.
Ну да.

Татарин>> 8 бит возникло уже позже для поддержки национальных алфавитов и породило кучу проблем,
Б.г.> А вот и нет - 8 бит возникло естественным способом.
Нет ничего "естественного" в выделении этого числа фирмой ИБМ. Это просто число. Да, степень двойки, да, умещается 2 4-битные BCD... Но и только. 8 битные кодировки, вмещающиеся в байт - позднее уродливое наследие.

Б.г.> Правильно, и это иллюстрирует, что не 8 бит введены были ради национальных алфавитов, а национальным алфавитам пришлось ужиматься в 8-битное прокрустово ложе.
Ты меня совершенно неверно понял: 8 бит, конечно, были введены не ради национальных алфавитов, а вообще "просто так". Тут утверждалось, что "байт - это для удобства обработки текстов", так вот это не так.

Двоично-десятичное представление было придумано ИБМ, но в реальности же практически и не пригодилось: с ростом сложности вычислений это почти мгновенно потеряло актуальность. Проще преобразовать бинарное представление в числа один раз, чем постоянно таскать с собой коррекцию (при этом, замечу, теряя биты и скорость исполнения). На практике оно почти и не использовалось, так что не может служить аргументом "за байт". Напротив, само наличие двоично-десятичной арифметики - недостаток.

Татарин>> При этом представь себе, что альтернативно, с той же лёгкостью, с которой ты выбираешь из памяти байт, ты можешь выбрать любое произвольное битовое поле. Это не требует каких-то ужасов ни в СК, ни в аппаратуре (наоборот, аппаратура как раз упрощается в сравнении с побайтовой адресацией). Скорость работы увеличивается, память экономится.
Б.г.> Скорость работы уменьшается.
Нет. Ещё раз - в сравнении с побайтовой адресацией.
Байт - это и есть совершенно произвольное битовое поле (не бит, и не слово) для любой не-8-бит машины.
Посмотри на побайтовую адресацию с этой точки зрения, и ты увидишь, что все твои претензии по скорости выборки и обработки применимы к машинам с побайтовой адресацией, только размер битового поля произвольно фиксирован волюнтаристким решением фирмы ИБМ.

Если у тебя есть, допустим, массив 4-битных целых, который у тебя изображает байтовый массив, то ты теряешь 4 бита из 8, половина помяти просрана. А bool сейчас всё равно почти-всегда либо слово (int), либо байт (что уродливо вдвойне - ты теряешь И память, И скорость).
Но ты не получаешь НИКАКОГО выигрыша по скорости при выборке байтов по сравнению с выборкой, допустим, 4 бит, все твои претензии по недозаполнению шины, по вычислению адресов, по неэффективному использованию АЛУ и вот всё это - они в ПОЛНОЙ мере применимы к любой 32-битной машине с побайтовой адресацией. Ну, разве что на современных архитектурах аппаратура частично скрывает от тебя проблемы с побайтовой выборкой и дополнительно создаёт проблемы с выборкой по 4 бита.
Но это не выгоды, а проблемы конкретной аппаратуры.

Более того, в конкретных рассматриваемых архитектурах (ИБМ, x86) к проблемам "чистой" "непословной" выборки добавляются ещё характерные проблемы архитектур - дополнительно ещё неэффективное использование АЛУ и регистров из-за перекрытия регистров разной размерности и невозможности использовать "хвост", дополнительный и бессмысленный расход кодового пространства команды (команды 8, 16, 32, 64 - это разные команды, и часто отличаются далеко не только префиксом) и т.п.

То есть, вот эти все описанные тобой проблемы - они существуют для байтовой адресации и обработки. ПЛЮС ещё много проблем сверху для конкретных архитектур от ИБМ и Интел.

Если ты пойдёшь ещё дальше, то ты увидишь, что для для любой RISC-подобной архитектуры с выраженным LOAD/STORE из регистрового файла в память, собссно, совершенно монопенисно как высчитывать сдвиг и как адресовать (если речь идёт о степенях двойки).
Побайтово, побитово, по 2, 4, 16 бит - пофигу, железо то же самое, то же количество аппаратуры. При совсем произвольном размере битовых полей (не степенях двойки) потребуется относительно дорогое целочисленное умножение (малоразрядное, впрочем). Но при этом во всех подобных случаях, реализованых на нынешних побайтовых архитектурах, ты будешь делать то же самое, только гораздо более дорогим умножением в коде. И операция доступа в память настолько дорога сама по себе (особенно сейчас), что (быстрое) умножение теряется на этом фоне.

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

...
Теперь о тратах шины, времени и прочего: это всё исчезает, если сразу принять для целочисленной арифметики, что регистр содержит вектор, от 1 до (число бит) скалярных значений, к которым все операции применяются отдельно (например, при перемножении А и Б, отдельно должны перемножаться А1 и Б1, А2 и Б2 и т.д.). С точки зрения аппаратуры или времени, это не несёт НИКАКИХ дополнительных трат (просто небольшая модификация логики работы того же сумматора или умножителя). Это (в отличие от привычных тебе нынешних векторных операций в х86) не требует дополнительных регистров, кодового пространства и т.п.

При этом шина и АЛУ при работе с битовыми полями используются на полную, эффективнее, чем в любых большинстве нынешних архитектурах (реальный пример обратного NM, где как раз вот так и сделано, ну и новые тензорные процессоры NVidia, где они честно потырили идеи NM).

...
Собссно, это и есть самый простой, красивый и эффективный способ апгрейда БЭСМ-6-совместимых.
А вовсе не введение идиотского промежуточного размера "недослова" в 8 бит и кучи дополнительных операций, чтобы всё это как-то обрабатывать, как сделала ИБМ (а потом, думаю, вынужденно, Интел сотоварищи).

Татарин> ...С точки зрения аппаратуры или времени, это не несёт НИКАКИХ дополнительных трат...
Положа руку на гениталий, скажем честно, таки несёт. Появляется дополнительный мультиплексор на входах данных АЛУ, что тормозит. Конечно, необходимо декодировать и дополнительное поле длины, что усложняет ПЛМ микрокоманд.
Что касается расширения БЭСМ-6, то тут я никак не пойму, почему оппоненты так не верят в эту возможность. Вона, 8080 расширили до иЦоре, Зионов всяких и не ощерились.

pokos> Вона, 8080 расширили до иЦоре, Зионов всяких и не ощерились.

Туда ли расширили? И не было ли варианта получше?

ИМХО - адресно-целочисленная арифметика должна быть отделена от "обычной" с дробями и плавающими точками.
Особенно сегодня.

3-62> Туда ли расширили? И не было ли варианта получше?
Нену, что для капитализма лучше, чем гигантские продажи? Значит, ьуда, куда надо расширили.

П.З.>> Квант меньше атома, квант - элементарная частица, а атом это целая конструкция.
3-62> Ужос. Призрак гуманитария за вашей спиной вижу я!
3-62> Квант - это "порция". То есть антитеза "непрерывности".
Собссно, любой частице (и фермионам типа электрона или протона тоже!) соотвествует некое (в нашей реальности всегда квантуемое) поле. При этом не обязательно фундаментальное.

Квантование и делает возможным статистический формализм (и понятие частицы) - см., например, операторы рождения и уничтожения частицы.

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

Татарин>> ...С точки зрения аппаратуры или времени, это не несёт НИКАКИХ дополнительных трат...
pokos> Положа руку на гениталий, скажем честно, таки несёт. Появляется дополнительный мультиплексор на входах данных АЛУ, что тормозит.
Ещё несколько гейтов в цепочке? Нет, это определённо не тормоз, особенно, если мы говорим об обращении к памяти. В АЛУ же - это не вопрос, всё равно в 1 цикл уложишься, а быстрее не нужно.

pokos> Конечно, необходимо декодировать и дополнительное поле длины, что усложняет ПЛМ микрокоманд.
Упрощает.
В лучших имеющихся имплементациях (RISC-подобных, в основном) оно уже и так есть: то есть, та же команда, тот же код, но 1 битик для 32 и 64 бит отличается.

В популярных имеющихся всё ещё хуже: см. разницу между
mov ah, 2
mov ax, 2
mov eax, 2
mov rax, 2

или
xor ax, dx; побитовое сложение для битов в ax,dx, только вот за этим ещё 3 полных набора вдобавок, что не несёт никакого смысла, побитовое сложение в любом случае одно и то же
add al, ah
add, ax, dx
add, eax, edx
add rax, rdx


В одной системе команд тут тебе и разный код, и разные префиксы. И это куда больше затрат даже в смысле чисто кодового пространства, чем 2 бита в поле команды.
А уж какая радость там у тебя в декодере!
И это вместо прямой конфигурации адресации и переносов в АЛУ несколькими битами в поле команды. Не нравится произвольно? Ну задай ряд из своего любимых степеней двойки, типа даже 1, 2, 4, 8, 16, 32, 64, 128. Всё равно будет МНОГО эффективнее имеющегося.

pokos> Что касается расширения БЭСМ-6, то тут я никак не пойму, почему оппоненты так не верят в эту возможность. Вона, 8080 расширили до иЦоре, Зионов всяких и не ощерились.
Именно что.
Где оригинальный 8080 и где х64? Но от поколения к поколению каждый раз был достаточно плавный переход с достаточной обратной совместимостью, чтобы обеспечить тотальную победу и доминирование.

Татарин> Собссно, любой частице (и фермионам типа электрона или протона тоже!) соотвествует некое (в нашей реальности всегда квантуемое) поле.

И?

Электрон - это "квант электрического поля"?

3-62> Адресуешь слова по 64 бита - ковыряйся с извлечением нужного тебе "куска" меньшей длины. Или теряй память попусту, если сразу в 64 бита запихиваешь 32 там или вовсе 8.
Так вот адресуя память по 8 бит в не-8-бит машине, ты за это платишь.

Ровно столько же, сколько платил бы за адресацию произвольного битового поля с длиной в степень двойки или почти столько же, сколько платил бы за адресацию произвольного битового поля.

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

См. выше ответ Генералиссимусу.

...
Из поля команд при этом исчезают побитовые операции (AND, OR и XOR), побитовые операции естественно получаются при представлении регистра как вектора из бит. А всякие сдвиги почти теряют смысл при непосредственно побитовой адресации (по базе).

Татарин>> Собссно, любой частице (и фермионам типа электрона или протона тоже!) соотвествует некое (в нашей реальности всегда квантуемое) поле.
3-62> И?
3-62> Электрон - это "квант электрического поля"?
Электрон - это квант соотвестветствующего "электронного" поля.

С фермионными полями формализм "частиц" обычно удобнее из-за антисимметричности волновой функции, но сути это не меняет.

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

Татарин> Так вот адресуя память по 8 бит в не-8-бит машине, ты за это платишь.

Так же как платишь адресуя не 8 бит в 8-битной машине.
Вопрос в обосновании удобства "не 8 бит".

Татарин> Ровно столько же, сколько платил бы за адресацию произвольного битового поля с длиной в степень двойки или почти столько же, сколько платил бы за адресацию произвольного битового поля.

Если степень двойки, то умножение/деление равно сдвигу. А если произвольное - то уже нет. Наверное. Что сложнее.

Татарин> Электрон - это квант соотвестветствующего "электронного" поля.

А что не позитронного, сразу?
Так "квант с квантом" взаимодействуют с появлением сил, перемещений, изменений энергии?

Татарин>> Так вот адресуя память по 8 бит в не-8-бит машине, ты за это платишь.
3-62> Так же как платишь адресуя не 8 бит в 8-битной машине.
3-62> Вопрос в обосновании удобства "не 8 бит".
Оно очень просто: "8 бит - частный случай".

Как пример неудобства и потерь-потерь-потерь в нынешних архитектурах (и ИБМ/360)- массив булов. Как я уже сказал, типично bool - либо int, либо вообще char/byte.
В обоих случаях ты теряешь память (используя по делу либо 3%, либо 12%).
В случае байта ты серьёзно теряешь в скорости выборки всегда, в случае int'a - на невыровненных данных (а выравнивание - это потери памяти снова и снова).
Если ты можешь адресоваться побитово (и имеешь соотвествующие команды битовых операций), бул натурально и без потерь представляется битом. А булевые операции (массивы, свойства) как бы не чаще, чем текстовые.

Как другой пример чисто практического неудобства: работа с UTF-16. Да, в силу тотальной кривизны 8086 и исторических причин у 8086 есть специальные команды для работы с 16 битами... которые будут исключительно тормознутыми и даже просто эмулироваться для х64. Для СК ИБМ/360 такого же и вовсе нет. Работа с 16-бит строкой в х64 или у ИБМ/360 ни разу не удобное и не простое дело. И что тебе за радость с байтовой адресации? И это ещё даже при том, что сам Unicode 16 бит (и 2 байта) был принят, чтобы быть максимально удобным для "байтовых" машин! Даже при этом всё криво!

Ну а все остальные 99% всей целочисленной арифметики составляют частные случаи. И вот тут 99% времени когда в int'e сохраняются реально 5, 7, 19, 37 и т.п. значения. Какая размерность целого числа "день недели"? Байт или int. А реально там - ВСЕГДА 3 бита.
Месяц? Байт или int. А реально там - ВСЕГДА 4 бита.
Число копеек? Байт или int. А реально там - ВСЕГДА 7 бита.
Номер года? Порядковый номер химического элемента? Номер вагона поезда? Расстояние от города до города в километрах (уж никак не больше 40000км, правда? ).
И т.п. и т.д. - таких примеров в практике миллион, их и есть абсолютное большинство, а число случаев, когда тебе реально нужно именно 8, 32 или 64 бит - очень счётно, единицы процентов, их можно даже не принимать в расчёт.

Это же самоочевидно.

При даже этом имеющаяся (! - по историческим причинам) в х86 арифметическая тряхомудия, позволяющая работать с 8 и 16 битами не используется и использоваться не может по причине исключительной тормознутости. В чистой теории, ты можешь написать add ah, al, на практике же это чисто ради совместимости, и если ты хоть сколь-нить ценишь производительность, ты не будешь так делать. А кодовое пространство эти команды занимают, и штраф на общую тормознутость системы побайтовой адресации в 64-бит машины ты платишь всегда.

Татарин>> Ровно столько же, сколько платил бы за адресацию произвольного битового поля с длиной в степень двойки или почти столько же, сколько платил бы за адресацию произвольного битового поля.
3-62> Если степень двойки, то умножение/деление равно сдвигу. А если произвольное - то уже нет. Наверное. Что сложнее.
Ну да. Поэтому сдвиг (и степень двойки) условно-бесплатен, а за индексирование произвольной размерности пришлось бы платить (но опять же, такую адресацию можно было сделать и прозрачной для программиста, просто с пометкой, что она затратна; точно так же, как сейчас адресация невыровненных по слову данных).

Татарин>> Электрон - это квант соотвестветствующего "электронного" поля.
3-62> А что не позитронного, сразу?
Это одно и то же. См. уравнение Дирака для фермионного поля: у него есть отрицательные решения, соотвествующие античастицам.
Ну, позитрону, в конкретном случае электронного поля.

3-62> Так "квант с квантом" взаимодействуют с появлением сил, перемещений, изменений энергии?
Поле с полем.
Ну, квант с квантом, да.

Татарин> Оно очень просто: "8 бит - частный случай".

Это обоснование? Удобства "не 8 бит"?!

Татарин> типично bool - либо int, либо вообще char/byte.

Есть такая команда TEST. Так она - вполне удобно решает проблему. И в байте у вас 8 битовых флагов.

Татарин> Какая размерность целого числа "день недели"? Байт или int. А реально там - ВСЕГДА 3 бита.

Теперь есть "TimeStumps", которые вообще - сплошной непрерывный счетчик по 200 наносекунд (Чубайс?!) с непонятно-лохматого года.