Ну, не такой уж она и раритет. И появилась задолго до «Электроники». Если мне не изменяет память, в США она длительное время была самой популярной ОС на DEC PDP, в отличие от СССР, где преобладали ОС-РВ (RSX11) и РАФОС (RT-11).
Простейшая и ежедневно имеющая место ситуация нашей действительности int i + 1: в архитектуре x86 целочисленное (знаковое) переполнение приводит к wrap around, а оно же на MIPS — trap.
Доставляет “приколов” и то, что на этом же самом MIPS целочисленное знаковое переполнение при операциях умножения или деления уже не трапается, как при сложении/вычитании, а молча заворачивается (wrap around).
Так какие ваши доказательства предложения по “определению переполнения” в том же С (или вообще) для упрощения жизни? Как заставить оптимизатор не считать “раз тут так складывают, то переполнения точно не будет”, и получить эффективный код на x86 и на MIPS?
Другой пример: int x / int y. При y == 0 на x86 — trap, а на PowerPC — спокойно “едем” дальше: Как определить деление на 0 так, чтобы оптимизаторы перестали считать “раз тут делят, то y точно не 0, и можно слегка подоптимизировать”, и получить эффективный код на x86 и на PowerPC?
С дереференсом 0 тоже полно приколов, Как определить Null pointer dereference так, чтобы оптимизаторы перестали считать “раз тут ptr дереференсится, то он точно не Null,и можно наоптимизировать”, и получить эффективный код на x86 (где вообще-то нет никаких проблем отмапить 0 по своей нужде) и на ARM (где обычно на 0 — обработчики исключений)?
Может, проще оптимизаторы запретить? Или собрать специальную рабочую группу ООН, которая напишет, а ГА ООН примет соответствующую резолюцию о единственно расово верных реакциях на все ситуации для всех производителей процессоров? <сарказм>
Словом, «И нашим, и вашим» — не получится, если мы о ЯВУ, у которых “высота” уровня низка настолько, что позволяет легко и эффективно писать программы для bare metal, а не каких-то абстрактных виртуальных машин. У знающих и понимающих целевую архитектуру программистов на ассемблерах описанные выше проблемы не существуют. Правда, у них и чрезмерно прытких оптимизаторов тоже нет. Если разработчик не знает/не понимает архитектуру целевой системы, вряд ли ему следует лезть в C или Rust. В Java или Python ему будет много комфортнее.
А жопоголовому кодеру, который не желает в валидацию данных, не поможет ничего. Он скорее будет возмущаться, что разработчики glibc/bsd libc/musl — идиоты, поскольку в strlen не проверяют (и правильно делают) параметр на NULL, а его программа из-за этого трапнулась.
Ага. Например, из языка C надо выкинуть операцию сложения. А то из-за неё случаются переполнения, и одни безответственные программисты используют x + 1 < x для проверки, а у других несчастных это x + 1 при переполнении вызывает trap (на MIPS, например), и проверять уже поздно.
С вычитанием, кстати, то же самое. Тоже надо выкинуть.
Безответственному программисту не поможет никакой язык.
По-моему, ЛА3 всегда была хитом продаж. По вполне понятным причинам. Когда я только вкатывался в цифровую электронику (вторая половина 70-х прошлого века), мне мой “ментор” подогнал целую гору военных ТЭЗов, по 16-20 корпусов 133-й серии на каждом, из которых абсолютное большинство были именно ЛА3.
У меня в конце 80-х “боевые алгоритмы” шились накруткой, только не на кольца, а на ферритовые “пеньки”. Обычной медной проволокой. Вручную.
А в статье речь не про ПЗУ, а про энергонезависимую RAM. Это скорее аналог флешки. У той же СМ-3 были модификации с RAM на ферритовых кольцах. Не стирается при выключении питания. А программируется всё же не накруткой проводов, а сигналами по этим проводам.
Высшее образование ... не даёт исчерпывающих знаний для успешной карьеры.
И — что важно, но многим почему-то непонятно — не должно!
Респонденту Максиму:
не надо тратить четыре года на какой-нибудь устаревший Pascal
Вот в этом-то и проблема. И это проблема не “вышки”, и даже не большинства курсов для “вкатунов”. Перестаньте уже наконец учить языки и фреймворки, начните уже наконец учить программирование.
Вы этой своей статьёй тоже способствуете росту позиций COBOL и FORTRAN в индексе Tiobe. Только это не имеет практически никакого отношения к росту популярности этих языков как инструментов. Достаточно одной новости о том, как IBM ищет пару разработчиков на COBOL по $500k в год на брата для поддержки 40-летней системы — и позиция COBOL в индексе Tiobe взлетает ракетой, ведь кругом это обсуждается. А популярность языка не подросла ни на йоту.
Вопрос о вкусах, конечно, но Cisco — далеко не лучший пример стройного и логичного конфига. Он плоский как блин. А их ACL — это вообще печаль. После Juniper (а ещё у Bay Networks был прелестный BCL незадолго до покупки Nortel'ом) простыни Cisco хочется свернуть в трубочку, обнять и плакать :)
8 лет назад поехал путешествовать по Европам, и по пути в Петербурге купил Waeco CDF-16. И ни разу с тех времён в нём не разочаровался. А сейчас взглянул на его цену, и порадовался ещё больше :)
Самое смешное в этой фотографии для меня то, что при всей её постановочности — люди, на серьёзных щах втыкающие в центральный пульт (рядом с которым в действительности если и сидели при штатной работе, то так, чтобы она была справа/слева под рукой), товарищи офицеры на не менее серьёзных щах втыкающие в скорее всего какой-то из талмудов от ЭВМ — это осциллограф! Вот он — совсем не постановка. Их реально приходилось практически всегда иметь рядом. Более того, зачастую — с подключенными к какой-нибудь“ноге” щупами.
Помню, мы две недели пытались отловить проблему в таком чудесатом дисплее — ВТА-2000. Всякий раз, когда он глючил, его выключали, вынимали подозреваемый ТЭЗ, устанавливали его на “расшивку”, подключали осциллограф на подозреваемые цепи, включали — он, собака, опять работал как ни в чём ни бывало. В конце концов так и пришлось оставить, категорически запретив увозить осциллограф, дабы поймать гада прямо в момент “совершения преступления.” Таки поймали, подтвердив до кучи известный уже тогда современно выражаясь мем про то, что советские микросхемы (а это была банальная К155ЛА3, 4×2И-НЕ) будут до упора бороться за свою жизнь в реанимации, то умерев, то вновь воскреснув. В отличие от иностранных, которые если подыхали, то сразу и навсегда
Я, конечно, не “в самом начале” начал, а всего лишь в 1978-м, но у нас программисты назывались алгоритмистами, и знание какого-либо языка программирования не было для них сколько-нибудь обязательным. Их деятельность, как легко догадаться, состояла в составлении алгоритмов решения той или иной задачи. И выдавали они их на довольно слабо формализованном языке, для чего лучше всего подошёл бы TeX, но он тогда только-только родился Д. Кнутом, и в СССР был совершенно неизвестен и недоступен. Потому их продукт был больше похож на то, что все делали в школе, расписывая пошагово решение примера по арифметике. И да, преимущественно — мужчины.
А вот переводом их алгоритмов на “понятный” для ЭВМ язык — в моём случае это был Algol-60 и ассемблер (АвтоКод) — занимались кодировщики. Они оформляли это всё на специальных бланках, которые затем передавались в отдел подготовки данных. И да, тоже в основном мужчины.
А вот в отделе подготовки данных уже преобладали женщины. Это было что-то типа работы машинистки — получить тот самый бланк от кодировщика, и скрупулёзно, буковка в буковку, набрать это на упомянутом в статье Консул-254, превратив тем самым код в дырки на перфокартах.
Колода карт отправлялась операторам ЭВМ — тоже в массе своей женщины — которые укладывали их в считыватели и нажимали кнопку. Результат — ошибки компиляции или результаты исполнения программы — печатались и попадали либо кодировщику (если ошибки), либо алгоритмисту (программисту).
С одним таким прямо-таки выдающимся программистом, который не знал ни одного языка программирования, мне довелось поработать почти до середины 90-х. Его программы — немалая доля во всей советской ПРО. Но он — повторюсь — не знал ни одного языка программирования.
Ну, не такой уж она и раритет. И появилась задолго до «Электроники». Если мне не изменяет память, в США она длительное время была самой популярной ОС на DEC PDP, в отличие от СССР, где преобладали ОС-РВ (RSX11) и РАФОС (RT-11).
Неполный ≠ неверный.
Вы станете говорить математику 2×2=4 или хватит 2×2? Он математик, а не идиот, он знает, что 4.
Вы станете говорить плёночному фотографу, что открытие камеры на свету приведёт к засвечиванию плёнки? Вы считаете его идиотом?
А ты уже получил диплом влажного фантазёра и сертификат регулятора контента в интернетах?
Простейшая и ежедневно имеющая место ситуация нашей действительности
int i + 1: в архитектуре x86 целочисленное (знаковое) переполнение приводит к wrap around, а оно же на MIPS — trap.Доставляет “приколов” и то, что на этом же самом MIPS целочисленное знаковое переполнение при операциях умножения или деления уже не трапается, как при сложении/вычитании, а молча заворачивается (wrap around).
Так какие ваши
доказательствапредложения по “определению переполнения” в том же С (или вообще) для упрощения жизни? Как заставить оптимизатор не считать “раз тут так складывают, то переполнения точно не будет”, и получить эффективный код на x86 и на MIPS?Другой пример:
int x / int y. Приy == 0на x86 — trap, а на PowerPC — спокойно “едем” дальше: Как определить деление на 0 так, чтобы оптимизаторы перестали считать “раз тут делят, тоyточно не 0, и можно слегка подоптимизировать”, и получить эффективный код на x86 и на PowerPC?С дереференсом 0 тоже полно приколов, Как определить Null pointer dereference так, чтобы оптимизаторы перестали считать “раз тут
ptrдереференсится, то он точно неNull,и можно наоптимизировать”, и получить эффективный код на x86 (где вообще-то нет никаких проблем отмапить 0 по своей нужде) и на ARM (где обычно на 0 — обработчики исключений)?Может, проще оптимизаторы запретить? Или собрать специальную рабочую группу ООН, которая напишет, а ГА ООН примет соответствующую резолюцию о единственно расово верных реакциях на все ситуации для всех производителей процессоров? <сарказм>
Словом, «И нашим, и вашим» — не получится, если мы о ЯВУ, у которых “высота” уровня низка настолько, что позволяет легко и эффективно писать программы для bare metal, а не каких-то абстрактных виртуальных машин. У знающих и понимающих целевую архитектуру программистов на ассемблерах описанные выше проблемы не существуют. Правда, у них и чрезмерно прытких оптимизаторов тоже нет. Если разработчик не знает/не понимает архитектуру целевой системы, вряд ли ему следует лезть в C или Rust. В Java или Python ему будет много комфортнее.
А жопоголовому кодеру, который не желает в валидацию данных, не поможет ничего. Он скорее будет возмущаться, что разработчики glibc/bsd libc/musl — идиоты, поскольку в
strlenне проверяют (и правильно делают) параметр наNULL, а его программа из-за этого трапнулась.Ага. Например, из языка C надо выкинуть операцию сложения. А то из-за неё случаются переполнения, и одни безответственные программисты используют
x + 1 < xдля проверки, а у других несчастных этоx + 1при переполнении вызывает trap (на MIPS, например), и проверять уже поздно.С вычитанием, кстати, то же самое. Тоже надо выкинуть.
Безответственному программисту не поможет никакой язык.
По-моему, ЛА3 всегда была хитом продаж. По вполне понятным причинам. Когда я только вкатывался в цифровую электронику (вторая половина 70-х прошлого века), мне мой “ментор” подогнал целую гору военных ТЭЗов, по 16-20 корпусов 133-й серии на каждом, из которых абсолютное большинство были именно ЛА3.
Классные у тебя статьи. Обе две, да.
Шли годы, а свежеустановленный
gitтак и продолжает рассказывать нам о том, что название главной веткиmaster is a subject to change.У меня в конце 80-х “боевые алгоритмы” шились накруткой, только не на кольца, а на ферритовые “пеньки”. Обычной медной проволокой. Вручную.
А в статье речь не про ПЗУ, а про энергонезависимую RAM. Это скорее аналог флешки. У той же СМ-3 были модификации с RAM на ферритовых кольцах. Не стирается при выключении питания. А программируется всё же не накруткой проводов, а сигналами по этим проводам.
Автору:
И — что важно, но многим почему-то непонятно — не должно!
Респонденту Максиму:
Вот в этом-то и проблема. И это проблема не “вышки”, и даже не большинства курсов для “вкатунов”. Перестаньте уже наконец учить языки и фреймворки, начните уже наконец учить программирование.
Анекдот напомнил другой анекдот. О длине половых органов и констатации огромных объёмов недополученного секса тогдашними радикальными феминистками.
Вы этой своей статьёй тоже способствуете росту позиций COBOL и FORTRAN в индексе Tiobe. Только это не имеет практически никакого отношения к росту популярности этих языков как инструментов. Достаточно одной новости о том, как IBM ищет пару разработчиков на COBOL по $500k в год на брата для поддержки 40-летней системы — и позиция COBOL в индексе Tiobe взлетает ракетой, ведь кругом это обсуждается. А популярность языка не подросла ни на йоту.
Вопрос о вкусах, конечно, но Cisco — далеко не лучший пример стройного и логичного конфига. Он плоский как блин. А их ACL — это вообще печаль. После Juniper (а ещё у Bay Networks был прелестный BCL незадолго до покупки Nortel'ом) простыни Cisco хочется свернуть в трубочку, обнять и плакать :)
CIDR'у пошёл уже четвёртый десяток лет, а кто-то до сих пор о классах вспоминает :)
Если принять во внимание, что на 9 из 10 пользовательских компьютеров стоит MS Windows, то ваше “иногда” выглядит довольно забавно :)
Самое смешное определение маршрутизатора, когда-либо попадавшееся мне на глаза :) Есть в нём что-то такое по-детски наивное, что прям даже мило.
8 лет назад поехал путешествовать по Европам, и по пути в Петербурге купил Waeco CDF-16. И ни разу с тех времён в нём не разочаровался. А сейчас взглянул на его цену, и порадовался ещё больше :)
Если на клетку с ослом повесить табличку «Слон», в клетке всё равно будет осёл.
Agile-команду нельзя создать. Agile-команда может сформироваться только сама.
Самое смешное в этой фотографии для меня то, что при всей её постановочности — люди, на серьёзных щах втыкающие в центральный пульт (рядом с которым в действительности если и сидели при штатной работе, то так, чтобы она была справа/слева под рукой), товарищи офицеры на не менее серьёзных щах втыкающие в скорее всего какой-то из талмудов от ЭВМ — это осциллограф! Вот он — совсем не постановка. Их реально приходилось практически всегда иметь рядом. Более того, зачастую — с подключенными к какой-нибудь“ноге” щупами.
Помню, мы две недели пытались отловить проблему в таком чудесатом дисплее — ВТА-2000. Всякий раз, когда он глючил, его выключали, вынимали подозреваемый ТЭЗ, устанавливали его на “расшивку”, подключали осциллограф на подозреваемые цепи, включали — он, собака, опять работал как ни в чём ни бывало. В конце концов так и пришлось оставить, категорически запретив увозить осциллограф, дабы поймать гада прямо в момент “совершения преступления.” Таки поймали, подтвердив до кучи известный уже тогда современно выражаясь мем про то, что советские микросхемы (а это была банальная К155ЛА3, 4×2И-НЕ) будут до упора бороться за свою жизнь в реанимации, то умерев, то вновь воскреснув. В отличие от иностранных, которые если подыхали, то сразу и навсегда
Я, конечно, не “в самом начале” начал, а всего лишь в 1978-м, но у нас программисты назывались алгоритмистами, и знание какого-либо языка программирования не было для них сколько-нибудь обязательным. Их деятельность, как легко догадаться, состояла в составлении алгоритмов решения той или иной задачи. И выдавали они их на довольно слабо формализованном языке, для чего лучше всего подошёл бы TeX, но он тогда только-только родился Д. Кнутом, и в СССР был совершенно неизвестен и недоступен. Потому их продукт был больше похож на то, что все делали в школе, расписывая пошагово решение примера по арифметике. И да, преимущественно — мужчины.
А вот переводом их алгоритмов на “понятный” для ЭВМ язык — в моём случае это был Algol-60 и ассемблер (АвтоКод) — занимались кодировщики. Они оформляли это всё на специальных бланках, которые затем передавались в отдел подготовки данных. И да, тоже в основном мужчины.
А вот в отделе подготовки данных уже преобладали женщины. Это было что-то типа работы машинистки — получить тот самый бланк от кодировщика, и скрупулёзно, буковка в буковку, набрать это на упомянутом в статье Консул-254, превратив тем самым код в дырки на перфокартах.
Колода карт отправлялась операторам ЭВМ — тоже в массе своей женщины — которые укладывали их в считыватели и нажимали кнопку. Результат — ошибки компиляции или результаты исполнения программы — печатались и попадали либо кодировщику (если ошибки), либо алгоритмисту (программисту).
С одним таким прямо-таки выдающимся программистом, который не знал ни одного языка программирования, мне довелось поработать почти до середины 90-х. Его программы — немалая доля во всей советской ПРО. Но он — повторюсь — не знал ни одного языка программирования.