Признаки устаревшего языка

Существует большое количество «старых» и «относительно старых» языков программирования, которые не то, чтобы в ходу, а вообще находятся в «мейнстриме» годами и десятилетиями. И не собираются спускаться с верхних строк рейтингов. Но что является признаком устаревания? К примеру, самолёт устарел, если он

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

А что с языками программирования? Понятно, что они не подвержены износу и не знают, что такое «усталость металла». Но ясно, что они тоже могут иметь проблемы, особенно если они разработаны давно, а жизнь, которая никогда не останавливается, накопила опыт решения проблем. А поскольку язык был сделан давно, а опыт появился только недавно, то естественно, что он не учтён этим языком.

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

Однако появляются новые языки. Но они, зачастую, ничем не лучше старых. Они ещё не «сошли с конвейера», а уже устарели. Или сошли, и в штампе об изготовлении стоит совсем свежая дата, но... Этот свежий автомобиль имеет устаревшие подвеску и тормоза, у него нет подушек безопасности, движок у него карбюраторный, а салоне — магнитола с кассетами и диапазоном «СВ» и «ДВ».

Так и язык — он только что вышел из-под пера (простите, клавиатуры) программиста, для него даже тесты ещё не написаны — а он уже устарел. Эх, не получилось никого удивить, вся публика выпячивает губы: «Мы это уже видели».

Конечно, цели создания языков могут быть разные, например Вы — завсегдатай выставок ретроавтомобилейкомпиляторов и «олдскульных» языков. Эти новые языки, которые лишь хорошо забытые старые, представлены в большом ассортименте в этих списках (разработки наших организаций и частников). Перед этими новыми языками вроде бы ставилась задача пододвинуть старые, но что делать, если они такие же, как и старые, но при этом ещё и «мясом» не обросли? Вот и курят они в сторонке, ожидая, что их компания будет пополнена другими образцами «нового слова в программировании». Такая картина наблюдается не только в родных палестинах, но и в Кремневой долине тоже. Ни Go, ни Swift точно не пошли дорогой революции.

Рискую повторить классификацию Борхеса, но попробую описать формальные критерии отнесения того или иного языка к устаревшим. И так, каковы они, эти признаки или приметы? Это когда в языке есть:

• неопределённое поведение (Undefined Behaviour), допускаемое стандартом языка;
• оператор «goto»;
• такая обработка исключений, которая ещё хуже «goto», когда исключение неизвестно где возникает и неизвестно куда передаёт управление;
• постфиксные операции «++» и «--», которые для большинства — загадочны;
• висячий «else»;
• приведения типов, влекущие «тайное» изменения значения;
• нулевой указатель и обращения по абсолютным адресам;
• упор на мутабельные состояния;
• возможность присвоить неинициализированное значение;
• неаккуратные пересечения типов, допускающих неправомерное использование;
• операции сдвига, которые работают не так, как ожидается, если счётчик превышает разрядность операнда;
• разные операции проверки равенства («isEqual()» и «==», например), которые надо описывать по отдельности, хотя они эквивалентны;
• избыточное употребление скобок из-за плохо продуманных приоритетов операций;
• визуальный мусор типа «then», «begin» и «end», особенно ЗАГЛАВНЫМИ буквами;
• пустой оператор, от которого пользы нет, а вред вполне вероятен, например в выражении if (условие); {...};
• никому не нужный унарный плюс;
• синтаксис, прогибающий под себя программистов, а-ля Forth;
• развитый макроязык, который говорит о неразвитости собственно языка.

• приоритетов операций а-ля Lisp или Forth;
• контроля границ массивов а-ля Си;
• контроля возможного переполнения при арифметических операциях;
• системы обработки ошибок, носящий обязывающий, а не факультативный характер;
• возможности вернуть из функций объекты как скалярные, так и не скалярные, как фиксированного, так и переменного размера;
• функций — объектов первого класса;
• оператора «for each»;
• программирования в стиле доказательств;
• вывода типов;
• зрительных ориентиров в тексте, позволяющих отличить операции от операндов;
• синтаксически обособленных чистых функций.

Если программирование будет идти вперёд, то в том числе через новые языки с новыми подходами и парадигмами. Для того, чтобы оставаться в рамках старых парадигм и привычных подходов, новые языки не нужны. Для этого есть «старый добрый» Си или «тёплый ламповый» Паскаль. Новые Си и Паскаль с иной, пусть и эргономичной, с отшлифованной формой записи проиграют конкуренцию своим первоисточникам.

Иногда языки могут «выстрелить» благодаря какой-то фишке, которой нет ни у кого. Например, у языка 1С — это русские идентификаторы. Или у PHP — ориентированность на Web. Но не раз повторённое новшество теряет притягательность. Однако найти такую фишку при неизменном фундаменте программирования сложно.

Эволюционный путь развития языков «в возрасте» приведёт в итоге в тупик. В языке С++, к примеру, с каждое нововведение увеличивает число правил, усложняет язык. Чем сложнее язык, тем сложнее компилятор. Тем меньшим коллективам разработчиков он под силу. Тем меньше конкурирующих компиляторов мы будем иметь. При отсутствии конкуренции начнает страдать качество компиляторов.

Опубликовано: 2019.09.05, последняя правка: 2024.04.21    13:22

✅  2019/09/10 10:17, kt          #0 

✅  2019/09/10 16:42, MihalNik          #1 

В первой прочитанной мною брошюре по Паскалю введение начиналась словами: наконец-то, после «пудовых» описаний PL/1 и ассемблера ЕС ЭВМ, мы получили язык с описанием на нескольких страницах. Года через два наши соседи купили дистрибутив Турбо-Паскаля

✅  2019/09/10 16:48, kt          #2 

✅  2019/09/10 18:36, MihalNik          #3 

Так речь не о скобочках, а о возрастании сложности при использовании языка на производстве.

✅  2019/09/10 21:10, kt          #4 

✅  2019/09/10 22:25, MihalNik          #5 

А тем, кто начинает осваивать с нуля сложнее — они сразу сталкиваются со всем многообразием возможностей.

✅  2019/09/12 11:36, Автор сайта          #6 

"Чистый" Паскаль, Лисп и другие годятся только для школьной информатики.

Глупо бороться с goto в старых языках. Этот оператор порою предлагает наиболее экономичные решения — в силу правил языка, которые у старых языков уже отлиты в бронзе. Бороться с памятниками — плохая идея. Но в новых языках можно построить правила так, что goto и близко будет не нужен. Однако в них порою предлагаются устаревшие подходы. Вот тогда смотришь на такой язык и приходит в голову классическое: «Молодая была немолода».

✅  2019/09/15 14:25, Александр Коновалов aka Маздайщик          #7 

✅  2019/09/15 19:32, kt          #8 

Например, "use strict" в современном JavaScript

✅  2019/09/15 21:18, Александр Коновалов aka Маздайщик          #9 

✅  2019/09/16 12:26, Автор сайта          #10 

Неявные объявления переменных можно рассматривать как признак устаревшего языка (хотя в некоторых скриптовых языках они могут быть уместны).

a = 2      // первое присваивание: присвоено и значение, и тип

✅  2019/09/16 13:06, kt          #11 

a = 2 // первое присваивание: присвоено и значение, и тип

a=2

a=2e0

✅  2019/09/16 18:13, MihalNik          #12 

Однако компиляторы должны должны поддерживать все подходы — и старые, и новые. А это ляжет тяжким грузом на компиляторы.

✅  2019/09/16 18:38, MihalNik          #13 

Но сейчас экономить на паре строк?

✅  2019/09/16 21:03, kt          #14 

✅  2019/09/16 21:06, Автор сайта          #15 

Предпочитаю явно указать, что а — это вещественное с мантиссой 53 разряда

