2fk0> на самом деле тут есть несколько подводных камней.

Я согласен, любое ускорение (в том числе и использование текущих средств разработки как ускорение процесса) несёт в себе отдачу по другим ресурсам - своего рода "плата" за скорость.
А теперь конкретней:

1. Внешняя память - её есть практически (!) сколько угодно
Пример: гибкие диски, жёсткий диск, компакт диск
1.а. Использование в методе модульных структур система использует эту память
1.б. Использование кернального метода не подразумевает перенос своего рода "нагрузки" на эту часть компьютера

2. Внутренняя память
Пример: ОЗУ
Спецификой является невозможность прямой адресации произвольной точки, только через страничный механизм доступа. Размер страницы - 16кб.
2.а. Модульная структура - программа занимает ровно столько сколько есть, и на строчкой больше
2.б. Каждый вызов в ОЗУ дополняется строчкой перехода по длинному адресу.

3. Релоцируемость
Понимается перенос программы уже скомпилированной в любой произвольный адрес
Пример: внутри программу переход во внутреннюю часть:
Сall Internal_label1
...
Internal_label1 ld a,1
...
Модификация метки внутри программы
ld a,5
ld (mem_label1+1)
...
mem_label ld h,0
...
3.а. Модульная система - как угодно и куда угодно - это её главный бонус
3.б. Кернальная система - не понял я как релокации настраиваются (если вообще есть такая возможность), точнее говоря я понял что это делается непросто

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


А теперь самое главное (своего рода закусь):

Те, кто писал ОСи под спекк сталкивались с проблемой нехватки ОЗУ - программа, написанная и откомпилированная не хотела занимать меньше 1ой страницы - т.е. сколько есть страница памяти - столько максимально (ну или почти столько) можно было загрузить приложений.
Это связано с тем, что трудно предсказать где должна закончиться одна программа (её код + служебные данные) и соответственно оттуда же начаться другая. Потому как правило обходились компиляцией под адрес #C000.
Т.е. если есть уже загруженная программа с адреса #c000 и длиной скажем #1AF0 то нужно чтобы следующая загружаемая п/а имела адрес компиляции #DAF0 - и никак не меньше, хотя больше адрес можно. А если в следующий раз программа будет иметь тот же стартовый адрес а длину уже #2AF0 - как быть?
В этом и кроется одна из причин возникновения т.н. динамической компиляции - неизвестно заранее куда должна быть загружена программа (базовый адрес).
Касательно систем записи программ.
Модульная система - теперь программ можно загрузить именно столько, сколько есть памяти, привязываясь к страничному принципу лишь ЧАСТИЧНО. Я думаю из указанного выше примера будет ясно почему.
Кернальный принцип - ровно там где были там и остались - т.е. на каждый процесс будет уходить по 1 странице памяти.

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

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


Цитата Сообщение от fk0
Способ N2 исключительно сложен в реализации, и требует
специальной поддержки от ассемблера, поэтому, с моей точки
зрения, в общем случае не применим и имеет смысл в каких-то
специфических случаях, например, когда исключительно критично
время вызова функции.
Я под всем подписываюсь что ты сказал, но глядя на бонусы даваемые модульной системой эти недостатки не выглядят так уж решающе.