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

с.т.> особенно те что с клаудом работают или там живут.

А. Вот где корень зла.

Ну так: "В России катастрофа с Xiaomi. Умные устройства больше не работают, серверы недоступны, сломалась вся экосистема"

Осторожнее надо.

Татарин> Адреса должны адресовать слова, слова, которые определены аппаратурой. Не надо "скрывать" это от программиста, это лишь порождает бессмысленную кривизну
Ну вот самая новая память DDR5 - восемь чипов, каждый на один бит.
https://img.computerunivers.net/images/400x400/9090963391D68F6378F74113B301BAFE.jpg [zero size or time out]

Дем> Ну вот самая новая память DDR5 - восемь чипов, каждый на один бит.

А с обратной стороны платы?

3-62> А с обратной стороны платы?
Пусто. Но вот вообще с четырьмя чипами

Татарин>> Нет, всё же, операнд произвольной величины и команда произвольной величины - это ну очень-очень о разном.
П.З.> Но всё одинаково квантуется байтом.
Нет.
Битом. А если перешли (а мы перешли) к пословной обработке, то словом.

П.З.> А адрес может иметь переменную длину еще и потому, что обращается к операндам разной длины.
Именно так и сделано в приличных архитектурах. И даже в х86 при сложном индексировании (разве что в х86 отсчёт идёт от байт) есть встроенные сдвиги индексных регистров при адресации.

П.З.> Скажем, "сложение двойных слов" имеет адрес, если в байтном формате, то с нулевыми тремя последними битами. Которые можно, как бэ, опустить, подразумевая по умолчанию.
Вот совершенно верный и уместный вопрос.
Откуда вопрос: а при чём тут адресация (аппаратная) как таковая? Если по-настоящему-то нам нужно только сдвигать индексы? И следующий же естественно вытекающий вопрос: если мы можем сдвигать на 3, на 3+1 или на 3+2, то почему не можем сдвигать на произвольное число из более широкого выбора? Имея при этом общие траты кодового и адресного пространств МЕНЬШЕ, чем в привычном х86, но с куда бОльшими возможностями по итогу?

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

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

Кодам команд арифметики при этом не нужно содержать типа и размера, как в большинстве архитектур. Например add al, 01h и add ax, 0001h - разные команды. Но, собссно, зачем? Если ты знаешь, что в R1 у тебя 8-битные данные, то операция сложения с R1 будет сложением вектора. И так далее - для всей арифметики же.

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

Татарин>> А для нормальной работы с текстом,..
Aaz> Просветите дилетанта: какие "мозги" использовались в пишущих машинках "с памятью"? Там, как я понимаю, какой-никакой, но текстовый редактор уже был.
Aaz> У нас они появились (пусть и в мизерных количествах) всё же чуть раньше, чем "персоналки" (ну, это если я не путаю).
Ой, вот чего там только не было.
Но в основном, НЯЗ, какие-то 8-битные общеупотребимые микропроцессоры и контроллеры - 8051, 8080, Z80, 6502 и им подобное. Тут даже не нужно видеть их все или даже много их: "время было такое". Очень уж большого выбора тогда ещё не было, а что-то серьёзнее вообще стОило диких денег (так что при явной достаточности 8051 и избыточности 16-бит не оставляет вариантов).

П.З.> Это плохо, если диктует аппаратура.
П.З.> Это значит, что этого коня вы так и не укротили.
Тут как обычно - "дай мне, боже, сил бороться с тем, что можно побороть, дай смирения смириться с тем, что не могу, дай ума, чтобы отличить одно от другого".
Вот вся проблема информационных технологий как раз в третьем пункте.

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

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

с.т.> особенно те что с клаудом работают или там живут.
Особенно те, да.

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

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

И теперь, при необходимости вычислении точного (UTC) времени какого-то события у тебя в программе, которая переводит местное время в UTC отныне и навсегда должно быть прописано - "если это было в Эстонии, то" - выясняем дату - "в период с 1996-го по текущее время переводить время как в ЕС, НО в период с 2007-го по 2018-й (точные года не помню, сори), время не переводить". И, ессно, свои поправки с 1900-мохнатого по 1918, потом отдельно с 1918 по 1939, потом с 1939 по 1941, потом с 1941 по 1944, потом отдельно с 1944 по 1947, потом отдельно с 1947 по 1963... ну, мужик, ну ты понял, да?

Медведев, Дмитрий Анатольевич, сцуко этакое, увековечил себя простым передвижением и изменениями поясов. Ты прикинь теперь, на какой территории теперь тебе нужно вычислять место происхождения абстрактного документа, чтобы понять, когда ж это было (а, например, для ментовки - это не последнее дело, и может сыграть и через годы).