a = long double (2);

int fun(int x, int y) {
a = x;
. . . }

a = f (x);

a = long double (2);

Но сейчас экономить на паре строк?

и получить не обнаруживаемую сразу ошибку

Можно выставлять ограничения на время поддержку старых кодов

✅  2019/09/16 23:25, MihalNik          #16 

Как раз между прописанными типами все зависимости очевидны и не меняются.

что-то я не понял этой мысли.

✅  2019/09/17 11:11, kt          #17 

Ну так у «2» есть тип по умолчанию. Если он не устраивает, можно у записать что-то типа
a = long double (2);
Везде есть информация о типе. Когда же хочется указать её в явном виде это так и делается (так называемая «синтаксическая соль»).
Дело не столько в экономии, сколько в том, что инициализация типа и значения происходит одновременно. После этого не приходится бороться с неинициализированными переменными. Уходит целый класс ошибок, а это дорогого стоит.

✅  2019/09/18 11:40, Автор сайта          #18 

я привык к своему болоту

С моей точки зрения «2» не имеет вообще никакого типа, это заполнение значением. И, кстати, а как по константе помимо типа определить ещё и разрядность (в битах или байтах)?

какую взять разрядность для «а» в выражении «а=0»?

разрядность — универсальная характеристика для выделения памяти.

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

Еще два разряда указывали — это данные или команды. При запуске программы память для данных расписывалась этими разрядами и при попытке обратиться к неинициализированной переменной происходило аппаратное исключение (попытка выполнения команд как данных).

✅  2019/09/18 15:18, kt          #19 

инициализация типа и значения происходит одновременно.

if x>0 then a=1; else a=1e-4;

Это «беззнаковое целое длиною 1 бит».

…
ON ENDFILE BEGIN; X=0; GOTO ДАЛЬШЕ; END;
…
GET LIST(Y);
IF Y>0 THEN X=FLOOR(Y); ELSE X=CEIL(Y);
ДАЛЬШЕ:
…

неинициализированные данные имеют такие же дополнительные (49, 50) биты, что и инициализированные данные.

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

БЭСМ и «Эльбрусы» увидели бы ошибку только в рантайме, а вывод типов работает уже во время компиляции!

✅  2019/09/19 11:24, Автор сайта          #20 

А если стоят ветвления?

Чем мучится с пониманием, сколько здесь разрядов нужно под X, не проще ли самому их указать, пусть и с запасом?

ui1  value;     // величина, под которую необходимо 1 бит

Давно было, может тоже память подводит.

А здесь анализ при компиляции может ошибку и не увидеть.

✅  2019/09/19 12:51, Александр Коновалов aka Маздайщик          #21 

Вообще-то последним словом в этой теме считается вывод типов, внешне напоминающий неявное объявление:

auto pi = 3.142;   /* C++ */
var pi = 3.142;    /* C#, Go */
pi := 3.142        /* Go, синтаксический сахар для var pi = 3.142 */

print(x) # ошибка
x = 1
print(x) # выведет 1

VeryCoolLibrary.Widgets.Window w = globalContext.getMainWindow();
w.setVisible(true);
w.redraw();

var w = globalContext.getMainWindow();
w.setVisible(true);
w.redraw();

✅  2019/10/26 09:48, utkin          #22 

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

Например, какую взять разрядность для «а» в выражении «а=0»? Ей-богу, проще самому явно указать и тип, и разрядность напрямую для каждой переменной. Лично мне так и проще, и понятней (я хозяин своих переменных!) Явная разрядность отсутствует во многих современных языках? Ну и зря. Ведь уже нет архитектур с не 8-разрядными байтами. Значит разрядность — универсальная характеристика для выделения памяти.

Мне видится, что тип «2» должен быть определён как «беззнаковое целое длиною 2 бита».

Это «беззнаковое целое длиною 1 бит».

Я имел ввиду то, с чем борятся implicit none в Фортране и Option Explicit в Бейсике. В этих языках если где-то используется необъявленная переменная (в любом месте программы), то вместо выдачи синтаксической ошибки компилятор её неявно объявляет. Молча. И, возможно, даже не инициализируя.

Тип для w можно вывести во время компиляции и тем самым сократить код:

✅  2019/10/26 10:00, utkin          #23 

Иногда языки могут «выстрелить» благодаря какой-то фишке, которой нет ни у кого. Например, у языка 1С — это русские идентификаторы.

✅  2019/10/26 10:10, utkin          #24 

Эволюционный путь развития языков «в возрасте» приведёт в итоге в тупик. В языке С++, к примеру, с каждое нововведение увеличивает число правил, усложняет язык. Чем сложнее язык, тем сложнее компилятор. Тем меньшим коллективам он под силу. Тем меньше конкурирующих компиляторов мы будем иметь. При отсутствии конкуренции начнает страдать качество компиляторов.

✅  2019/10/26 14:47, kt          #25 

Разве в алгоритме расчета затрат муки на приготовления пирожка с капустой нужно знать разрядность? О чем это Вы :) ? Ради машины Вы готовы применять кучу знаний, которые совершенно не требуются для решения задачи. Игры разума.

✅  2019/10/28 08:17, utkin          #26 

Я имел ввиду, что лучше явно указать разрядность, чем писать все эти совершенно непонятные "double" и "long", размер которых неочевиден. В PL/1 разрядность указывалась с самого начала и это делало язык как раз независимым от архитектуры машины.

✅  2019/10/28 10:08, kt          #27 

✅  2019/10/28 11:27, MihalNik          #28 

В PL/1 это делается не очень удобно в битах, а не в байтах.

✅  2019/10/28 17:49, utkin          #29 

Вдруг где-то будут не 8-разрядные байты :)

Я писал не о необходимости самому рассчитывать число разрядов, а о форме явного указания длины объектов в памяти.

А для избегания штрафных тактов при обращении к объектам в х86, требуется их выравнивание кратное длине объекта (так и делает PL/1-KT). Т.е. 2-х байтные объекты выравниваются в памяти на 2, 4-х байтные объекты — на 4, 8-ми байтные на 8. Таким образом, в х86 для bool выделится все-таки один невыровненный байт, при том, что Intel физически при обращении всегда читает не менее 4 байт.

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

✅  2019/10/28 23:43, Автор сайта          #30 

Мне видится, что тип «2» должен быть определён как «беззнаковое целое длиною 2 бита».

Сразу же падение производительности. Все процессоры неэффективно работают с битами.

Во всех Бейсиках, которые мне известны, переменные всегда инициализировались.

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

kt: лучше явно указать разрядность

мне нужно знать сколько вешать муки в граммах.

Строго говоря, нет никакого стандарта, в котором байт равен 8 битам. И в истории были системы, в которых байт содержал иное количество бит. Просто это общепринятое явление в данный конкретный момент развития ИТ. И не факт, что позже с развитием оптических или квантовых технологий эта величина не изменится.

✅  2019/10/29 07:42, MihalNik          #31 

Но есть разница между правильным значением и значением по-умолчанию. Инициализация значением по умолчанию хороша только одним: выключается «датчик случайных чисел» при чтении неинициализированной переменной. А вывод типов исключает само чтение неинициализированного.

✅  2019/10/29 10:02, utkin          #32 

Вы путаете объявленную разрядность объекта и реально выделяемое количество памяти.

Да, но у организмов эволюция отсекает лишние и устаревшие функции, а у языков программирования — нет. Вот и тащится воз обратной совместимости.

Если эти граммы известны компилятору как константа, то он вычисляет необходимое и достаточное количество битов. Если это читается в рантайме из БД, то это делает программа.

А уж компилятор сам рассчитает, сколько битов достаточно для квантового компьютера, сколько для фотонного.

