57 лет назад была выполнена первая программа на Basic'е.

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

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

Зачем? Не проще закопать Си окончательно?

1. Комитет не хочет себя самораспускать наверное :)

2. Они хотят только часть фич из С++, а не все.

3. Так как основные компиляторы С (gcc, clang, MSVC) являются и компиляторами С++, то ввод новых фич в С с синтаксисом С++ уменьшает работу для разработчиков компиляторов, поэтому вполне возможно что С23 будет поддерживаться компиляторами в том же 23 году.

Они хотят только часть фич из С++, а не все.

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

Так как основные компиляторы С (gcc, clang, MSVC) являются и компиляторами С++, то ввод новых фич в С с синтаксисом С++ уменьшает работу для разработчиков компиляторов

Если полностью выкинуть Си, то это ещё сильнее упростит разработку компиляторов.

Давай разберемся

Ты говорил о языке, а не машкодах! Язык един для всех платформ!!! И если функция работает на x86_64, то она будет и на арме, и на мипсе, и на спарке, и на микроконтроллере восьмибитном работать!

2 кБ кода, нулевое использование памяти при декомпрессии.

Да? И куда я это буду распаковывать? В 10кБ оперативки что ли???

Ты, я так понимаю, не знаком с людьми, которые упаковывают 3D шутаны в win32-бинарник 64 кБ.

И распаковывают его в 128кБ?

в 60-х не было ни паскаля, ни Си, ни модулы, ни оберона.

Но был предмет обсуждения и алголы, например

В 60-х бейсик работал на мейнфреймах! Ничего мельче не могло запустить такой тяжеловевсный язык.

На чём будешь писать вместо С в 23 году?

С чего ты взял, что я буду в 23 году писать на чем-то другом? Только на С. И в 2030 году, если доживу, буду на С писать. И в 2040 (но там уже маловероятно, что доживу: сильно сомневаюсь, что смогу до 60 лет проскрипеть).

Ты вообще в курсе что в твоём С делается?

Да насрать мне! Я пишу в стиле С99 и не собираюсь этот стиль менять. А gcc до сих пор может собрать даже исходники родом из семидесятых годов (поругается, конечно, но соберет).

Но фанаты С вообще не следят за развитием языка :(

Последнее вменяемое развитие было в С99, когда стало возможным массивы по индексам инициализировать. Больше ничего эдакого не встречал. Я читал о С11: там вообще ничего полезного нет, одно бесполезнейшее дерьмище вроде генериков и т.п.

Ну идея исключения она как бы в воздухе витает, ошибка в основной программе перейди к плану бэ. На лиспе это наверное выглядит как (PlanA PlanB), хотя не видел в глаза лиспа, с автолиспом который в автокаде это родственники?

Только на С. И в 2030 году, если доживу, буду на С писать.

Оно хоть кому нибудь нужно то что вы пишите?

А при чем тут современные очертания? были альтернативные реализации прошивки и настоящие операционные системы doors например, просто идея бейсика в ПЗУ это была не очень хорошая идея.

Зачем? Не проще закопать Си окончательно?

Комитет не хочет себя самораспускать наверное

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

Так как основные компиляторы С (gcc, clang, MSVC) являются и компиляторами С++, то ввод новых фич в С с синтаксисом С++ уменьшает работу для разработчиков компиляторов, поэтому вполне возможно что С23 будет поддерживаться компиляторами в том же 23 году

Забавно то, что трехуровневая архитектура компилятора «парсер-фронтэнд-бэкэнд» появилась именно в сишных компиляторах. По этой же причине поддержку новых стандартов реализовать во всех упомянутых компиляторах (gcc, clang, msvc) реализовать просто, но по этой же причине разница будет только в сахаре — даже близкий, казалось бы, компилятор Rust на них ты написать не сможешь.

Если полностью выкинуть Си, то это ещё сильнее упростит разработку компиляторов

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

Эдя это Йети, он в горе живет с телескопом и ящиком стм32, который туристы потеряли.

Ты говорил о языке, а не машкодах! Язык един для всех платформ!!! И если функция работает на x86_64, то она будет и на арме, и на мипсе, и на спарке, и на микроконтроллере восьмибитном работать!

fopen(«/root/filename.txt», «r»)

Удачи писать программы без ввода-вывода.

Да? И куда я это буду распаковывать? В 10кБ оперативки что ли?

В регистры процессора.

Ты, я так понимаю, не знаком с людьми, которые упаковывают 3D шутаны в win32-бинарник 64 кБ.

И распаковывают его в 128кБ?

Конкретно там распаковывают в несколько десятков МБ, но тебе до этого расти и расти. Как и мне, впрочем.

Если бы не было нужно, не писал бы. А так — как минимум тем, кто наблюдает на телескопах нужно!

В регистры процессора.

Что 2kb в регистры процессора? Туда байт 16 влезет не больше)

fopen

Я элементарно заставлю работать эту функцию, если реализую низкоуровневые. И она сможет, например, читать массив из флеша. Ты ж сам говорил, что malloc работает даже без MMU, т.е. в курсе, что любая функция glibc будет работать на МК, если написать низкоуровневые обертки (sbrk и т.п. в случае с malloc).

В регистры процессора.

А, т.е. ты вообще не в курсе, как МК работают!..

