OSDev

Ну что ж Вы меня обижаете : )
Я знаю про MASM, но есть очень мало причин в этом мире (и в обозримой нами части вселенной), которые заставят меня на нём писать. И причины эти вряд ли станут актуальными для меня в ближайшие несколько миллиардов лет.


Если только это будет Intel-syntax, а если GNU-syntax, то лучше написать свой GCC с блэкджеком и Intel-syntax.


Да, я в целом разделяю Вашу радость. Но нужны сравнения с Intel C++, на практике он давал решения, которые могли на порядок обгонять GCC, но это было давно.

[ 9 ] :: Блоки кода

Ещё одна провокационная тема.

Нужны ли нам блоки кода типа begin / end или { / }?

На самом деле я лично не вижу в них острой необходимости. Блок кода можно определить отступом, хотя это может оказаться неудобным, потому что не очень хорошо видно, в каком блоке мы находимся, если их много. Когда есть скобки или операторы begin / end, можно хотя бы посчитать или определить комментариями у закрывающих скобок, в каком блоке мы находимся. Но точно также можно и без всяких скобок написать подобные комментарии, если они потребуются.

Есть неплохие варианты, которые позволят избавиться от подобных скобок, но при условии, что мы используем не обычный текстовой редактор, – цветовое графическое выделение блоков или соединительные линии. То есть в случае цветового выделения фон каждого блока, находящегося внутри другого, можно сделать чуть темнее. Либо оформить код так, как это предлагается в некоторых псевдоязыках:



Может возникнуть ещё одна трудность. Например, в языке C++ я нередко объявляю блоки кода подряд друг за другом для выделения смысла:



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



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



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

Распечатывать разноцветный листинг (пусть даже только с оттенками серого) тоже не вполне удобно, поэтому можно листинги делать на обычном белом фоне. Лично у меня не было случаев, чтобы нагромождение скобок {} в листинге делало код более понятным, чем если бы их не было, а когда блоков немного, то всё и так видно. Либо это был ужасно оформленный код, написанный без всякой культуры пьяным индусом, например, когда всё пишется одним большим куском строк так в две-три тысячи (при условии, что программу не генерирует другая программа).

Есть ли более серьёзные трудности, которые я проморгал?

[ Продолжение следует ]

+100500

Есть параметр gcc -masm=intel
Единственно, что могут возникнуть ошибки компиляции при использовании сторонних библиотек, где используется синтаксис att.

Вот Intel C++ у меня нет. Если появится - посмотрим.

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

В блоках могут объявляться локальные переменные -- иногда это удобно.

А вообще, для условных операторов и циклов я предпочитаю Адский синтаксис:



С одной стороны, нет бесконечных begin-end (или, что для меня ещё хуже, { } -- в отличие от begin-end, скобки сливаются с общей массой символов и не всегда мною замечаются адекватно; это же относится и к другим спецсимволам, коими изобилует Си/Си++), с другой -- чётко виден конец оператора, причём сразу видно, что именно за оператор закончился (if, а не case или loop).

Что же касается разноцветного синтаксиса и прочая, то это -- не выход. На экране компутера мы действительно можем получить такую картинку (и это, в общем-то, неплохо, если сделано разумно) -- однако при распечатке на бумаге цвет, как правило, теряется. Однако анализировать логику работы программы по крайней мере некоторым людям (мне) обычно удобней не с экрана, а по распечаткам. (Вообще, как по мне, неумение многих работать "с карандашом и бумагой" является одной из основных современных бед -- вместо того, чтобы спокойно подумать над задачей, набросать её решение, проанализировать тонкие места и т.д., сразу бегут кодировать).

Вот какой язык всем нужен: http://www.utro.ru/news/2014/12/09/1225137.shtml

Да, байт потерял, пардон. Это должно работать на принципах элементарной оптимизации. Если компилятор видит использование старших значащих разрядов (а после сложения этот разряд хранится в переносе, это компилятор обязан знать), он их просто использует в следующей операции. Компилятор в любом случае помнит, где хранятся данные и результаты операций, - в регистрах, на стеке или, в данном случае, в битовых флагах. Вы ведь не указываете компилятору для 32-битной машины, по инструкциям (включая ADD/ADC) как работать с 64-битными числами, компилятор это без труда делает софтовым способом, ничего не теряя.