✅  2019/10/29 10:17, utkin          #33 

✅  2019/10/29 10:32, kt          #34 

Это очень старые данные. Даже старые Дельфи (еще до Эмбекадеро) уже во всю равнялись на 16 байтовые страницы.

Очевидно, что со времени расцвета PL/1 мир значительно продвинулся вперед.

В 64-х битных системах (а они медленно, но верно наступают на все вокруг) выравнивание даже на 4 байта очень не эффективно.

Bool или Int как раз этим самым и занимаются. Нет необходимости плодить лишнюю сущность — скальпель Оккама и все такое.

✅  2019/10/29 12:03, Автор сайта          #35 

MihalNik: Принципиального отличия нет, любое изменение переменной в условии даст подобное состояние, т.е. локально значение до условия будет каким-то "по умолчанию".

int i;		// в Бейсике здесь присвоят 0; в Си — «случайное» число
if (i = 1)	// здесь не проверка на равенство «==», 
		// а присвоение и проверка i на неравенство 0

локально значение до условия будет каким-то "по умолчанию"

utkin: компилятор будет использовать практически всегда избыточное количество битов. Потому что биты нельзя насыпать в стакан. Они выдаются пачками — байтами и словами. Поэтому надо вам 7, Вы получите 8 минимум… Bool или Int как раз этим самым и занимаются.

int i = 0;	// длина кратна 16

Надо Вам пароль в Блокноте записать — сколько там байт? 10-16 наберется? А на жестком диске данный файл займет 4 Кб. Работа с памятью примерно такая же, только масштабы не столь эпичны.

Как раз явное указание разрядов позволяет устранить лишние сущности.

✅  2019/10/30 09:41, utkin          #36 

Не понял, о каких страницах речь.

А вот зачем данные выравнивать на 16, а не кратно их длине, непонятно.

С чего Вы это взяли и где на это ссылаются?

При переходе PL/1 с 32 на 64 просто FIXED(31) увеличились до FIXED(63). Безо всяких добавлений «long long»

Занимаются похожими вещами, но не теми же. Сколько нужно бит для хранения константы 0? Ровно 1 бит. Но Вы объявляете:

целое(32 бита) а = 45658421
целое(1 бит) б = 0

.... // Какие-то другие команды

а = а + б

Но тут Вам встречается какой-нибудь 14-разрядный квантовый вычислитель. Если бы у Вас константа была известна компилятору как однобитная, то она спокойно бы разместилась в 14 битах. Но Вы-то её объявили 16-разрядной и она не поместится в 14 разрядов! Тогда 14 разрядов будут запрошены дважды, чтобы поместить якобы 16-разрядную (а на деле одноразрядную) константу. Т.е. знание размера объекта с точностью до бита лучше знания размера, кратного 8.

Дело не в экономии, а в точности знания. Наше дело — дать точное знание компилятору, а уж сколько он выделит — зависит от платформы.

✅  2019/10/30 11:05, kt          #37 

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

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

Это архитектурный вопрос. Прочитать 8 байт за 1 раз эффективней, чем читать 8 раз по одному байту. Даже если конкретно вот сейчас Вам нужен только один байт.

На это есть простая причина — совместимость.

✅  2019/10/30 12:24, MihalNik          #38 

Т.е. знание размера объекта с точностью до бита лучше знания размера, кратного 8.

✅  2019/10/30 12:41, MihalNik          #39 

И что Вы имели в виду под «подобным состоянием»?

✅  2019/10/30 14:15, utkin          #40 

Извините, но я уже потерял «нить понимания».

А вот аппаратный кэш организован построчно с размером строки 16 (или 32) байта.

Компилятор не выделяет память «страницами»,

но зачем, когда его длина всего лишь 4 или 8 байт?

Никакого выигрыша скорости это не даст, все равно читается строка кэш.

И при этом, например, 32-разрядный Intel имеет лишь 30 адресных линий (А0 и А1 — внутренние) и физически всегда читает по 4 байта, а потом из них внутри себя выбирает нужное.

Нет же смысла его считать вручную, наверное, Utkin это подразумевал.

✅  2019/10/30 16:29, kt          #41 

✅  2019/10/30 18:30, utkin          #42 

Тогда причем здесь компилятор и какие-то «16 байтовые страницы»? Компилятор не выделяет памяти динамическим объектам и понятия не имеет, на что там выравнивается, а просто генерирует обращения к таким объектам через указатели.

✅  2019/10/30 18:38, utkin          #43 

И, поверьте, наличие или отсутствие в программе массивов структур не является признаком её современности или признаком студенческой работы.

✅  2019/10/30 19:38, Александр Коновалов aka Маздайщик          #44 

✅  2019/10/31 08:58, kt          #45 

kt, а можно ли в Вашем компиляторе указать float(39) или float(13)? Что тогда получится? А fixed(13)?

 dcl i fixed(13) static init(8191);

   3 c      dcl i fixed(13) static init(8192);
ПЕРЕВОД                                   ?
КОМПИЛЯЦИЯ ПРЕКРАЩЕНА

✅  2019/10/31 09:18, utkin          #46 

Никаких «16-байтовых страниц» не существует — это выдуманный utkin’ом термин. Менеджеры памяти (тот же malloc() для Си), как правило, выделяют адреса, кратные 16 байтам.

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

✅  2019/10/31 11:31, Автор сайта          #47 

✅  2019/10/31 12:47, utkin          #48 

Вы так смело оперируете терминами («кэш нижнего уровня», «выравнивание», «конвейер») и какими-то цифрами («16-байтовые страницы», «кратна 8-16 байтам»), но при этом пишите интерпретатор(!) языка и совсем не на ассемблере(!).

В Вашем интерпретаторе делается подсчёт байтов с целью этого самого выравнивания?

Так ли часто в Вашем интерпретаторе работают команды MMX и SSE, как Вы их вспоминаете всуе?

Пытаясь в чём-то переубедить Дмитрия Юрьевича, не пытаетесь ли Вы «научить учёного», у которого, в отличие от Вас, есть за плечами написанный транслятор с двух языков: PL/1 и ассемблера?

Вы, utkin, пишите программу на своём языке, а Дмитрий Юрьевич — на PL/1. Оценка — по двум старым критериям: скорость и объём занятой памяти.

«лучшее знание архитектуры процессоров и памяти»

✅  2019/10/31 13:11, Александр Коновалов aka Маздайщик          #49 

Никаких «16-байтовых страниц» не существует — это выдуманный utkin’ом термин. Менеджеры памяти (тот же malloc() для Си), как правило, выделяют адреса, кратные 16 байтам.

Это тоже самое и есть :). Минимальная единица в менеджере памяти страница.^{[Источник?]} И она, кстати, не обязана быть равна 16 байтам, просто наиболее часто используется данная величина. И выделяются не адреса, а блоки памяти. Блок всегда имеет целое число страниц. Вот это самое я и писал между прочим. Согласен был не точен в формулировках. Но речь шла об этом. И о том, что в свете такого механизма работы с памятью прямое указание битов не даст Вам никакой эффективности в сравнении с традиционными типами данных.

✅  2019/10/31 13:37, Александр Коновалов aka Маздайщик          #50 

И? Это означает, что я не должен касаться этой темы и изучать её?

Ничего хорошего не получится. Из-за жесткой привязки к FPU все переведется в FLOAT(53) и FLOAT(24).

✅  2019/10/31 13:41, Александр Коновалов aka Маздайщик          #51 

Ещё есть в книге Дракона.))

✅  2019/10/31 13:52, Автор сайта          #52 

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

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

сравнивать компилятор и интерпретатор — это сильно

✅  2019/10/31 14:28, kt          #53 

А FLOAT(63) (10-байтовое расширенное) поддерживается?

