GCC 11.2.1 с поддержкой процессоров 1801вм1 и 1801вм2

[yu.zxpk]

за 0x2000 - не скажу, не понимаю, о чем речь.

Вот свежий вариант LD скрипт для SAV файла:
https://github.com/yshestakov/pdp11-...c/pdp11-sav.ld

В нем в 1й блок файла (512байт) сделан в виде savhdr.o файла. То есть структура заголовка SAV описана в savhdr.s.
В частности, это позволяет в адрес 050 (Program’s high limit) внести адрес метки `.end` -- где конец программы с данными

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

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

Вы в этом точно уверены? Мне так не показалось. По-моему, GCC для PDP-11 вообще не использует секцию .bss

Нет, уже не уверен. Смотрю в файл hello.out.map, вижу секция .bss есть, но не инициализированная переменная, или инициализированная 0-лем попадает в секцию data.

Надо разбираться. Я за год+ все забыл.

Судя по всему, `pdp11-sav.ld` -- не рабочий. Я пользую pdp11-aout.ld скрипт + lda2sav программу для преобразования LDA->SAV.

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

При `ALIGN(040)` не работает rt11_print() и puts() функции. При `ALIGN(0100)` -- все работает. Почему так? Не помню. Надо разбираться, опять таки.
размер всей программы hello минус 512 байт заголовка == 384 байта. При этом на ALIGN между секциями фактически ушло 100 байт. Много ли это или мало?

[Advertiser]

[Oleg N. Cher]

100 байт это не так много конечно, но наверное стандарты RT-11 этого требуют. Других объяснений почему могут не работать функции rt11_print() и puts() - у меня нет.

Итак, я беру Ваш pdp11-sav.ld и сырой бинарь после pdp11-aout-ld.exe (в скрипте же уже выбран формат OUTPUT_FORMAT("binary") вместо "a.out-pdp11" как было раньше). Попутно появилась мысль не вызывать pdp11-aout-objcopy.exe для конвертации a.out в bin вообще. Но не тут-то было. Бинарь pdp11-aout-ld.exe даёт, но настраивает его с нашим скриптом крайне криво - при заданном стартовом адресе 01000 (для БК-0010/0011М) адрес константного массива находится _ниже_ адреса кода. Вот сейчас отладчик показывает адрес константного массива 0424, т.е. константный массив размещён _после_ кода, а адрес настроен как будто бы он находится _до_ кода. Притом увеличение этого числа ничего не даёт:

.data : AT(phys + data + 1000)

Я вынужден опять откатиться до формата a.out и вызова objcopy - так хотя бы криво, но работало. А бинарь после aout-ld со съехавшими адресами массивов вообще нерабочий. Повторюсь, что в случае вызова lda2sav этой проблемы наверное нет.

Кстати, может быть, что константные массивы ложатся в секцию (или подсекцию? как это правильно?) .rodata, а не .bss?

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

Я воспроизвёл проблему на маленьком исходнике:

Test.zip

Как видим, здесь адрес массива равен 016, а должен быть больше 01000.

Я склоняюсь к тому, что проблема есть и в .sav, просто Вы не дошли до работы с конст. массивами.



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

Кстати, здесь и адрес данных получился странный, наложился на последнюю команду в коде. Видите? Хотя ALIGN(010) в скрипте есть.

[yu.zxpk]

Да, с LD скриптом проблема: при малом ALIGN (<0100) у меня портится строка, которая выводится. Починю - маякну

[Oleg N. Cher]

Спасибо.
Смотрите как я генерю рабочий бинарь с правильными смещениями (это может помочь. Наверное):

OUTPUT_FORMAT("a.out-pdp11")
ENTRY(start)
phys = 00001000;
SECTIONS
{
    .text phys : AT(phys)
    {
        code = .;
        *(.text)
        *(.rodata)
        . = ALIGN(phys);
        *(.data);
    }
}

.bss убираю вообще, а .data подпихиваю в .text

Теперь так:

pdp11-aout-ld.exe -T %PdpDev%\Bin\pdp11-bin.ld %PdpDev%\Lib\crt0.o %1.o %Modules% %Libraries% -o %1.out
IF errorlevel 1 PAUSE
pdp11-aout-objcopy.exe --output-target binary %1.out ..\%1.bin
IF errorlevel 1 PAUSE
%PdpDev%\Bin\make-bk.exe ..\%1 512
IF errorlevel 1 PAUSE

Здесь всё хорошо, кроме ". = ALIGN(phys)" перед данными. Что туда добавить - так и не понял. Делаю ALIGN(phys+phys) и тоже работает, хотя ничего визуально не меняется (даже сам бинарь). Делаю мелкое число - глючит.

[AFZ]

