LINUX.ORG.RU
ФорумTalks

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

 , , , ,


3

4

Ъ: https://habr.com/company/badoo/blog/420407/

!Ъ: C — это на самом деле такой высокоуровневый ассемблер для PDP-11. А из современной пеки или арма такой PDP-11, как из Iron_Bug — японская школьница. Отчего величина ускоряющих костылей в компиляторах C перерасла мыслимые и немыслимые пределы, лишь бы оставить сишникам ощущение штабильности и низкоуровневости. (Тема стопицот раз перетиралась на ЛОРе, хз, зачем я это ваще притащил). А вы тут Rust хаете, в котором векторизация во все поля. В плюсах, впрочем, тоже, так что Rust не нужен.

И сразу же 4.2. Почему - читай комментарии.

devl547 ★★★★★ ()

Низкоуровневость — понятие относительное, можно считать любой пользовательский код высокоуровневым, поскольку он крутится в user-mode контексте операционной системы. Но в сравнении с виртуальными машинами Java/.NET слоёв абстракции значительно меньше, поэтому такой код будет низкоуровневым. В сравнении и никак иначе.

Sadler ★★★ ()

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

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

FilosofeM ★★ ()
Последнее исправление: FilosofeM (всего исправлений: 1)

Если вы заполните эту структуру нулями и потом укажете значение некоторым полям, будут ли в битах выравнивания нули? Согласно результатам опроса, 36% были уверены, что будут, а 29% опрошенных не знали ответа. В зависимости от компилятора и уровня оптимизации это может быть правдой (или нет).

Это довольно тривиальный пример, однако многие программисты или дают неправильный ответ, или не могут ответить вовсе.

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

lenin386 ★★★ ()
Ответ на: комментарий от lenin386

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

Дав категоричный ответ. Например: Всегда да или всегда нет.

atrus ★★★★★ ()

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

this. Сишка, на которой пишут «железячники» уже второй десяток лет почти никакого отношения к аппаратной части не имеет :)

Deleted ()
Ответ на: комментарий от FilosofeM

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

Нет, человек дело говорит. Если учесть, что современный x86 давно уже внутри risc, динамически перекомпилирующий старый cisc-код, переставляющий местами инструкии и т.д., то все они, включая ассемблер - высокоуровневые. Последствия самые разные. Например, я не представляю, как теперь на x86 можно реализовать жёсткий real-time, ведь с конвейером уже нельзя быть точно уверенным сколько будет выполнятся тот или иной код, рассчитывать такты бессмысленно.

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

atrus ★★★★★ ()
Ответ на: комментарий от atrus

Если учесть, что современный x86 давно уже внутри risc

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

Например, я не представляю, как теперь на x86 можно реализовать жёсткий real-time, ведь с конвейером уже нельзя быть точно уверенным сколько будет выполнятся тот или иной код, рассчитывать такты бессмысленно.

А какое отношение рассчёт тактов имеет к риалтайму, товарищ. Риалтайм - это прогнозируемое время _реакции на событие. Считать такты, кстати, было бесполезно ещё со времён 386-го процессора, у которого появился кеш. Вообще, это ублюдочное занятие - забава, которую применяли в Apple II. Там просто никак иначе. Никакой возможности контроля времени, кроме этих тактов.

lenin386 ★★★ ()
Последнее исправление: lenin386 (всего исправлений: 5)

Да, собственно, и ассемблер - представление более высокого уровня. Линус Торвальдс, вон, когда ещё не знал про ассемблер прямо в машинных кодах писал.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

Товарищ, я знаю эти грибы. Это не очень хорошие грибы.

lenin386 ★★★ ()

Давно уже говорю в пустоту, надо либо архитектуры процессоров менять либо (что гораздо сложнее и хуже) делать языки под то нагромождение костылей что сейчас имеем в железе. Нынешний путь развития ЯП и компиляторов есть путь в никуда. Точнее в куда — в объятия вебмакак с их webassembly.

Deleted ()
Ответ на: комментарий от atrus

Как можно дать неправильный ответ
Дав категоричный ответ. Например: Всегда да или всегда нет.

у меня есть домашний мем: «всегда да, но иногда нет», который появился после моего «консалтинга» в Казани.
довольно категоричный ответ.

system-root ★★★★ ()
Ответ на: комментарий от saahriktu

…прямо в машинных кодах писал.