✅  2019/10/31 16:53, Александр Коновалов aka Маздайщик          #54 

Знаете, когда-то я читал такое: «Хватит выравнивать на границу слова или двойного слова, это было важно для быстродействия во времена первых Пентиумов, но не сейчас. В современных x86 влияние выравнивания на производительность сильно уменьшена». Но я не пытаюсь кого-то убедить, что это так

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

test double+alloc_ali, checksum 2999.0, ma 00A7F020, mb 01BC6020,
                                      mc 02D1D020, time 14.777000
test double+alloc_una, checksum 2999.0, ma 03E65021, mb 04FA7021,
                                      mc 060F3021, time 15.919000
test float+alloc_ali, checksum 2999.0, ma 0723F020, mb 07AEE020,
                                      mc 0839D020, time 14.243000
test float+alloc_una, checksum 2999.0, ma 08C45021, mb 094EC021,
                                      mc 09D9D021, time 14.761000
test int+alloc_ali, checksum 2999.0, ma 0A64F020, mb 0AEFE020,
                                       mc 0B7AD020, time 9.498000
test int+alloc_una, checksum 2999.0, ma 0C050021, mb 0C8F5021,
                                      mc 0D1A8021, time 10.147000
test short+alloc_ali, checksum 2999.0, ma 0DA51020, mb 0DEA1020,
                                       mc 0E303020, time 8.841000
test short+alloc_una, checksum 2999.0, ma 0E763021, mb 0EBC9021,
                                       mc 0F029021, time 9.221000
test char+alloc_ali, checksum -73.0, ma 0F487020, mb 0F6BC020,
                                       mc 0F8F5020, time 8.588000
test char+alloc_una, checksum -73.0, ma 0FB2D021, mb 0FD61021,
                                       mc 0FF96021, time 8.542000

test double+alloc_ali, checksum 2999.0, ma 0000000000AD0040, mb 0000000001C1D040,
                                        mc 0000000002D69040, time 13.336000
test double+alloc_una, checksum 2999.0, ma 0000000003EBD041, mb 0000000005006041,
                                        mc 0000000006155041, time 14.499000
test float+alloc_ali, checksum 2999.0, ma 000000000729F040, mb 0000000007B44040,
                                        mc 00000000083FA040, time 12.770000
test float+alloc_una, checksum 2999.0, ma 0000000008CAC041, mb 000000000955A041,
                                        mc 0000000009E04041, time 13.470000
test int+alloc_ali, checksum 2999.0, ma 000000000A6B2040, mb 000000000AF51040,
                                        mc 000000000B7F0040, time 9.597000
test int+alloc_una, checksum 2999.0, ma 000000000C095041, mb 000000000C93E041,
                                        mc 000000000D1EE041, time 10.047000
test short+alloc_ali, checksum 2999.0, ma 000000000DA9A040, mb 000000000DEF2040,
                                        mc 000000000E356040, time 8.765000
test short+alloc_una, checksum 2999.0, ma 000000000E7BD041, mb 000000000EC1F041,
                                        mc 000000000F070041, time 9.044000
test char+alloc_ali, checksum -73.0, ma 00000000006F7040, mb 000000000F4CC040,
                                        mc 000000000F70B040, time 8.472000
test char+alloc_una, checksum -73.0, ma 000000000F946041, mb 000000000FB77041,
                                        mc 000000000FDA4041, time 8.426000

test double+alloc_ali, checksum 2999.0, ma 02560004, mb 036A0004,
                                        mc 047E0004, time 19.562000
test double+alloc_una, checksum 2999.0, ma 05920005, mb 06A60005,
                                        mc 07BA0005, time 19.219000
test float+alloc_ali, checksum 2999.0, ma 08CE0004, mb 09580004,
                                        mc 09E20004, time 15.266000
test float+alloc_una, checksum 2999.0, ma 0A6C0005, mb 0AF60005,
                                        mc 0B800005, time 15.562000
test int+alloc_ali, checksum 2999.0, ma 0C0A0004, mb 0C940004,
                                        mc 0D1E0004, time 14.719000
test int+alloc_una, checksum 2999.0, ma 0DA80005, mb 0E320005,
                                        mc 0EBC0005, time 15.406000
test short+alloc_ali, checksum 2999.0, ma 0F460004, mb 0F8B0004,
                                        mc 0FD00004, time 12.156000
test short+alloc_una, checksum 2999.0, ma 10150005, mb 105A0005,
                                        mc 109F0005, time 12.516000
test char+alloc_ali, checksum -73.0, ma 006C0004, mb 10E40004,
                                        mc 11070004, time 11.328000
test char+alloc_una, checksum -73.0, ma 112A0005, mb 114D0005,
                                        mc 11700005, time 11.422000

• Вещественная арифметика медленнее целочисленной. Где-то раза в полтора.
• Разница между 32-разрядным и 64-разрядным кодом (для GCC) небольшая, 64 чуть-чуть быстрее.
• Разница в производительности double→float и int→short→char, по-видимому, вызвана меньшим размером данных: эффективнее используется кэш, меньше обращений к памяти и т.д.
• Не выровненный доступ медленнее выровненного, но не сильно.
• Современный GCC выравнивает указатели по 16 байтам точно, старенький BCC — по 4 байтам.

✅  2019/10/31 17:04, kt          #55 

Но вернемся к нашим баранам, т.е. к тесту. Я попытался вручную повторить некоторые приемы оптимизации. Замена деления умножением, к моему удивлению, совершенно ничего не изменила. Похоже, процессор сам оптимизирует случаи вроде деления на степень двойки. А вот выравнивание данных на 16 привело не к ускорению, а к замедлению работы. Выравнивание данных здесь вообще выглядит не очень. Я рассчитываю, что будет использовано 5000х5000х4=100 000 000 байт, а транслятор IBM реально использовал 400 миллионов. Для 32-х разрядной системы это значительная разница. Ожидаемо самый большой вклад времени дает запись в массив (чуть ли не половина времени), что ещё более снижает вклад остальных оптимизаций.

✅  2019/11/01 17:18, Автор сайта          #56 

Не выровненный доступ медленнее выровненного, но не сильно.

✅  2019/11/01 19:38, kt          #57 

✅  2019/11/05 14:11, Александр Коновалов aka Маздайщик          #58 

Теперь у меня есть авторитетный источник :)

✅  2019/11/07 10:58, kt          #59 

✅  2021/01/16 00:00, alextretyak          #60 

оператор «goto»;

такая обработка исключений, которая ещё хуже «goto», когда исключение неизвестно где возникает и неизвестно куда передаёт управление;

постфиксные операции «++» и «--», которые для большинства — загадочны;

приведения типов, влекущие «тайное» изменения значения;

нулевой указатель

возможность присвоить неинициализированное значение

int x = void;

визуальный мусор типа «begin» и «end», особенно ЗАГЛАВНЫМИ буквами;

контроля возможного переполнения при арифметических операциях;

приоритетов операций а-ля Lisp или Forth;
контроля границ массивов а-ля Си;
возможности вернуть из функций объекты как скалярные, так и не скалярные, как фиксированного, так и переменного размера;
функций — объектов первого класса;
оператора «for each»;
вывода типов;

обращения по абсолютным адресам
синтаксис, прогибающий под себя программистов, а-ля Forth;
программирования в стиле доказательств;
зрительных ориентиров в тексте, позволяющих отличить операции от операндов;

✅  2021/01/16 13:37, Автор сайта          #61 

Очень больная/большая тема… По вопросу исключений ... я пока остановился на «устаревшей» модели, принятой в Python и C++…

то против префиксных «++» и «--» он ничего не имеет?

о каком приведении типов идёт речь

