Board.KolibriOS.org

Serge wrote:Не врубаешься.
1. Вещи, очевидные для ЯВУшников, не являются таковыми для ассемблерщиков.

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

2. Давно было высказано предположение, что Вилле собирался использовать статические адреса для взаимодействия с загружаемыми драйверами.

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

SII
Однако пишешь ядро для arm на ADA. А некоторые ассемблерщики о ЯВУ только слышали.

Serge wrote:Однако пишешь ядро для arm на ADA. А некоторые ассемблерщики о ЯВУ только слышали.

Я пишу ядро на ассемблере, Ада пойдёт только для задач (программировать восьмиэтажную математику даже на ассемблере VAX-11 -- удовольствие ниже среднего). Основная причина, почему я отказался от идеи сначала набыдлокодить ядро на Аде, а уж затем при необходимости перевести на ассемблер -- крайняя неэффективность и даже ненадёжность компилятора GCC, в состав которого входит и единственная доступная Ада.

Но речь не об этом, а о том, что мне непонятно, для чего потребовалась фиксация различных адресов в ядре системы. Поскольку внятной причины я не услышал, то дерзну предположить, что для КОС причина кроется в "тяжком наследии проклятого прошлого", ну а для МеОС -- в неопытности или безграмотности разработчика, изначально пошедшего неверным путём.

У многих чисто ассемблерщиков-самоучек отсутствует школа, которую дают ЯВУ. Структуры данных, типизация, приведение типов ? Нафиг надо ! Что хочу, то и ворочу.
Мне кажется это та ситуация, когда из-за деревьев не видно леса. Всё в машинном коде, тяжело увидеть и продумать конструкцию всей системы. Ну и неопытности с безграмотностью хватает.

Serge wrote:У многих чисто ассемблерщиков-самоучек отсутствует школа, которую дают ЯВУ. Структуры данных, типизация, приведение типов ? Нафиг надо ! Что хочу, то и ворочу.
Мне кажется это та ситуация, когда из-за деревьев не видно леса. Всё в машинном коде, тяжело увидеть и продумать конструкцию всей системы. Ну и неопытности с безграмотностью хватает.

Да, об этом я не подумал как-то... Первым, в 13 лет, у меня был Бейсик, но почти сразу, буквально месяца через 3, начал использовать ассемблер. Ну а настоящую школу начал проходить через год на СМ-4 (клон PDP-11), где впервые познакомился с Паскалем. С тех пор по возможности из ЯВУ использую только его или его производные (ту же Аду) -- ну и ассемблер, конечно, но для разных задач. Заниматься формошлёпством в Дельфях явно удобней

Можно ещё добавить психологические особенности. У меня, например, ярко выраженное стремление всё всегда разложить по полочкам, упорядочить и т.п., откуда системный подход к разработке, склонность к "бумажному" проектированию, а не к скорейшему быдлокодингу, ну и т.д. У многих же, по моим наблюдениям (никого конкретного в виду не имею!), наоборот: пришла в голову какая-то идея -- сразу бегут её реализовывать, даже не пытаясь увязать с другими компонентами, без обдумывания возможных последствий... Конечно, всего заранее не предусмотришь, но, ИМХО, всё ж надо сначала думать, а потом делать

Я начинал с бейсика и ассемеблера 8085. В институте нас два семестра учили записывать алгоритмы в читаемом транслятором Фортрана виде. Когда препод с нашей кафедры "Технология машиностроения" сказала, что в Паскале можно определять свои типы данных, первым вопросом было: - А зачем ? Вот такое программирование. В моём понимании школа - набор базовых элементов как в гимнастике или фигурном катании. У них прыжки, вращения, у нас списки, очереди, деревья, сортировки. Всё уже придумано, бери и пользуйся. Это то, что должен знать любой кодер. Следующий уровень - умение "разложить по полочкам, упорядочить и т.п.," и я не знаю где этому учат. Беда многих начинающих ассемблерщиков в том, что они не изучат эти примитивы в исходниках на Паскале и Си, и не заметят в листингах на ассмемблере.
Всё это к тому, что если бы Вилле знал о существовании двусвязных списков, планировщик и оконная система у нас были бы немного лучше.

