C не низкоуровневый

Ну, так они и не выполняли фунции составления этой программы, они ещё просто загружали.

они ещё просто загружали.

Они выполняли свою работу, как и пульт, который не обязательно задавал операнд и данные, мог просто быть набором бит без нажатия кнопки ввода. В зависимости от выполняемой программы это могло означать — с какого дивайса грузиться, какие флаги при старте и в какое состояние перейти сейчас. И ассемблер тут мог рядом не лежать вообще, ибо если ПЗУ исправно, то пульт использовался для вот того что выше. У нас была неисправно, но даже там требовалось всего 4 команды по шпаргалке.

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

И ч0 ? Да этого risc добраться-то всё равно кроме как через команды x86 нельзя.

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

Я не силён в английском, но может что-то об этом написано в документации к IA-64/32?

Какая нахрен разница, если на нем можно писать код?

Зависит от того, у кого какие требования, очевидно же.

Зависит от того, у кого какие требования, очевидно же.

От того, можно ли его называть X, а не Y, меняется область применимости языка? Вау.

Кто-то прочитал статью и прикинул общую картину чем оно реально является. Ты зафиксировался на том, как его называть.

С — не низкоуровневый язык
https://queue.acm.org/detail.cfm?id=3212479
Разработка веб-сайтов,

Перевод

that's just another way of saying that C doesn't map to modern hardware very well.
это просто ещё один способ сказать, что C не подходит для современного аппаратного обеспечения.

Мареколог из шараги веб-макак решил поделиться домашкой по английскому?

Так и есть. По ссылке — перевод статьи с ACM.

На LtU, кстати, комменты к статье будут поинтересней швабра.

http://lambda-the-ultimate.org/node/5534

Разница в том, что из-за стремления разработчиков процессоров делать более быстрый PDP-11 для более быстрой работы сишного кода мы имеем все эти Meltdown и прочие лулзы.

Какой-то бред, автор катит бочку на Си, но все его аргументы, что это из-за него процессоры такие омельдоненные можно отнести и к любому другому обычному императивному языку, транслируемому в нативный код x86-го процессора (и не только x86).

То есть и к ассемблеру и к Паскалю и Фортрану и тому же Rust, D, Ada, что там вообще есть.

Разница в том, что из-за стремления разработчиков процессоров делать более быстрый PDP-11 для более быстрой работы сишного кода

А почему не паскалевского кода? Не фортрановского?

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

Потому что Фортран является чуть более высокоуровневым языком чем C и не завязан на строго определённую модель памяти.

С высоты «птичьего полёта» там мелкие отличия.

Если уж говорить про Си и модель памяти, то я должен признаться как-то так вышло, что постоянно не очень уверенно чувствую себя с указателями в Си, особенно в сочетании с массивами. Вот вроде и понимаю, а вроде и не твёрдо. Что-то тут не доделано.

К примеру, в Паскале (в совремённом) с ними всё очень чётко. Есть тип указатель, есть сами указатели, есть получение адреса, есть разыменование, есть приведение одних типов к другим. Есть даже арифметика указателей, правда в отличие от Си с громоздкой записью через приведения типов.

В Си тоже стоило бы не одной звездочкой * обходиться, а придумать разные символы для определения указателя и для получения значения в памяти, на которое указывает указатель. В том числе в случаях LValue.

С высоты «птичьего полёта» там мелкие отличия.

Я не знаю, какой у тебя там птичий полёт, но различия весьма существенные. Для начала, в Фортране работа с массивами и строками не основана на жонглировании указателями, из-за чего её гораздо проще оптимизировать. Именно поэтому в Фортране поддержка SIMD появилась гораздо быстрее и работает предсказуемее (ссылок не будет). В C же чтобы использовать SIMD для работы с массивом, компилятор должен понять, что вот этот вот цикл for(...) — это именно работа с массивом, а не просто увеличение счётчика. С идиомами типа while(*p++) {...} аналогично.

в Паскале (в совремённом)

Современный Паскаль — это оксюморон, нет?