char a = выбрать 8 младших битов (9876543210);	// явное обрезание лишних битов
char b =  9876543210;		// неявная потеря битов. Если потеря и вправду
				// случается, возбуждаем исключение

#include <stdlib.h>
main () {
   double  x = 0.1;
   if (x*6 == 0.6)
      printf("Здесь всё прозрачно.\n");
   else
      printf("Что-то пошло не так, тут поработали тёмные силы.\n");
   return;
}

Автор против nullable-типов?

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

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

Не совсем понял, о чём это

обращения по абсолютным адресам

int* ptr = (int*) 1234;	// запросто получаем абсолютный адрес
*ptr = anything;		// и пишем по нему

синтаксис, прогибающий под себя программистов, а-ля Forth

A+B-C

A + B — C

зрительных ориентиров в тексте, позволяющих отличить операции от операндов

  blabla_1 blabla_2 blabla_3 

✅  2021/01/19 00:00, alextretyak          #62 

Я протестую не против синтаксиса — префиксного или постфиксного, а против семантики постфиксных «++» и «--».

Например, присвоение переменной типа int значения типа long, float или double часто делается с искажением значения. В таких случаях надо либо явно «убивать» лишние биты значения, либо должно быть реагирование на ошибку

Да. Адрес, указывающий незаконный участок памяти, сам незаконен.

Но если обнаружилась такая незаконная ситуация, то должна быть немедленная реакция на ошибку, это описано в статье «Обработка ошибок».

Биты переполнения и так устанавливаются, хотим мы этого или нет.

А вот условный переход по условию «переполнение» замедляет код не в разы, а лишь на проценты — даже не на десятки процентов. Дмитрий Караваев на этом сайте озвучивал цифры на сей счёт.

Без проверки на переполнение:
...
add     %esi, %edi
...
С проверкой на переполнение:
...
add     %esi, %edi
jo      <handle_overflow>
...

for (int j = 0; j < n; ++j) {
  sum += a[j];
}

✅  2021/01/20 00:10, Автор сайта          #63 

Но чтобы использовать значение, которое вернул `find()`, необходимо либо явно проверить его на N/null\Н/нуль, либо использовать оператор `?` (например так: `dict.find(key) ? default_value`). Как вы предлагаете изменить это? Какая сигнатура и тип возвращаемого значения должны быть у метода `find()`?

Не могли бы вы указать, где именно это описано в статье «Обработка ошибок».

Да, но проверка этих битов далеко не бесплатна. На современных суперскалярных процессорах условные переходы стоят дорого и, вероятно, со временем будут становиться ещё дороже.

говорится о двукратном падении производительности:... a 2x slowdown, which isn't acceptable if Rust wants to compete with C++.

Можно исходный код тестирующей программы, с помощью которой получены эти данные?

замедления в 2 раза… 28%… в 6 раз медленнее…

✅  2021/01/23 00:35, Автор сайта          #64 

но что конкретно вы предлагаете?
1. чтобы `i++` работало точно также как и `++i`;
2. запретить `i++`, оставив только `++i`;
3. разрешить `++i`, `i++` и `arr[++i]`, но запретить `arr[i++]`, что мне больше всего нравится.

✅  2023/03/27 10:49, ChatGPT отвечает          #65 

По каким признака можно понять, что определённый язык программирования устарел, что подходы, принятые в нём, не соответствуют современным подходам в программировании?

• Отсутствие поддержки новых технологий и фреймворков: если язык не может использовать новые технологии и фреймворки, то это может означать, что он устарел и не соответствует современным требованиям в программировании.
• Низкая производительность: современные языки программирования обычно предназначены для работы с большими объемами данных и многопоточностью, и если язык не может обеспечить высокую производительность при работе с большим объемом данных, то это может указывать на его устарелость.
• Сложность программирования: современные языки программирования обычно облегчают и упрощают процесс программирования, делая его более продуктивным и эффективным. Если же язык усложняет процесс программирования, то это может быть признаком его устарелости.
• Малая популярность: если язык программирования не используется большим количеством разработчиков, то это может быть признаком его устарелости и неактуальности.
• Отсутствие обновлений: если язык программирования не получает обновлений, исправлений ошибок и улучшений, то это может быть признаком того, что он устарел и не поддерживается разработчиком.

✅  2023/03/29 22:25, move.l -(*void),(a0)+          #66 

но что конкретно вы предлагаете?
1. чтобы `i++` работало точно также как и `++i`;
2. запретить `i++`, оставив только `++i`;
3. разрешить `++i`, `i++` и `arr[++i]`, но запретить `arr[i++]`, что мне больше всего нравится.

;псевдокод из мануала 68kprm.pdf, section 2 addressing capabilities 
; и далее, описание опкодов команд
movem <list>, <ea> ; список регистров -> эффективный адрес
 ; или 
 movep Dx,(d16,Ay)  ;
 move16 (Ax)+,(Ay)+
 move <ea>,<ea> ; из эффективного адреса в эффективный адрес слева направо
; например
 move.l (a0)+,-(a1);
; псевдокод
; move.l  ([bd,An,Xn],od),(d8,An,Xn) ;MC68020,MC68030,MC68040

; про структуру опкодов

;  table 2-1. instruction word format definitions
; mode, register, D/A, W/L, scale*1,*2,*4,*8, BS(base register added/suppress),
; bd size=base displacement size(reserved, null, word, long),
; I/IS index/indirect selection  indirect and indexing operand determined
; in conjunction with bit 6, index suppress

; table 2-2. IS-I/IS memory indirect action encodings
; IS 0 index/indirect 000 No Memory Indirect Action
; IS 0 I/IS           001 Indirect Preindexed with Null Outer Dispacement
; IS 0 I/IS           010 Indirect Preindexed with Word Outer Dispacement
; IS 0 I/IS           011 Indirect Preindexed with Long Outer Dispacement
; IS 0 I/IS           100 Reserved
; IS 0 I/IS           101 Indirect Postindexed with Null Outer Dispacement 
; IS 0 I/IS           110 Indirect Postindexed with Word Outer Dispacement 
; IS 0 I/IS           111 Indirect Postindexed with Word Outer Dispacement 
; IS 1 I/IS           000 No Memory Indirect Action
; IS 1 I/IS           001 Memory Indirect with Null Outer Displacement
; IS 1 I/IS           010 Memory Indirect with Word Outer Displacement
; IS 1 I/IS           011 Memory Indirect with Long Outer Displacement
; IS 1 I/IS           100-111 Reserved

;далее в мануале идёт раздел 2.2 EFFECTIVE ADDRESSING MODES
; 2.2.1 Data Register Direct Mode
; 2.2.2 Address Register Direct Mode
; 2.2.3 Address Register Indirect Mode
; 2.2.4 Address Register with Postincrement Mode
; 2.2.5 Address Register with Predecrement Mode
; 2.2.6 Address Register Indirect with Displacement Mode
; 2.2.7 Address Register Indirect with Index (8-bit Displacement) Mode
; 2.2.8 Address Register Indirect with Index (Base Displacement) Mode
; 2.2.9 Memory Indirect Postindexed mode
; 2.2.10 Memory Indirect Preindexed mode
; 2.2.11 Program Counter Indirect with Displacement Mode
; 2.2.12 Program Counter Indirect with Index (8-bit Displacement) Mode
; 2.2.13 Program Counter Indirect with Index (Base Displacement) Mode
; 2.2.14 Program Counter Memory Indirect Postindexed Mode
; 2.2.15 Program Counter Memory Indirect Preindexed Mode
; 2.2.16 Absolute Short Addresing Mode
; 2.2.17 Absolute Long Addresing Mode
; 2.2.18 Immediate Data

move.l -(a0),(a1)+

(привет, (*this)->VirtualMethodTable(...), разыменовывающий (*void)(...)) 

