Программирование на УКНЦ как?

[Hunta]

Это и есть низ блока переменных в описываемом случае (он же - верх программы):

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

[form]

это ещё надо вычислить

Вычислять тут ничего не надо - мы на этапе трансляции знаем адрес начала и адрес конца, и они фиксированные.

[Hunta]

В моём случае - MOV #BUF, R0
В твоём случае - MOV .LIMIT+2, R0 ADD #BUF, R0 (SUB .LIMIT, R0 ADD #BUF, R0)
Вот даже не скажу сходу, как вычислить адреса буфера, который где то внутри блока

[form]

В моём случае - MOV #BUF, R0
В твоём случае - MOV .LIMIT, R0 ADD #BUF, R0

Абсолютно неверно.

Рассмотрим два случая.
Единственный (есть конечно и другие способы, но в данном случае нам интересна сама суть - возможность использования #BUF) случай когда можно обойтись одним "MOV #BUF,R0" - это когда мы уверены что "BUF:" перед .END - окажется в конце программы. Но тогда "мой" случай сводится к тому же самому и .LIMIT не нужен в принципе.

Второй случай - когда мы используем библиотеки, кучу модулей итд, и "BUF:" перед .END может и не быть концом программы. Описываемый вариант предназначен именно для этого случая, и тут нам нужно уже MOV LIMIT+2,R0 и TST (R0)+ (а не мифический ADD #BUF). Но и "канонический" вариант с .SETTOP тут сводится к тому же самому - мы получаем адрес верха программы из @#50 (до расширения) и так же должны добавить к нему 2.

Иными словами, .LIMIT здесь выполняет роль чтения @#50 в момент старта программы, только результат готов еще до ее запуска.

[Hunta]

Второй случай - когда мы используем библиотеки, кучу модулей итд, и "BUF:" перед .END может и не быть концом программы.

В моём случае он ГАРАНТИРОВАННО будет в конце за пределами программы, но внутри блока, который будет распределён вызовом .SETTOP внутри п/п инициализации, которая ещё и отдаст свою память в этот блок. Как я и сказал - ВСЁ адреса этого блока будут известны на момент компиляции, но при этом пространство для него не будет выделятся в .SAV и вообще не будет трогаться ячейка 50

- - - Добавлено - - -

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

[form]

ГАРАНТИРОВАННО будет в конце за пределами программы, но внутри блока, который будет распределён вызовом

Это точно так же легко делается с использованием правки 50 через .ASECT.
Напомню, речь идет не о том как ЛУЧШЕ сделать, а о самой возможности.
Сам я использую .SETTOP и @#50 как самый универсальный и подконтрольный способ, тем более, что ULBLIB предоставляет достаточно удобный набор для работы с памятью.

[Advertiser]

[Hunta]

Это точно так же легко делается с использованием правки 50 через .ASECT.

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

Сам я использую .SETTOP и @#50 как самый универсальный и подконтрольный способ, тем более, что ULBLIB предоставляет достаточно удобный набор для работы с памятью.

Мне понадобился простой и удобный способ выделения места под impure переменные, так что бы не возиться вообще с динамической памятью, не занимать места в .sav файле и не проводить вообще никаких вычислений - то есть, что бы ВСЕ адреса переменных были известны в момент компиляции. По ссылке, которую я привёл - мой ответ на ответ, что это вообще не возможно в RT.

Тебя устраивает твой - да ради бога - я никому ничего не навязываю.

- - - Добавлено - - -

На этом на эту тему писать больше не буду. Можно мне не отвечать.

[Manwe]

Я обычно в конце программы ставлю метку FREE: (подразумевая свободную память с этого адреса) непосредственно перед директивой .END
А в начале программы задаю переменные (указатели на буферы для временных вычислений) типа таких:
BUF1 = FREE
BUF2 = BUF1 + 256 ; размер первого буфера
BUF3 = BUF2 + 1230 ; размер второго буфера
FREEND = BUF3 + 542 ; размер третьего буфера.
В самой программе пишу MOV #BUF1,R0 или MOV BUF2(R1),R2 или что угодно в таком духе.
Остаётся только после компиляции в .sav-файл как-то вписать значение FREEND в 50-ю ячейку этого sav-файла.

[form]

Я обычно в конце программы ставлю метку FREE: (подразумевая свободную память с этого адреса) непосредственно перед директивой .END

Такой способ не всегда годится.

[litwr]

Предполaгаю, что работа с памятью в RT-11SJ как в Досе - получай всю. Хотя неуверен, на БК11 работает какой-то своппинг. А библиотеки сверху кода никакой в этом случае нет. С ХМ монитором это не так, но этого нет на БК и УКНЦ. На системе без виртуальной памяти возможно, что никаких действий и не нужно, но не уверен. Это получился вопрос.
Пользуюсь случаем обратиться к уважаемому form. Меня швед BQT просто достал, более 4-х месяцев доказывал, что данные, которые вы мне сообщили по π-затвору на 11/83 неверные, так как они лучше, чем от его 11/93. Объяснял ему, что это из-за того, что RT-11SJ быстрее RSX-11 и 2.11BSD, но он не верил. А RT-11 он не любит и ставить не хочет. Нет ли у вас сейчас какой-нибудь DEC PDP-11 системы с RT-11, чтобы данными оттуда помочь мне его убедить? У шведа есть довольно сильный аргумент, так как алгоритм несколько раз слегка разгонялся и мне приходилось ваши данные согласовывать с новыми кодами. И он настаивает, что в таких согласованиях невозможно быть 100% точным и в этом он прав. Считаю, что погрешность в процентов 10 вполне могла случится. И хотя 11/93 получается, в любом случае, медленнее, шведа это не убеждает. Он предполагает, что возможна и большая погрешность. Помогите, если возможно.