В Си тоже стоило бы не одной звездочкой * обходиться, а придумать разные символы для определения указателя и для получения значения в памяти, на которое указывает указатель. В том числе в случаях LValue.

Синтаксис C — это одна из наименьших проблем с ним. Я тут ещё раз повторю про плоскую модель памяти. В современных системах память даже близко не плоская, но ради C это приходится эмулировать в железе.

Особенно с учетом того, что запускаться байт-код может на произвольной архитектуре, а не только x86

Не на любой, а на той, где реализован runtime. Равно как и x86-код может быть запущен на x86-совместимом процессоре любого производителя (даже если их risc(и не только risc!)-микроинструкции и не совпадают).

Современный Паскаль — это оксюморон, нет?

Нет.

IA-64/32?

Кстати, там документация по "Intel 64 and IA-32". IA-64 — это Itanium и оно не взлетело. Просто Intel гордый и не напишет "AMD64" (как следовало бы)

Для начала, в Фортране работа с массивами и строками не основана на жонглировании указателями, из-за чего её гораздо проще оптимизировать.

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

Но в целом Си намного менее строгий, чем Фортран и поэтому компилятору без дополнительных подсказок труднее решить с какой абстракцией идёт работа.

Но в этом смысле, наверное Ada должна быть ещё удобнее фортрана для оптимизаций SIMD.

Современный Паскаль — это оксюморон, нет?

Паскалю не так, как Си повезло со стандартизациями. Но есть классический «виртовский» паскаль, который уж точно не совремённый и мало на что сейчас годен. И есть паскаль в варианте Turbo-, Delphi или FreePascal (есть и другие), это я и имел ввиду под совремённым.

Я тут ещё раз повторю про плоскую модель памяти. В современных системах память даже близко не плоская, но ради C это приходится эмулировать в железе.

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

В принципе и в Си можно попробовать обойтись при работе с ними без явных применений указателей.

Каким же, интересно, образом?

Но в целом Си намного менее строгий, чем Фортран и поэтому компилятору без дополнительных подсказок труднее решить с какой абстракцией идёт работа.

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

И для Си и для фортрана - память плоская. Даже более того, я затрудняюсь сходу назвать язык, где бы она не была плоской.

Большинству языков плевать, потому как они не завязаны так сильно на указатели.

И для Си и для фортрана - память плоская.

как насчет x86 в real mode, с его сегмент:смещение?

Ты точно сразу назовешь, куда будет записан 'a' в данном коде?

char *p = (char*)0x10000000UL;
p[0x10000UL] = 'a';

хз, зачем я это ваще притащил

Моя первая мысль когда увидел этот пост.

Хе-хе. Я смотрю, DR 260 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm) стал популярен.

Желающие могут заценить https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 и особенно первый ответ на багрепорт (и вообще все ответы от жозефа)

А есть ли отличия AMD64 от Intel 64, кроме названия?

и к Паскалю и Фортрану и тому же Rust, D, Ada

безусловно

что там вообще есть

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

ассемблеру

в меньшей степени: команды ассемблера превращаются в хз что 1 раз - внутри процессора, а код на С - дважды: первый раз - на этапе компиляции, во время трансляции кода в асм, второй раз - тоже самое, что у ассемблера

Каким же, интересно, образом?

В принципе, разве что в объявлениях функций не удастся обойтись, чтобы передавать массивы, а так можно в принципе пытаться без указателей работать с ними. Конечно, это сократит возможности.

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

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

как насчет x86 в real mode, с его сегмент:смещение?

Это страшный сон тех, кто еще застал такое программирование :)

Но в принципе, память-то и там плоская, просто адресация сделана в виде сегмент:смещение.

Ты точно сразу назовешь, куда будет записан 'a' в данном коде?

В терминах сегмент:смещение можно по-разному записать эту адресацию, но место в физической памяти (а в real mode другой нет) будет однозначное.

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

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

в меньшей степени: команды ассемблера превращаются в хз что 1 раз - внутри процессора, а код на С - дважды: первый раз - на этапе компиляции, во время трансляции кода в асм, второй раз - тоже самое, что у ассемблера