Татарин>> Адреса должны адресовать слова, слова, которые определены аппаратурой. Не надо "скрывать" это от программиста, это лишь порождает бессмысленную кривизну
Дем> Ну вот самая новая память DDR5 - восемь чипов, каждый на один бит.
Ну, во-первых, там не "каждый на 1 бит" Во-вторых, и? Как это связано со сказаным мною?

Но конкретно у DDR5 разрядность - 64 бита (может использоваться 2 отдельно адресуемые 32-битных канала).
Вообще, нынче цифровая природа удивительно обманчива: банальный провод для зарядки содержит микропроцессор, и даже "УСБ-зарядка" - вовсе не про 5 вольт, а что-то там от "5 до дофига" с переменным числом ампер, о которых зарядка телефон и кабель договариваются по особому протоколу.
Эта микросхема с DDR5-планки и простая как табуретка 565РУ5 с ногами адреса, сигналом CS и выходом - ну очень разные по сложности (а не только по ёмкости) микросхемы.

Татарин>>>> Каких багов-то?
П.З.> 3-62>> Так символ-то - байт. И по сей день. И байт в х64 болтается как в проруби. И это создает неудобства.
Татарин>> Во-первых, символ - не байт
П.З.> 1. А что же? Или ASCII уже отменили или даже запретили?
Так ASCII - 7 бит.

П.З.> 2. А как вообще должны представляться символы по-вашему?
Сейчас - Unicode.

Татарин>> Спецвычислители для симуляции МД.
П.З.> МД-yandex:
Молекулярная динамика. Это охрененно широкий класс разных задач, просто название одно.

3-62> В NTFS, специально для них, придумывали аттрибуты. Неразрывно цепляемые к файлу. Поставь туда "версию запроса/отклика" - и наслаждайся строгой, ничем не нарушаемой упорядочностью. А дату - которая для людей нужнее - не мацай!
Это не будет работать.

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

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

Даже лень примеры приводить, несть им числа.

Таймштамп или хотя бы UTC - это как "мойте руки перед едой". Не факт, что прям вот сейчас это будет критично. Но привычка хорошая, и избавляет от кучи проблем.

Татарин>>> Адреса должны адресовать слова, слова, которые определены аппаратурой. Не надо "скрывать" это от программиста, это лишь порождает бессмысленную кривизну
Татарин> Ну, во-первых, там не "каждый на 1 бит" Во-вторых, и? Как это связано со сказаным мною?
1) "Новые 16-гигабитные чипы организованы как 1Gx16 или 2Gx8" (ц). Так что какие поставили, да.
Где четыре чипа - там второе.
Татарин> Но конкретно у DDR5 разрядность - 64 бита (может использоваться 2 отдельно адресуемые 32-битных канала).
Угу - и планка раскидывает данные по шине. Плюс там и в "длину" последовательность нехилая.
Ну и раз чип сам адрес инкрементит - то ему не похрен, с круглого начинать или нет?

И кстати, в связи с двухканальностью DDR5 - уже появились планки на 24, 48 и 96 Гб

Татарин> Это не будет работать.

Не вижу физических препятствий к тому, чтобы работало.

Татарин> Что там "для людей важнее" люди часто не понимают.

А вот и он, большой зуб. "мы лучше вас знаем что вам нужно".
Кончается все неинтеллигентно.

Дем> И кстати, в связи с двухканальностью DDR5 - уже появились планки на 24, 48 и 96 Гб

А, вот, ели бы в ПО убрали половину "do nothing loop"-ов, то эффект был бы заметнее чем от плюс еще 64ГБ РАМа.

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

Так и нули не надо читать.
Читать (параллельно) надо столько байт, сколько заказано.

Татарин> Татарин>> Во-первых, символ - не байт
П.З.>> 1. А что же? Или ASCII уже отменили или даже запретили?
Татарин> Так ASCII - 7 бит.

Мы робяты простые, от сохи



П.З.>> 2. А как вообще должны представляться символы по-вашему?
Татарин> Сейчас - Unicode.

Для тех, кому надо.
Некоторые и по древне-египетски балакают.
Но не все.

Unicode ASCII не отменяет.
А слово не отменяет байт.

П.З.> Unicode ASCII не отменяет.

Причем наблюдается трогательная совместимость применяемого юникода с англиской раскладкой аски. А те версии юникода где этой совместимости нет - "мало распространены".
И как так вышло?

П.З.> А слово не отменяет байт.