✅  2023/03/29 22:29, void          #67 

Критика усредняющего разума

Книга неутомимого ниспровергателя стереотипов мышления, сковывающих познание изменяющегося человека в изменяющемся мире, выпускника Высшей школы образования Гарвардского университета Тодда Роуза по праву может быть определена ёмким символом «Манифест индивидуальности». Смысло­образующий мотив этой книги, названной The End of Average (почти в буквальном переводе — «Конец усредненности»), — бунт против всяческого усреднения и диктатуры стандарта, технологий обезличивания, обесценивающих неповто­римость каждого из нас, низводя её до уровня погрешности, отклонения от Нормы. Рискуя впасть в преувеличение, отмечу, что по своему значению и роли в смене ценностных установок это полемическое произведение вполне может конкурировать с эпохальными трактатами создателя философии нестабильности, лауреата Нобелевской премии Ильи Пригожина «Конец определенности: Время, Хаос и новые законы природы» (2000) и возмутителя спокойствия, социального философа и политолога Фрэнсиса Фукуямы «Конец истории и последний человек» (1992).

Каковы исторические и научные истоки мифологии «среднего человека», «среднего социального класса», «среднего ученика», «нормальной» профессиональной карьеры? Как в лоне статистики родились представления о стандарте и Норме, на долгие годы ставшие идеалами познания? Почему вслед за знаменитым бельгийским астрономом конца ХIХ века Адольфом Кетле, разрабатывавшим «метод усреднения», учение о «средних величинах», «типах» и «среднем человеке», идущие по его стопам поколения ученых, подобно язычникам, стали поклоняться таким идеалам, как Стандарт и Норма, а любые отклонения от Стандарта, в том числе индивидуальные различия между людьми, интерпретировать как погрешности измерений, досадные случайности, которые ради точности измерений необходимо отбрасывать, приносить в жертву системе? Как возникло мировоззрение, в котором Стандарты и Нормы, символы статистических усреднений, стали, по сути, идеалами управления на самых различных фабриках, в том числе и на фабрике образования как производстве «среднего ученика» или идеологической фабрике как производстве «среднего человека»?

Тодд Роуз шаг за шагом показывает, что за формулой «Система — всё, Индивидуальность — ничто» проступает явная или неявная вера в то, что обезличивает статистика обширных массивов данных позволит отсеять все лишнее, случайное и найти тот или иной «идеальный тип» — среднестатистическую норму, например, красоты, строения тела или же типовых параметров кабины самолета и тому подобного, под которую должны быть подстроены любые произведения нашего разума.

Переводя эти установки усредняющего разума на язык психологии обыденной жизни, так и хочется сказать: будь в образовании, политике, на производстве ближе к Норме, Стандарту, будь проще — и народ к тебе потянется. А если отклоняешься от Стандарта, заданного алгоритма, типовой программы образования — пеняй на себя. Неслучайно суть усредняющего разума Тодд Роуз иллюстрирует словами признанного классика конвейерных технологий в различных сферах индустриального общества Фредерика Тейлора.

«Готовность прощать самодеятельность — камень, о который споткнулись самые светлые умы, — предупреждал он в статье 1918 года. — Средний человек ни в коем случае не имеет права создавать новую машину, или метод, или процесс в целях замены уже имеющегося варианта».

Не только мы с вами порождаем те или иные технологии, но и технологии порождают нас. Хотим мы того или нет, доведенные до абсурда технологии стандартизации, типологизации, унификации, ранжирования, сертификации, тестирования рискуют превратиться в ритуалы особой религии — религии усредняющего мировоззрения. Именно поклонение подобным ритуалам становится, по мысли Тодда Роуза, знамением уходящего века как века усреднения. Думая о драматических последствиях века усреднения, невольно вспоминаешь название известной книги Милана Кундеры «Торжество незначительности».

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

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

Я пишу об этой опасности, так как новая вера в ХХI веке во всесилие «Больших Данных», которые позволят понять все на свете, даже предсказать непредсказуемое поведение индивидуальности, «вычислить», например, установки потребительского поведения каждого человека, чем-то сродни вере во всесилие усредняющего разума, прокладывающего единственную для всего человечества дорогу технологического прогресса. Неслучайно ещё на границе XIX и XX веков великий мыслитель Владимир Иванович Вернадский предупреждал, что, как только в нашем мышлении мы переходим от понимания каждого человека как индиви­дуальности к безликой категории «люди», мы рискуем потерять самого человека, его уникальность.

Книга Тодда Роуза, на мой взгляд, являет собой подлинный гимн разнообразию жизни, уникальности и ценности каждого человека. Уже много лет, читая студентам факультета психологии МГУ курс «Психология личности», я не устаю повторять «Индивидом рождаются! Личностью становятся. Индивидуальность отстаивают!»

Не сомневаюсь, что книга, посвященная критике усредняющего разума, будет нужна всем тем, кто рискует принимать самостоятельные решения и отстаивает индивидуальность. Она будет интересна представителям самых разных социальных сословий и профессиональных цехов. Политикам, строящим стратегии развития нашего общества, она даст прививку от «усреднения» при выработке программ развития страны; мастерам управления компаниями и организациями подскажет стратегии конструирования будущего и выращивания инновации в бизнесе с «необщим выражением лица»; психологам даст возможность почувствовать востребованность психологии личности как междисциплинарной ведущей науки о человеческой уникальности.

И наконец, эта книга с подзаголовком «Манифест индивидуальности» — редкий шанс для смены парадигмы школьного и высшего образования, перехода от парадигмы усредняющего века к парадигме века индиви­дуальности. В веке индивидуальности рано или поздно останется в прошлом представление о «нормальном» жизненном пути как единственно правильном пути с усредненными вехами образования и профессионального роста — пути, который расписан и предопределен, по образному выражению Тодда Роуза, «как по нотам». Например, вместо стандартной образовательной карьеры в стиле Тейлора — школьник, студент, аспирант, доцент, профессор, заведующий кафедрой… — предлагается близкий моему сердцу принцип множественности путей, который составляет ядро развиваемого в России вариативного образования как расширения возможностей для развития личности и компетентного выбора собственной биографии, собственной судьбы.

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

✅  2023/03/30 22:51, Автор сайта          #68 

в процессоре Motorola MC 68000 было разных 14 режимов адресации — и никто не жужжал по поводу сложности.

Это "сложна"

предекременты/постинкременты тянутся ещё из PDP

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

int i = 1;    // Описатель - первая точка следования, полное выражение - вторая
i += ++i + 1; // Полное выражение - третья точка следования
printf("%d\n", i); // Может быть выведено как 4, так и 5
i = i++ + 1; // неопределённое поведение
i = ++i + 1; // тоже неопределённое поведение

printf("%d, %d\n", --i, ++i); // неопределённое поведение
printf("%d, %d\n", ++i, ++i); // тоже неопределённое поведение

a[i] = i++; // неопределённое поведение
a[i++] = i; // тоже неопределённое поведение

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

✅  2023/04/01 03:44, void          #69 

Вы не замечаете очевидного — идёт обсуждение языков достаточно высокого уровня, а Вы пытаетесь увести обсуждение в сторону, приводя в пример машинный язык. Вы не чувствуете разницы?!

Coder-friendly

The goal of the 680x0 was to develop an easy to program coder-friendly CPU. The 680x0 is so easy to code because it does a lot of work to help you out. We can compare 680x0 to a car that is easy to drive and has many driver assistance features like automatic transmission, ABS, ESP, and Tesla autopilot.

A non-coder-friendly CPU makes coding harder, and you lose track of functions. That increases the risk of coding errors. It is much easier to make a stable program on 680x0 than other architectures.