В этом смысле да, но возвращаясь к теме, что из совремённых CPU сделали быстрый PDP-11 ради Си, я не пойму почему именно о Си автор столько говорит.

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

Разница в том, что из-за стремления разработчиков процессоров делать более быстрый PDP-11 для более быстрой работы сишного кода мы имеем все эти Meltdown и прочие лулзы.

Шото яне заметил особого Metldown в AMD. Есть мнение, что дело в том, что процесс тестирования в Intel просто сделан через жопу.

Конечно, это сократит возможности.

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

А есть ли отличия AMD64 от Intel 64

Насколько я знаю (и как написано в википедии) — они одно и то же.

UPD А нет, есть разница: https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64

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

PS. Rust нужен и он похоронит ублюдочный уродливый Цепепе

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

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

Такое можно дома на коленке собрать из логических элементов.

Вряд ли, оно на столе лежало и размером чуть меньше обычного ATX системника было, с КР580ИК80 унутре вроде бы

на логических элементах размер будет не меньше шкафа

я не пойму почему именно о Си автор столько говорит

Потому, что есть тенденция именно С называть низкоуровневым языком, волшебным образом более нативным, чем все остальные. Фанаты С думают, что он чем-то лучше, чем паскаль, фортран, D, раст и даже С++ (лол). Последний вообще является надмножеством С.

Хотя на деле, все преимущества С-шечки сводятся к наличию приличных оптимизирующих компиляторов. И то не перед С++.

До сих пор ситемная разработка как правило ведётся на чистом С. Именно из-за таких вот заблуждений.

C позволяет напрямую работать с ресурсами, предоставляемыми железом, и это основной способ работы с ресурсами в C

1) Не со всеми

2) чем тогда жаба не низкоуровневый язык? https://en.wikipedia.org/wiki/GNU_Compiler_for_Java Хоть уработайся напрямую с ресурсами, предоставляемыми железом

Кек, я в майнтесте пытался такое делать. Причём даже без мезеконсовых логических элементов, на гравии и пистонах. Засыпаешь сверху одно число, выбираешь операцию, засыпаешь другое, получаешь результат и спускаешься вниз его смотреть. Хватило только на AND/OR; пробовал усложнять машину, но оказалось, что липкие пистоны гармошкой не складываются:( Думал допилить мод, но забил, так та машина и стоит разобранная.

Пруфлинк

Относительно асма - не низкоуровневый.

Особо не отличается. Я с асма начинал программистский путь и несколько лет исключительно на нём писал. Потом на сишечку перешёл. Во времена борланд и турбо си, где вставки на асме можно было прям в теле сишного кода шлёпать, не заморачиваясь с watcom-like аннотацией, коя и в gcc присутствует, было вообще вольготно. Код полуассемблерный всегда был. Но там и оптимизаций конпелятор таких не делал, как gcc где-то после 4.4.

Толковый сишник на ассемблер достаточно быстро переходит, что указывает на принципиальное родство концепций.

си это не ассемблер вообще

Зашёл на сервер, проверил — эта часть машинки на месте, я тогда только корпус чуть разобрал. Но не фунциклирует, потому что то ли в майнтесте физику сыпучих объектов поменяли, то ли мод окончательно доломали :\ когда пистон вылезает из-под гравия — гравий не падает, пока его не трогать. Наверное, это изменение ради висячих пластов гравия в пещерах, чтобы они не падали внезапно на голову. Пойду искать виноватых.

Ещё лет в первых альфах кубача делали на редстоуне
https://www.youtube.com/watch?v=LGkkyKZVzug

Да, но там логика электронная, так неинтересно; я хотел без контроллеров и логических элементов сделать, в идеале полностью механический. Но механики нету, так что сделал на пистонах. И то, когда начал делать регистры, реализация упёрлась в то, что они после растягивания гармошкой не складываются обратно. Тогда забил, щяс глянул — енти пистоны уже переписать успели несколько раз, а проблема не ушла: насколько я понял — оно специально так сделано, чтобы головка не отрывалась от пистона, надо основательно допиливать мод, короче.