tarasv> Принимается. И как я понимаю претензии к размеру символьного типа сняты?
Их никогда и не было - раз 15 уже тут повторено. Были претензии только к тому, что это
единственно возможный размер. Которого сначала было много, а потом (в момент интернационализации) почти мгновенно стало мало.
Татарин>> И сразу ошибка - в чём?
tarasv> В том что я не телепат. Теперь я вот знаю что ты только про load/store.
Нет, многократно повторялось и уточнялось одно и то же.
tarasv> Что значит нормальная в твоем понимании? Возможность грузить N бит одной командой а не двумя/тремя и только словные инструкции для любого размера данных в регистре, как в RISC-V или ARM например? И только из за этого весь этот поток эмоций?
Двумя-тремя ты не обойдёшься, скорее, речь о десятке+ (напиши псевдокод по индексации и присваиванию 5-битного целого в память и из - ну, поймёшь, о чём я)... И да. Именно из-за этой "мелочи" весь "поток эмоций". Потому что эта "мелочь" в корне огромной ветки технических решений, определяющих облик нынешней техники. Не лучшим образом сформированной ветки. Та самая палеоценская бабочка из-за которой будущее выглядит радикально иначе, только цепочка причин и следствий куда более проста. "Влияние ширины жопы лошади на форм-фактор космических ракет"©, что-то типа.
tarasv> Векторная это SIMD выполняемый параллельно. Cray-1 до кожной хаты? rep это самый обычный SIMD с одним исполнителем.
Векторная - это SIMD с не-фиксированным размером вектора. Да, именно так, rep - это вариант SIMD, только с произвольным размером тех "MD".
tarasv> Могут ли данные меньшего размера пересекать границу слова? Я предполагаю что не могут. Так? Для знаковых целых нужно преобразование на лету. Не проблема. Есть это все для вещественных?
Могут.
Нет. Вещественные могут и должны оставаться фиксированного размера, как раз потому что они вещественные, переполнение для них возможно только в каких-то исключительно редких случаях научных расчётов. Вопрос лишь в точности расчётов, которую планировать динамически куда сложнее (и это экзотика, неважная на практике).
Татарин>> Если ты аккуратно повспоминаешь применение байтовой (допустим) арифметики на х86, то ты с удивлением обнаружишь, что собссно, байтовость арифметики не используется почти нигде, а в большинстве случаев переполнение с переносом - по сути ошибка, особая ситуация. Исключения же - крайне редки, и по сути являются хаком.
tarasv> До Unicode беззнаковая байтовая арифметика без всяких хаков использовалась любой программой обработки текстов на русском, французском, испанском и тд языках.
Ещё раз перечитай то, на что ты отвечаешь.
Да, использовалась (и используется, и будет). Но что в ней от специфично
байтовой арифметики, а что просто от целой? В каких местах та же арифметика после загрузки символа не может вестись в размерности слова?
Я утверждаю, что таких мест в реальном коде нет или ничтожно, пренебрежимо мало. Можешь привести примеры обратного?
tarasv> О чем это? О процессорах c кешами на кристалле? Никто не лезет за отдельными байтами в ОЗУ сейчас.
Я именно про это самое. Никто не лезет за байтом.
Любая реальная работа идёт со словом.
Поэтому нет никакой существенной практически разницы между выборкой байта или произвольного размера целого, разница только немножно в арифметике вычисления и выдачи адресов плюс сдвига на нужное число бит. Всё.
tarasv> Эпитеты указывают на то что ты или систему команд S/360 не видел или пишешь для тех кто ее не видел. Не надо это писать мне. Не смотря на правоверный CISC, наличие RR и RM клонов всех команд операций над данными, полный комплект команд работы со строками и двоично-десятичными числами в памяти ИБМ так и не смогла придумать что туда еще напихать. Opcode не только поместился в одном байте, но еще и 100 кодов остались свободными. И в 370 помещалось с запасом. Второй байт добавили в 390.
Нет, я пишу о системе с байтовой выборкой в принципе... но замечу, что наличие "лишнего" кодового пространства характеризует систему с самой худшей стороны. Тем более, CISC.
tarasv> Ну и конкретика. Ты предлагаешь использовать 7 полных регистров чтобы сравнить две строки в первом примере вместо трех регистров во втором примере? Два назначения, два адреса, два смещения в слове и один размера. Я не ошибся в подсчетах?
Уф, ошибка, конечно, но я согласен принять часть вины за неё, раз уж сам написал [addr] (хотя imm там же не было, вроде, правда? я даже не подумал, что ты решишь, что сравнение символов строк можно делать выборкой по константным адресам). Если уж, действительно, брать сравнение символов из двух строк, то на х86 будет что-то типа
mov al, es:[si]
или
mov al, [cx]; инициализацию ds оставим за скобками, да?
или
mov eax, [rbx + rsi*imm]
Последнее, кстати,
реально существующая и
массово используемая удобная инструкция х86-64, и чем она от мной предлагаемого
mov R, [R1 + R2*R3(бит)]
? Тем, что
трёхбитный imm в реальной исторически сложившейся интел-амдешной архитектуре включен в опкод?
Серьёзно?
Так что 4 против 7. Или даже 5 против 6, в зависимости от компилятора, является ли это константными строками, как компилятор их расположил (потому как база может быть той же), его внутренние соглашения вызова и адресации, вот это всё.
Или даже 7 против 7, если брать реально существующую доминирующую архитектуру и некоторые (практически значимые и популярные) случаи и слегка натянуть.
То есть, разница - да, есть, и вроде как не в пользу "переменного размера". Но она на практике минимальна: ну, на тот самый размер, плюс-минус, остальное - просто сложная адресация, которая применяется вовсю и без того.
Будешь настаивать на бОльшей разнице? Можно. Но заметь: она обусловлена лишь бОльшим количеством инструкций load/store в альтернативах, то есть, сравнение изначально нечестное и даже бредовое.
Считаешь это критичным?
Давай добавим ещё пару инструкций выборки, если так нужно.
tarasv> Ты же даже считать эти проценты не пробовал. Просто с потолка взял.
Нет, почему же?
Я просто назвал проценты для всех команд, которым требуется размер. Совершенно очевидно же.
Докапываться до того, что существуют и другие?
Ну... это как-то уж совсем до запятых дотрахаться.
tarasv> А у тебя байт из середины слова оказывается в младших битах регистра с помощью сильного колдунства и совершенно бесплатно? Или таки тем же самым железом туда захизивается которое ты только что так страстно отругал?
Именно железом, "которое я отругал". Но, во-первых, его не больше для поддержки любого размера, а, внезапно,
МЕНЬШЕ. Во-вторых, это затрагивает только и исключительно спецкоманды спецадресации полей, и никак не затрагивает остальные команды (в отличие от байт, где под байты "пилится" вся система).
tarasv> Ты уверен что сдвиг на 63 разных значения аппаратно выйдет проще чем сдвиг на четыре разных значени.
Абсолютно уверен. Если это сдвиговый регистр делает, то ему, знаешь ли, всё равно, сдвигать только на 1, 2, 4, 8 или ещё и на 2, 3, 5, 6, 7, 9..63. Тут экономия на размерности счётчика сдвига, но это уже даже не экономия на спичках, а экономия на побелке, которая коптится выбросом их сажи.
Но зато эта процедура только в одном месте - на конкретных операциях load/store, а не затрагивает ВСЕ операции с памятью. Разницу видишь?
Татарин>> Посмотри на альтернативу. Оставляем везде только слова. Оставляем загрузку произвольного поля по адресу, индексу и размеру. Добавляем к этому векторизацию, не префиксом, а командой повторения rep R (делать следующую команду пока (--R)!=0). Вся работа с байтами остаётся такой же или лучше, чем у ИБМ, но в дополнение получаешь...
tarasv> Ничего не получаю если речь про байты.
ЕСЛИ РЕЧЬ ПРО БАЙТЫ.
Если речь исключительно про них (а это не так, много раз говорилось что борьба - за возможность нормальной работы с размером "по месту"), ты получаешь, как минимум, учетверение-увосьмерение адресуемой пословно, а не побайтно памяти. За что, знаешь ли, дважды шла целая война на переходах "за 64кб" и "за 4Гб", именно вот "за пару лишних бит", и которые вообще никогда лишними не бывают - см. например, наличие и дальность "ближних" переходов в разных архитектурах. Получаешь естественно, со всеми выгодами.
И без потерь.
Ты получаешь экономию кодового пространства. Минимум один бит (а то и два). Но и один бит - это удвоение кодового пространства для соотвествующих команд, им можно очень хорошо распорядиться.
Ты получаешь экономию времени на выборке
команд (как минимум, на CISC, из-за естественного выравнивания команд на слово при пословной адресации).
Ты экономишь сколько-то аппаратуры в самых критичных точках - при работе с памятью.
Но "в дополнение" (а на самом деле как раз то, за что боремся) ты получаешь
возможность работы с правильными размерами. И огромную экономию памяти именно для бизнес-систем. Ещё помнишь, что она была не всегда такая дешёвая, как сейчас, да даже и сейчас небесплатна?
И экономию шины памяти. Что определяет реальную производительность сейчас.
И кучу бонусов по мелочи.
А главное - получаешь способность нормально и "плавно"(!), бесшовно переходить между размерами, динамически, прямо в коде, как результат иного развития ЯВУ и подхода к распределению и использованию памяти.