Easy Coding. We truly believe that coding for the 68k is very easy, especially that 68k assembly is really easy to learn. <..>

Это, в первую очередь, низкопроизводительно с точки зрения расходования такого ресурса, как труд программиста. Много ли сейчас программируют на ассемблере? В исключительных случаях. Ну или «по приколу», как в случае KolibriOS.

Нет, не буквально! В PDP машинные операции инкремента и декремента соответствовали исключительно префиксным операциям Си. Никаких постфиксных операций inc/dec в ассемблере PDP быть просто не могло.

    mov (PC)+, R6 ; SP = (*void++)
void:  nop 
    mov -(PC), -(PC) ; PC = R7, SP = R6

Не кажется ли Вам, что слишком много проблем для такого малозначительного оператора? И этот абсурд поддерживается компиляторами в 21 веке!

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

✅  2023/04/01 11:21, MihalNik          #70 

Результатом экономии труда времени программиста стало катастрофическое падение его качества.

наглядные исходники Оберон-2 с кодогенерацией под простой и понятный 68k, например

что на ассемблере может код быть достаточно высокоуровневым и при этом всё легко читаемым (если ISA микроархитектура CPU адекватна и с "человеческим лицом", то есть, coder-friendly

✅  2023/04/01 13:50, Автор сайта          #71 

      move.l  #FX+64,$DFF410        ; Set 32bit Ptr (skipp AIFF 64byte header)
      move.l  #(FX_e-FX-64)/2,$DFF414 ; Set 32bit Length (length in pairs of sample)
      move.w  #$00FF,$DFF418        ; Play sample on right speaker
      move.w  #80,$DFF41C           ; Set Samplerate 44khz
      move.w  #01,$DFF41A           ; Set 8Bit One-Shot mode
      move.w  #$8202,$DFF096        ; Enable DMA

Можно также примерно проэкстраполировать 68060 раз в 5-6, и получить нечто аналогичное Pentium I MMX 1200 Mhz.

"сложна" и "ненужна"

Просто существует другой путь действительно развития. Да и он всегда тут был, рядышком — просто его перестали замечать, когда это стало вдруг внезапно "не модным".

стали записывать CISC и вообще ассемблер в "устаревший язык"?

✅  2023/04/01 16:24, Ильдар          #72 

Никаких постфиксных операций inc/dec в ассемблере PDP быть просто не могло.
Ну, значит в мотороллерах они уже появились.

*dst++ = *src++;

 *dst = *src;	// само выражение
 dst++; src++;	// инкремент выполняется ПОСЛЕ!

✅  2023/04/02 15:43, Comdiv          #73 

А что касается приведённых Вами цифр — с трудом в них верится. Ведь переход по условию переполнения будет весьма редок. Ведь именно такой переход будет вызывать торможение

✅  2023/04/02 20:46, Автор сайта          #74 

✅  2023/04/02 22:44, void          #75 

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

Ковалёв Сергей Протасович. Теорико-категорные модели и методы проектирования больших информационно-управляющих систем. Москва 2013

✅  2023/04/03 00:01, void          #76 

Но это в Си. А вот у машинных кодов нет выражений! Они выполняются сразу же.

    ORG    $1000
START:                  ; first instruction of program

* Put program code here

    LEA SRC, A1
    LEA DST,A2
    MOVE #9, d1  ; a-1
STRNCPY:     
    MOVE.B (a1)+,(a2)+
    DBRA D1,STRNCPY
    
* PRINT "DST" STRING    
    lea DST,A1
    MOVE #14,D0
    TRAP #15

    SIMHALT             ; halt simulator

* Put variables and constants here

RULER   DC.b '0123456789a'
SRC     DC.B 'from.THERE',0
DST     dc.B 'TO.HERE123',0

    END    START        ; last line of source

from.THERE

LOOP CX

DBRA Dx,label

*-----------------------------------------------------------
* Title         : Tutorial 3 for EASy68k
* Written by    : Chuck Kelly
* Date Created  : May-06-2004
* Dec-25-2012 by CK, Uses SIMHALT
* Description   : 
*
* A simple number guessing game. The program generates a random number
* between 1 and 100 and asks the player to guess the number. After each guess
* the program displays higher or lower until the player guesses the correct number.
*
* Demonstrates Structured Assembly, SECTION directive & Macros with EASy68K
*-----------------------------------------------------------
    OPT     MEX         Expand macro calls
    OPT     SEX         Expand structured statements

CODE    EQU     0
TEXT    EQU     1
CR      EQU     $0D
LF      EQU     $0A


    SECTION TEXT
    ORG     $800        set the address for TEXT data

    SECTION CODE
    ORG     $2000       set the address for program code

PRINT   MACRO
    lea     \1,a1
    move.b  #14,d0
    trap    #15
    ENDM

GETNUM  MACRO
    move.b  #4,d0       get user guess in D1.L
    trap    #15
    ENDM

*----------------------------------------------------
* Program execution begins here
*----------------------------------------------------
START

  repeat
    PRINT instr_Msg     print instructions

    * generate random number for player to guess
    * Uses timer as random number generator. This may not be the best way to
    * generate a random number but it will work for this demonstration.
    * Trap code 8 returns time in hundredths of a second since midnight in D1.L

    move.b  #8,d0
    trap    #15
    and.l   #$5FFFFF,d1 prevent overflow in divu
    divu    #100,d1     time count / 100
    swap    d1        swap upper and lower words of D1 to put remainder in low word
    addq.w  #1,d1       d1.w contains number from 1 to 100
    move    d1,d2       d2 = d1

    repeat
      PRINT enterMsg    Display 'enter guess' prompt
      GETNUM            get user guess in D1.L

      if d1 <ne> #0 then
        if d1 <hi> d2 then  if the player guessed hi
          PRINT bigMsg      Display 'Too Big'
        else
          if d1 <lo> d2 then    if the player guessed lo
            PRINT smallMsg      Display 'Too Small'
          else                  The user guessed the number
            PRINT goodMsg       Display 'Good Guess'
          endi
        endi
      endi
    until d1 <eq> #0 OR d1 <eq> d2 do
  until d1 <eq> #0 do

    SIMHALT

    SECTION     TEXT
instr_Msg   dc.b    CR,LF
        dc.b    '----- Number guessing game -----',CR,LF
        dc.b    ' Guess the number from 1 to 100',CR,LF
        dc.b    ' Enter a 0 to quit the game',CR,LF,CR,LF,0

enterMsg    dc.b    CR,LF,'Enter your guess: ',0
goodMsg     dc.b    CR,LF,'Good guess, that is correct!',CR,LF,0
bigMsg      dc.b    CR,LF,'Your guess is too big',CR,LF,0
smallMsg    dc.b    CR,LF,'Your guess is too small',CR,LF,0
        
    END     START

    movem.l d0-d7/a0-a6,-(SP) ; PUSH registers
    movem.l (SP)+,d0-d7/a0-a6 ; POP registers, a7=SP

✅  2024/04/10 18:12, veector          #77 

✅  2024/04/13 00:00, alextretyak          #78 

В PDP машинные операции инкремента и декремента соответствовали исключительно префиксным операциям Си. Никаких постфиксных операций inc/dec в ассемблере PDP быть просто не могло.

Ахинея. Постфиксные инкремент или декремент вычисляются после ...

clr r0           ; r0 = 0
mov #000100 r1   ; r1 = 000100
movb (r0)+ (r1)+ ; *r1++ = *r0++
movb (r0)+ (r1)+ ; *r1++ = *r0++
movb (r0)+ (r1)+ ; *r1++ = *r0++
movb (r0)+ (r1)+ ; *r1++ = *r0++

mov (pc)+, r1
.word 000100

✅  2024/04/13 12:31, Автор сайта          #79 

 while (*dst++ = *src++);

✅  2024/04/15 00:00, alextretyak          #80 

Таким образом, к началу следующей фазы — выполнения инструкции — регистр pc/eip/rip будет указывать уже на следующую инструкцию.

Всё, что Вы так подробно описываете, справедливо с точки зрения микропрограммного управления.

К примеру, push сперва заталкивает что-то в стек, а потом изменяет адрес вершины стека.

Самый низкий уровень, к которому он имеет доступ, — это машинные операции

BOOOsssSSSdddDDD
│└┬┘└┬┘└┬┘└┬┘└┬┘
│ │  │  │  │  └─ 0-2 биты: регистр-приёмник
│ │  │  │  └──── 3-5 биты: режим адресации регистра-приёмника
│ │  │  └─────── 6-8 биты: регистр-источник
│ │  └───────── 9-11 биты: режим адресации регистра-источника
│ └─────────── 12-14 биты: код операции
└───────────────── 15 бит: признак byte-инструкций

┌───┬───┬────────────────┐
│Bin│Oct│Assembler Syntax│
├───┼───┼────────────────┤
│000│ 0 │ Rn             │
│001│ 1 │(Rn)            │
│010│ 2 │(Rn)+           │
│100│ 4 │-(Rn)           │
└───┴───┴────────────────┘

; Во второй колонке соответствующий код на языке Си
; В третьей колонке машинный код в восьмеричной сис. сч.
movb r3    r5   ;  r5 =  r3      ; 11│0│3│0│5
mov  r3    r5   ;  r5 =  r3      ; 01│0│3│0│5
mov (r3)   r5   ;  r5 = *r3      ; 01│1│3│0│5
mov  r3   (r5)  ; *r5 =  r3      ; 01│0│3│1│5
mov (r3)  (r5)  ; *r5 = *r3      ; 01│1│3│1│5

mov (r3)+ (r5)  ; *r5   = *r3++  ; 01│2│3│1│5
mov (r3)  (r5)+ ; *r5++ = *r3    ; 01│1│3│2│5
mov (r3)+ (r5)+ ; *r5++ = *r3++  ; 01│2│3│2│5

mov (r3) -(r5)  ; *--r5 = *r3    ; 01│1│3│4│5
...

add  r3    r5   ;  r5   +=  r3   ; 06│0│3│0│5
...
add (r3)  (r5)  ; *r5   += *r3   ; 06│1│3│1│5
add (r3)+ (r5)  ; *r5   += *r3++ ; 06│2│3│1│5
add (r3)  (r5)+ ; *r5++ += *r3   ; 06│1│3│2│5
add (r3)+ (r5)+ ; *r5++ += *r3++ ; 06│2│3│2│5
add -(r3) (r5)  ; *r5   += *--r3 ; 06│4│3│1│5
...

sub  r3    r5   ;  r5   -=  r3   ; 16│0│3│0│5
...

Поэтому говорить о постдекрементах и преинкрементах совершенно бессмысленно.

https://news.ycombinator.com/item?id=24817321:

«pre/post-increment/decrement addressing is baked into the instruction set»

«... 4 is the pre-decrement mode ...»

https://stackoverflow.com/questions/17436141/kr-seems-to-prefer-pre-increment:

«PDP-11 had post-increment and pre-decrement.»

while (*dst++ = *src++);

потом выход в случае нулевого значения. И только в самом конце — постфиксные инкременты.

begin_while:
bool is_not_zero = (*dst++ = *src++) != 0;
if (!is_not_zero) goto end_while;
// Здесь располагается тело цикла while, но в данном случае оно пустое
goto begin_while;
end_while:

mov #100 r0 ; r0 - src
mov #200 r1 ; r1 - dst

begin_while:
movb (r0)+ (r1)+ ; bool is_not_zero = (*dst++ = *src++) != 0;
beq end_while    ; if (!is_not_zero) goto end_while;
br begin_while   ; goto begin_while;
end_while:
halt

; Копируемые данные:
.= 100
.word 123456
.word 007700
.word 000000

; Область памяти назначения забиваем мусором
; (для проверки того, что данные из источника
; скопировались полностью, включая завершающий
; нулевой байт)
.= 200
.word 111111
.word 111111
.word 111111
.word 111111

✅  2024/04/18 04:47, void          #81 

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

Вот здесь есть дырка в понимании поведения абстрактного исполнителя интерпретатором/модели памяти и верификатора стандарта компилятором.

1. интерпретируемого BCPL, откуда в Си пришла семантика указателей (дырявая),
2. вот этот пример с ассемблером CISC процессоров PDP-11 либо MC68k.

✅  2024/04/19 22:13, Автор сайта          #82 

И всё-таки инкременты выполняются перед выходом.

0019ff20:  20 21 22 23| 24 25 26 00| 28 29 2a 2b| 2c 2d 2e 00 | !"#|$%&.|()*+|,-..|

0019ff30:  21 22 23 24| 25 26 27 00| 29 2a 2b 2c| 2d 2e 2f 00 |!"#$|%&'.|)*+,|-./.|

	while (*dst++ = *src++);

0019ff30:  20 21 22 23| 24 25 26 00| 29 2a 2b 2c| 2d 2e 2f 00 | !"#|$%&.|)*+,|-./.|

src = 19ff28
dst = 19ff38

• были скопированы байты 0 — 7, включая седьмой с содержимым 0,
• содержимое 0 седьмого байта послужило сигналом в выходу; этот факт процессор запомнил,
• был выполнен постинкремент переменных src и dst и они стали отличиться от исходных значений не на 7, а на 8!
• и, наконец, выход.

	while (*dst++ += *src++);

0019ff30:  41 43 45 47| 49 4b 4d 00| 29 2a 2b 2c| 2d 2e 2f 00 |ACEG|IKM.|)*+,|-./.|