Не стоит так делать, господа, ведь от вас потом ФСКН не отстанет.

Guest_1488 ()
Ответ на: комментарий от Deleted

Вот у сишников бомбанёт-то, если после обрастания теми костылями, коие сейчас имеют компиляторы C, WA станет работать быстрее C.

bodqhrohro_promo ()
Ответ на: комментарий от lenin386

Заливаешь в проц кастомный микрокод, пытаясь его не окирпичить во время разработки микрокода => профит. Полной гибкости это, конечно, не даст, но хоть что-то.

bodqhrohro_promo ()
Ответ на: комментарий от lenin386

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

И то. Из байт-кода Java вы до машкода целевой платформы тоже законными способами не доберётесь.

А какое отношение рассчёт тактов имеет к риалтайму, товарищ.

А такое, что при вызове функции заполненность конвейера, состояние предсказателя переходов и кэша могут изменить конкретное выполнение текущего вызова функции на порядок по сравнению с другим. (Из-за ошибки предсказателя придётся чистить конвейер, потом пара промахов до L3 и привет.)

ещё со времён 386-го процессора, у которого появился кеш

Кэш появился только в 486.

atrus ★★★★★ ()
Ответ на: комментарий от bodqhrohro_promo

Заливаешь в проц кастомный микрокод, пытаясь его не окирпичить во время разработки микрокода => профит.

Это так не работает*.

*Если у вас не чип от Transmeta.

atrus ★★★★★ ()

Кто о чем, о школьник о школьницах.

madcore ★★★★★ ()

man CPU Opcodes

все получится.

sqq ()
Ответ на: комментарий от saahriktu

А как-то раз мы на лабе тумберами выставляли значения ячеек. Не всем нужны машинные коды новомодные!

Shaman007 ★★★★★ ()
Ответ на: комментарий от Shaman007

Но мог бы их выставить, если бы не знал языка ассемблера ?

lenin386 ★★★ ()
Ответ на: комментарий от atrus

Из байт-кода Java вы до машкода целевой платформы тоже законными способами не доберётесь.

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

cvs-255 ★★★★★ ()
Ответ на: комментарий от lenin386

Я его и не знаю. Там была ЭВМ системы «мечта saahriktu»: 8 регистров памяти по 1 байту, индикация диодами, управление тумблерами. Положил положил операнды, положил операцию, нажал кнопку - получил значение!

Shaman007 ★★★★★ ()
Последнее исправление: Shaman007 (всего исправлений: 3)
Ответ на: комментарий от Shaman007

Положил положил операнды, положил операцию, нажал кнопку - получил значение!

Это и есть язык ассемблера. А мнемоник может быть несколько даже для одного процессора.

lenin386 ★★★ ()
Последнее исправление: lenin386 (всего исправлений: 3)
Ответ на: комментарий от Shaman007

это и есть машинные коды, просто варианты ввода разные могут быть

Harald ★★★★★ ()
Ответ на: комментарий от Shaman007

положил операцию

а операцию-то откуда брал, из таблички небось? Вот в ней и были машинные коды :)

Harald ★★★★★ ()
Ответ на: комментарий от Harald

Кмк, несколько слишком широкая трактовка, но пусть будет.

Shaman007 ★★★★★ ()
Ответ на: комментарий от Shaman007

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

Harald ★★★★★ ()
Ответ на: комментарий от Shaman007

ну дак каждый тумблер - единичка или нолик, нативное представление данных в системе, машиннее некуда

Harald ★★★★★ ()
Ответ на: комментарий от Harald

Думаю что скорее из лени: в идеальном мире должна была быть лабораторка «собери эту хреновину», а на соседней кафедре «слабай ей кристалл» (все оборудование было).

Shaman007 ★★★★★ ()
Последнее исправление: Shaman007 (всего исправлений: 1)
Ответ на: комментарий от Shaman007

у тебя наверняка тумблеры параллельно были, можно было сразу целый регистр нащёлкать, а вот тут одной кнопкой последовательно бит за битом прошивку набивать предлагают :)

https://habr.com/post/152052/

Harald ★★★★★ ()
Последнее исправление: Harald (всего исправлений: 1)
Ответ на: комментарий от lenin386

Это и есть язык ассемблера. А мнемоник может быть несколько даже для одного процессора.

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

vodz ★★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

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

lenin386 ★★★ ()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от lenin386

не зная языка ассемблера.

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

vodz ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)