Я в своих демонах, крутящихся на телескопах, тоже «исключения» делаю: после демонизации материнский процесс делает форк и наблюдает. Как только дочерний помрет, он делает sleep(N), опять форкается и наблюдает. А дочерний в случае каких-нибудь ахтунгов пишет в лог (или не пишет, если просто аппаратура выключена), почему сдох, и самоубивается.

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

считаем AF, BC, DE, HL, IX, IY, R, I

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

PC и SP нельзя трогать

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

Z80 вестимо

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

Я был бы очень рад, если бы кто-то за меня раскопал причину, по которой комитет по разработке Ada (green language) пришел к необходимости ввода исключений в язык. Уже позже подобный прием использова Страуструп, но первым из статических языков была именно Ada. Lisp и Scheme были глубоко динамичными языками со сборкой мусора, для которых не составляло труда прыгать по выполнению.

А с каких пор мы опять к Z80 вернулись, если уже флейм о нужности С на современных компьютерах пошел?

Это что у тебя за процессор, где всего лишь 18 регистров?

PIC например. В 16 и 32 битных x86 регистров тоже не много (8).

идея бейсика в ПЗУ это была не очень хорошая идея

ПЗУ было самым эффективным хранилищем. Потому что один байт оперативы требовал 48 транзисторов.

Про laser-basic шел разговор? ну вот он и был даже на 48k, а про C я ничего не говорил. В любом случае 2 Kb данных не влезет в регистры именно процессора

В результате битность процессоров и компьютеров – это не более чем маркетинговый приём.

Вот и выросло поколение.

да тогда еще SRAM был, К565РУ5

Что не так?

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

Я с ним согласен а ты сам попробуй развести 64 провода шины данных на примитивной плате компа 1982 года, я про Spectrum.

Что 2kb в регистры процессора? Туда байт 16 влезет не больше)

Ну а как же процессор оперирует гигабайтами данных, если у него в регистрах 16 байт помещается?

Ты там про операции писал. Которые могут по нескольку тактов требовать. А что насчет AVX и подобных инструкций?

А что, мультиплексоры уже отменили?

Во первых оперирует это ты не про память? Если память то это к шине адреса а не данных.

fopen

Я элементарно заставлю работать эту функцию, если реализую низкоуровневые

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

Потактово, вестимо.

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

А что насчет AVX и подобных инструкций?

Я считаю, что битность – это размер указателей и только. По такому критерию многие 8 битные процессоры на деле оказываются 16 битными. Также 68k и Apple Macintosh 32 битный, хотя там не все биты были аппаратно реализованы, но потом реализовали не меняя машинный код.

Ты про что сейчас? Если про шину адреса то там сегментация и прочие хитрые штуки. А заче шине данных что то потактово?

Да это до сих пор используется!!! Похоже, ты просто ничего не писал под микроконтроллеры! Память ведь и на I2C бывает! А это — вообще последовательный интерфейс…

Ну а как же процессор оперирует гигабайтами данных, если у него в регистрах 16 байт помещается?

Эти гигабайты не в регистрах хранятся, в регистрах хранятся указатели на данные.

Уж лучше правда разводить эти провода на плате чем мультиплексировать а потом демультиплексировать.

*вздохнул*

память с I2C интерфейсом это уже новомодная хипстота, олдскул был только параллельным :)

Про исполнение инструкций процессором. Который не просто «взял, и захавал 2ГБ данных за 1 присест», а потактово их принимает, обрабатывает и по регистрам/кэшу распихивает…

Ну и какое это имеет отношение к теме? Это ведь и так ясно всем.

Я про одного товарища, который говорил, что можно 2кБ сжатого кода за один присест в регистры микроконтроллера развернуть!

Вот другое дело — если натравить DMA на получение данных с внешней флешки (или еще какой фигни) и распихивание их по регистрам МК. Но здесь тоже никакое сжатие не поможет.

В общем, чушь он несет.

// блин, с этими вашими праздниками я вместо того, чтобы «арканоид» под STM32 писать, сижу и пиво пью…

считаем AF, BC, DE, HL, IX, IY, R, I
20 байт, всего 20 байт можно запихнуть в регистры процессора, учитывая что регистров общего назначения два комплекта и AF тоже

Одной из важных ошибок Intel было использование слишком малого числа регистров — в основном потому, что расчет шел на операции с SRAM оперативой, скорость доступа к которой была подобна L1 кэшу. Только в x86-64 ошибка была наконец исправлена. Однако, за это время ошибку за интелем скаргокультировала куча других разрабов. Даже 8-битный AVR имеет 32 байта регистров. А при 8-битных операндах это дофига, есть где развернуться.

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

Так это не интеловский процессор а Zilog

да тогда еще SRAM был, К565РУ5

«До К565РУ3 в микросхемах динамического ОЗУ применялись трёхтранзисторные ячейки, что давало 2-кратную экономию площади кристалла по сравнению со статическим ОЗУ, где на одну ячейку требовалось 6 транзисторов. К565РУ3 была первой массовой микросхемой, использовавшей однотранзисторную ячейку.»

Одной из важных ошибок Intel было использование слишком малого числа регистров

А может быть наоборот, оптимизированный стек позволяет заменить регистры и стек более гибкий, чем прошитое намертво число регистров. По сравнению с регистрами, стек проще отлаживать (как вывести трассировку стека со значением параметров, если они переданы через регистры?) и писать под него рантаймы.