Похоже, нигде по-настоящему не учат. Упор делается на освоение конкретного языка, его синтаксиса и т.п., а отнюдь не на понимание фундаментальных вещей. А в результате имеем низкокачественные программы и вездесущее засилие Си/Си++: чему научили, на том и программируют (а параллельно, например, считают, что я использую Паскаль и Аду, а не Си, из фанатизма или банального незнания сего языка, хотя причина абсолютно иная: паскалеподобные языки предохраняют меня от кучи идиотских случайных ошибок и в то же время нисколько не снижают гибкости, просто надо уметь ими пользоваться, а в первую очередь -- правильно задачу ставить, чтобы не было нужды, например, заниматься извращениями с указателями там, где реальной нужды в этом нет).

Вообще, еще полезно попробовать Haskell и LISP - очень большой опыт для программиста, независимо от языка. Не обязательно глубоко залезать - а попробовать, имхо, - надо.

Serge wrote:У многих чисто ассемблерщиков-самоучек отсутствует школа, которую дают ЯВУ. Структуры данных, типизация, приведение типов ? Нафиг надо ! Что хочу, то и ворочу.
Мне кажется это та ситуация, когда из-за деревьев не видно леса. Всё в машинном коде, тяжело увидеть и продумать конструкцию всей системы. Ну и неопытности с безграмотностью хватает.

А меня иногда ставит в ступор позиция программистов-профессионалов: если что-то не вписывается в Концепцию (не важно чью - Танебаума, Кернигана, Вирта, POSIX) - тем хуже для этого чего-то. Надо реализовать Концепцию любой ценой, пусть даже такой.

И давно уже даже у технарей мысли не возникает, что по сути программирование (в т.ч. системное) - это узкоприкладная техническая дисциплина, вроде хим.технологии или материаловедения. Да, лет 20-30 назад претерпела типичную постмодернистскую инверсию формы, но это не значит что она останется такой вечно. Кому ваши концепции будут нужны лет через 5, когда надо будет срочно клепать БПЛА и ФАР из любых имеющихся подручных материалов?

Как писал, кажется, Фр. Брукс-мл., если нечто не вписывается в концептуально стройную систему, то это нечто следует отбросить, а не ломать систему, даже сли само по себе это нечто заслуживает внимания. Однако если таких вещей набирается достаточно много, то надо создавать новую систему, а не держаться за старую любой ценой.

Ага давайте вместе с водой выплеснем ребенка из тазика, ну не вцепился он в края - его проблема. Вот когда трупиков накопится заметное количество - вот тогда!

Вообще есть как справедливое замечание которое Serge высказал, но зачем же становится фанатиками методов?

SII wrote:Мне вот непонятно, а почему в ядре должны быть какие-то статические адреса? Когда речь идёт о стандартном древнем оборудовании, там дело ясное: адреса жёстко заданы разработчиками железа, и с этим ничего не поделаешь.

Интересно а контроллер флопика и IDE PATA тоже можно убедить, что памяти бывает больше 16 Мб?

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

+1

В силу специфики fasm'а (непосредственной компиляции исходников ядра в бинарник) статические адреса все-таки присутствуют, но их должно быть минимальное количество - база ядра в ВАП, физический адрес загрузки файла ядра, соответствующий загрузочным стандартам, и адреса (а также размеры) уж слишком специфичных секций ядра, привязанных к определенным областям памяти (типа BDA до включения пейджинга и при идентичном отображении во время инициализации). Плюс адреса секций или отдельных, но аналогичных им по значимости, структур (например, таблицы страниц, чтобы было понятнее), которые отсчитываются от конца ВАП (если кто-то такое практикует). И то при использовании последних остается (пусть и теоретический) риск пересечения. Плюс фиксированные физические адреса для взаимодействия с определенной аппаратурой или BIOS (типа 0A0000h или 0E0000h). Про использование переменных/структур/буферов со статическими адресами для взаимодействия с загружаемыми модулями говорить не буду, потому как любому здравомыслящему должно быть понятно, что это зло.

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

Phantom-84 wrote:В силу специфики fasm'а (непосредственной компиляции исходников ядра в бинарник)

Э... А что, FASM не позволяет получать нормальные объектники, как другие трансляторы? (вариант "через анус" не предлагать: речь же о нормальной разработке, а не об извращениях).

Позволяет. Но он также позволяет делать такие бинарники, которые из объектников без дополнительных утилит и шаманства с ld-скриптами не получить, поэтому лично я предпочитаю прямую компиляцию.

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