int  F (int  i) { return  i & 1; }
. . .
	while (*dst++ += F(*src) * *src++);

0019ff30:  21 43 23 47| 25 4b 27 00| 29 2a 2b 2c| 2d 2e 2f 00 |!C#G|%K'.|)*+,|-./.|

это тоже один из признаков устаревшего языка: Undefined Behaviour в стандарте, причём UB is not error

❔  2024/04/23 00:00, alextretyak          #83 

Уместно-уместно. Причина одна, и это тоже один из признаков устаревшего языка: Undefined Behaviour

То есть произошло следующее:

• были скопированы байты 0 — 7, включая седьмой с содержимым 0,
• содержимое 0 седьмого байта послужило сигналом в выходу; этот факт процессор запомнил,
• был выполнен постинкремент переменных src и dst и они стали отличиться от исходных значений не на 7, а на 8!
• и, наконец, выход.

.L2:
        mov     rdx, QWORD PTR [rbp-8]  ; rdx = src   ; prev_src = src
        lea     rax, [rdx+1]            ; rax = rdx+1
        mov     QWORD PTR [rbp-8], rax  ; src = rax   ; ++src
        mov     rax, QWORD PTR [rbp-16] ; rax = dst   ; prev_dst = dst
        lea     rcx, [rax+1]            ; rcx = rax+1
        mov     QWORD PTR [rbp-16], rcx ; dst = rcx   ; ++dst
        movzx   edx, BYTE PTR [rdx]     ; dl = *rdx
        mov     BYTE PTR [rax], dl      ; *rax = dl   ; *prev_dst = *prev_src
        movzx   eax, BYTE PTR [rax]     ; al = *rax
        test    al, al                  ; if (al != 0)
        jne     .L2                     ;     goto .L2

The value computation of the ++ expression is sequenced before the modification of the operand object.

Вычисление значения выражения ++ выполняется до модификации объекта операнда.

while (*postfix_increment(dst) = *postfix_increment(src));

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su