Так ведь ТеХ использует plain-text в основе! Это и есть отказ от визуального представления в пользу текста. Визуальное представление получается в результате (условно говоря) компиляции текста в графическое представление.


Нет, не то же самое. Я предлагаю не избавиться, а пока не пользоваться. Иначе говоря, не влезать на стремянку, пока она шатается. Когда будет ясно, что стремянка не упадёт, ей можно будет безопасно пользоваться.


Именно так делает Python. Но здесь есть своя засада - символ табуляции! Вообще говоря, ещё в эпоху электромеханических печатных машин, используемых в качестве устройств вывода, позиции табуляции не были фиксированными. В ранних терминалах они также настраивались. Потом свистопляска немного утряслась и все более-менее сошлись на 8 символах. Последние лет *дцать в интерактивных средах и текстовых редакторах свистопляска опять вернулась и часто табуляцию используют в качестве обозначения одного уровня вложенности, - обычно 2 или 4 символа. Вопрос - как быть с символами табуляции? Вообще говоря, их изначально надо было запретить (т.е. вообще не вводить в коды ASCII, как и вертикальную табуляцию и многие другие вредоносные управляющие коды), но что есть, то есть. Я полагаю, что сейчас хорошего ответа на этот вопрос быть не может. А пока так, то и блоки нужны. Но я согласен, что при отсутствии табуляции обозначение уровня вложенности могло бы определяться отступами.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Какие у неё ограничения?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Мне что-то не нравится, но я пока не могу понять, что именно. Могли бы Вы написать оператор сложения полностью правильно для int72 (на любом языке, который можно понять без лишних пояснений)? При этом, если Вы пользуетесь int128 для промежуточных результатов, то нужно описать и его.


Совершенно верно, однако есть визивиг (wysiwyg) редакторы для TeX, которые оставляют скрытым plain-text, лежащий в основе. (К сожалению, все известные мне визивиги для TeX обладают той формой школоподобия, при которой работать с ними (лично мне) неприятно). Над тем же думал и я, когда писал про внутренний и внешний форматы. Внутренний формат используется компилятором, а внешний - это визуальное отображение внутреннего. При этом будет ли это плагин к редактору, как предлагалось выше, либо что-то другое, сейчас это не важно. Пользователь может писать как на внутреннем формате, так и на внешнем. Оба формата следует продумать удобными. Я вообще подозреваю, что TeX такой именно потому, что раньше, в те времена, были только текстовые редакторы. Мыслить о быстрой и удобной графике никто особо не смел.


Вы не ответили на мой вопрос о том, какие по-Вашему символы в UTF-8 следует считать устоявшимися. Или вопрос некорректен?


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


Я предлагаю запретить символ табуляции и назначить на эту кнопку что-то другое в моём редакторе, а ещё считать данный символ синтаксической ошибкой. Ведь, например, в C++ многие символы будут синтаксической ошибкой, и если в новом языке добавить в этот список tab, то ничего по сути не изменится. Просто 9-й символ будет восприниматься таким же запрещённым, как, например, 31-й. В моём редакторе я бы даже сделал так, что tab раскрывается в ёмкое ругательное выражение большими красными буквами. Причём при каждом нажатии выдаются разные фразы : ) Я отказываюсь проверять программы своих учеников, если при открытии их в моём редакторе я вижу хоть одно неправильное выравнивание (неправильное - это не то же самое, что "не как у меня", это когда в одной программе отступы разные, не поддающиеся единому стилю оформления или какой-то другой простой логике, это почти всегда происходит, когда ученик использует tab). Я просто возвращаю программу на доработку. Ибо нефиг. И здесь я совершенно радикально настроен против табуляции как способа выравнивания кода, если есть хоть один шанс перепутать её с пробелами (если такой шанс есть, он обязательно выпадает). Сам я нажимаю tab регулярно, но мои редакторы всегда превращают его в нужное число пробелов без каких-либо вариантов, этот символ остался только в моих старых программах, когда я ещё был полон иллюзий и оптимизма. Единственное исключение - makefile, но там и перепутать нельзя, не скомпилируется.


Можно альтернативный вариант: во внутреннем plain-формате скобки для блоков кода есть, а во внешнем формате их нет. При этом в качестве скобок для внутреннего формата брать не именно скобки, а что-то типа __begin__ / __end__ или то, о чём пишет SII (if / end if ).

Я, кстати, вообще против ключевых слов, но об этом позже.