Все еще хуже. Вожусь тут снова с потрохами ntfs. И в тему разговора об экономии и удобствах слова над байтом - вот в этой ntfsс одной стороны место не экономят. И поля там по 8 бвйт. И много их разных избыточных и дублированных. Понятно. Победа прогресса в виде шалых ресурсов.
Но почему тогда "потоки данных" кодируются как у Плюшкина - аж до нибблов доходя? Байт экономят?
И как так вышло?

Татарин>> Татарин>> Во-первых, символ - не байт
П.З.> П.З.>> 1. А что же? Или ASCII уже отменили или даже запретили?
Татарин>> Так ASCII - 7 бит.
П.З.> Мы робяты простые, от сохи
Поэтому не знаете, что ASCII - это только нижняя часть таблицы, до 127?
1251 - это не ASCII.

Татарин>> Сейчас - Unicode.
П.З.> Для тех, кому надо.
По-хорошему, надо всем. Просто не все это понимают.
КМК, нынешнее поколение пользователей уже избаловано Уникодом до такой степени, что не понимает уже, зачем Уникод нужен. А вот ещё лет 20 назад всё было совсем иначе.

П.З.> Unicode ASCII не отменяет.
Еснно.

П.З.> А слово не отменяет байт.
При чём тут "отмена"? Байт просто не нужен.

Татарин>> Нет. Потому что шина (и все гейты контроллера) заняты одинаково, шине почти всё равно, передавать ли данные или нули.
П.З.> Так и нули не надо читать.
П.З.> Читать (параллельно) надо столько байт, сколько заказано.
А передавать-то их как, если ширина шины 64 бита?
Будет переданы данные кратные размеру слова полностью (ну, или что то же самое, будет полностью занят пакет передачи с этой или бОльшей размерностью).
Тут вариантов нет.
Если тебе это непонятно, представь подставь в своё предложение "бит" - так его странность тебе будет виднее. Хотя на самом деле, оно странно одинаково, что то, что это.

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

Тогда - да, можно было бы передавать и байт, и 3 бита, и 79. Беда только в том, что смысла в этом нет. Даже в таких железячных нутрёшках как шина памяти протокол уже достаточно сложен. Ну и нести все потери транзакции с памятью ради передачи одного единственного байта смысла нет (ты учти, что даже передача адреса займёт больше времени и места). Это помимо отсутствия всей системы для работы с байтом далее... ты не сохранишь его в кэш, не запишешь в регистр, не проведёшь с ним операцию.

Татарин>> Это не будет работать.
3-62> Не вижу физических препятствий к тому, чтобы работало.
Так просто же - при таком раскладе нет главного: нет возможностей обмена между системами с сохранением упорядоченности событий.

Татарин>> Что там "для людей важнее" люди часто не понимают.
3-62> А вот и он, большой зуб. "мы лучше вас знаем что вам нужно".
3-62> Кончается все неинтеллигентно.
Ну, блин, а вообще, что делать, если лучше знаем?

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

Татарин> Байт просто не нужен

... а буквенный алфавит надо заменить иероглификой.
Понятно с вами всё.

Татарин> А передавать-то их как, если ширина шины 64 бита?

Задействуя половину/четверть/одну восьмую шины

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

Становится переменным по длине не тоже самое, что теряет смысл.
Наоборот.

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

Я про смысл и говорил.
Экономия электричества.

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

Татарин>> Байт просто не нужен
П.З.> ... а буквенный алфавит надо заменить иероглификой.
П.З.> Понятно с вами всё.
По-моему, после 9 повторений типа "это не про замену", всё ещё непонятно.
Думаю, моя позиция хотя бы в этом пункте начнёт только проясняться где-то к 30-35-му повторению этой фразы.

Я не раз говорил: байт - случайный технически-исторический выверт, исторический курьёз, как частота электросети на швейцарских ЖД 18,333Гц. Какого-то особого технического смысла в этом стандарте стандарте нет, но раз уж он случился и с ним привыкли работать, то он жив. И отменять его не собираются.

С другой стороны, он никому особо-то и не нужен. Скажи кому в постСССР, что наши ЖД ужасно страдают из-за отсутствия переменного напряжения 18.3Гц на ЖД - не поймут. Потому что у нас этого технического анекдота никогда не было, и сразу (ну, не сразу, но быстро) приняли более удобный стандарт - повсеместно применяемую промышленную частоту 50Гц, удобную для единой системы генерации и распределения. И брать это за "недостаток" советских электровозов - чистый идиотизм.

С байтом - то же самое, только та разница, что вот байт у нас как раз был.
Но могло бы и не быть.
Жили бы примерно так же, только чуть лучше.