Коллеги, напоминаю. Традиционным для Си на PDp-11 считается расположение переменных и массивов, локальных для любой С-функции, включая main(), в стеке. Из-за чего обычных для RT-11 96 слов стека (192 байта) между тоже традиционным для RT-11 началом программы 001000 и "желтой" границей стека 000500, чаще всего, не хватает. Поэтому программы из-под компиляторов Си, обычно, линкуют с ключиком /BOT команды LINK, указывая конкретный адрес, откуда начнется программа и ниже которого будет стек.

Я при написании и отладке программ на С, обычно, сначала указывал /BOT:5000, а далее отладка покажет, много это или мало...

[Hunta]

желтой" границей стека 000500

Жёлтая граница стека - ниже 400, красная - ниже 340

Ну и если есть регистр границы стека - возможны варианты - он задаёт значение старшего байта для границы стека, а в младшем - см выше.

[yu.zxpk]

Значит так.
Утилита `bin2load.exe` (a.out -> LDA) имеет внутри harcoded значение ALIGN секции = 0100.
Если в LD скрипте выставить значение ALIGN меньше 0100, то смешение в результирующем LDA не будут соответствовать тому, что прописано в A.OUT файле линкером.

#define SECT_ALIGN 0100
/*
** If we have a data section, we align it to a boundary and
** save it in a new block.
** In this version the boundary is fixed (SECT_ALIGN, defined in bin2load.h)
** I'll give the chance of specifying it as a program argument... perhaps
**
** WARNING: The boundary size MUST be the same as the specified in the link
** script, else BAD THINGS WILL HAPPEN...
*/

[Oleg N. Cher]

Но дело не только в bin2load, ведь я её не использую. Или где-то ещё захардкожено 0100?

Такой вопрос. Столкнулся с тем, что при умножении идёт вызов к неопределённой подпрограмме __mulhi3:

;# Test.c:51:   Laser2_PTBL2(x + 1, y * 10 + 28, 103);
	mov	$012,-(sp)	;#,
	mov	026(sp),-(sp)	;# y,
	jsr	pc,___mulhi3	;#
	add	$04,sp	;#,

Это, получается, 16-битное умножение. Хотя не очень понятно что здесь обозначает hi и 3.

Где-то есть готовая эффективная реализация умножения для 1801BM1 ?

[yu.zxpk]

Функция __mulhi3 должна быть частью LIBGCC, но для PDP11 она не реализована. И вообще, libgcc для PDP-11 я ее не собирал (не дошли руки):

https://github.com/gcc-mirror/gcc/bl.../pdp11/t-pdp11

hi -- half-integer (16-bit) в терминах GCC. qi -- quarter integer (8 bit), si -- 32-bit integer.

https://www.cse.iitb.ac.in/grc/intdo...n-details.html

в Decus-C я нашел реализацию умножения над 2-мя long. Думаю, ее и надо брать за основу для реализации __mulhi3 (для 1801ВМ1 в общем).

http://www.ibiblio.org/pub/academic/...C/5,4/mull.mac

Там рядом лежит fmul.mac, кстати.

Для процессора MSP430 эта функция реализована так:

/* Public domain. */
extern int __mulhi3 (int, int);

int
__mulhi3 (int x, int y)
{
char bit;
int neg = 0;
int rv = 0;

if (y < 0)
{
y = - y;
neg = 1;
}

for (bit = 0; y && bit < sizeof (y) * 8; bit ++)
{
if (y & 1)
rv += x;
x <<= 1;
y >>= 1;
}

return neg ? - rv : rv;
}

[Oleg N. Cher]

В журнале "Персональный компьютер БК-0010, БК-0011М" №2-1995 есть такая реализация умножения:

; Подпрограмма умножения
; 8-разрядных чисел
; R2-множимое, R3-множитель,
; R4-результат, R5-счетчик итераций
MUL: MOV  #10, R5 ; Цикл из 8 итераций
     CLR  R4      ; Очистить аккумулятор результата
1:   ASR  R3      ; Очередной разряд множителя
     ВСС  2       ; Если 0 - дальше
     ADD  R2, R4  ; Иначе прибавить множимое
2:   ASL  R2      ; Сдвиг множимого на один разряд
     SOB  R5, 1   ; Если не конец - в цикл
     RET          ; Выход
; Алгоритм этой программы построен совершенно аналогично
; правилу умножения «в столбик» для двоичных чисел
; и, видимо, в пояснениях не нуждается.

Вроде выглядит неплохо. Меня смутило только то, что заявлено умножение только 8-разрядных чисел. Как можно её модифицировать для 16-разрядных? Также я могу расковырять подпрограмму умножения из OMSI Pascal. Надо?

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

А хотя, скорее всего, OMSI Pascal юзает аппаратное умножение, он же для 1801BM2 и RT-11.