Почему BBC Basic так тормозит?

[Alex]

К дистрибутиву Basic PDP-11 шли разные библиотеки, под разные арифметические опции , по сему "формат 3=1" - есть стандартное представление для чисел с плавающей запятой одинарной точности на PDP-11. Ещё вроде как была опция генерации с двойной точностью, но я с ней не разбирался.

[ivagor]

BBC Basic PDP11 можно оптимизировать для УКНЦ, сейчас не используются команды умножения и деления, и текущие реализации не самые быстрые (особенно деление).

[Hunta]

Чёт мне не понятен смысл всех гаданий и предположений. Исходники есть - кому интересно - можно залезть и посмотреть

[BlaireCas]

Результаты просто невероятно тормозные.

Запустил на реальной УКНЦ. И .. немного подождал . 12876.3 секунды (ну хоть УКНЦ прогрел). Фрактал рисуется верно.
Заодно можно сказать что эмулятор UNKCBTL по таймингам в данном примере довольно точен (имхо +/-3% это уже могут сами укнц плавать по частотам) и достаточно тестировать на нем.
Открыл код васика.. а черт его знает почему оно тормозит. Операции умножения и деления там реализованы циклическими сдвигами/сложениями.
Деление вроде как 48 раз крутит эти операции. Вроде вот кусок кода если верно понимаю:

Скрытый текст

; Division - <number> / <number>
; ==============================
; On entry, r2/r3/r4 = RHS value
;           sp=>retaddr, r2/r4/r3 = LHS value
;
.fnDivide
jsr  pc,EnsureFloat
beq  errDivideZero	; RHS=0, num/0 = divide by zero
jsr  pc,SwapStack
.fnDivideSwap
jsr  pc,EnsureFloat
beq  fnMultiplyZero	; LHS=0, 0/num = 0
;
; r2/r3/r4=LHS value
;    sp=>  RHS value
;
; to divide,
;  exp=expL-expR
;  man=manL/manR
;  then renormalise
;
sub  2(sp),r2		; Subtract exponents
add  #&81,r2		; Exponent biased from &80
;			; Exponent is tested after normalisation as
;			; exponent may get inc/dec'd back into range
;			; by normalisation
jsr  pc,fnFloatPrepare	; Stack exponent, get sign of result, add '1' to mantissas
mov  r5,-(sp)		; Save program pointer
mov  r1,-(sp)		; Save sign of result
mov  #48,r5		; r5=48, number of bits to divide
clr  r2
; could speed this up by doing 32+8 bits and pre-rotating values
;
; we now have
;          r1:r0=running total, starts at LHS dividend
;       r2:r3:r4=initially LHS mantissa, result rotated into
;          r5   =48, number of bits to add/multiply
;          sp=>sign, saved r5, retaddr, exponent, r4, r3 = RHS value
;
br fnDivideStart	; Jump into division loop
.fnDivideFloatLp
rol  r2
rol  r1			; Rotate carry bit into r3:r4 result
rol  r0
.fnDivide34
clc			; Rotate dividend
rol  r4
rol  r3
bcs  fnDivideSubtract
.fnDivideStart
sub  8(sp),r4		; Trial subtract total=total-RHS divisor
sbc  r3
sub  10(sp),r3
bcc  fnDivideNoRestore
add  8(sp),r4		; Add RHS back to restore total
adc  r3
add  10(sp),r3
clc
br fnDivideCount
.fnDivideSubtract
sub  8(sp),r4		; Trial subtract total=total-RHS divisor
sbc  r3
sub  10(sp),r3
.fnDivideNoRestore
sec
.fnDivideCount
dec  r5
bne  fnDivideFloatLp	; Loop for all bits
;
; Answer is now in  r0:r1:r2
; Transfer to       r3:r4:xx
; Then normalise
;
; Need to get
; r3:r4:r1=mantissa
; r2      =exponent
; (sp)    =return address
; r0      =<sign of result><operator>
;
mov  r0,r3
mov  r1,r4
.fnDivideFinish
mov  (sp)+,r0		; Get sign of result
mov  (sp)+,r5		; Restore program pointer
mov  (sp)+,r1		; r1=return address
mov  r1,4(sp)		; Store further up stack
mov  r2,r1		; r1=rounding bits
mov  (sp)+,r2		; r2=exponent of result
tst  (sp)+		; Drop part of RHS from stack
bis  #&80,r0		; Set <not compare>
jmp  fnFloatNormaliseDiv; Jump to normalise and insert sign bit

[свернуть]

Попробовал простейшую программку типа хелловорлд - вообщем такое впечатление что в этот бейсик специально встроили задержку на выполнение каждой строки. То-есть все эти деления/умножения вовсе не причем. Банально пустой цикл крутит с тормозами по 0.5сек выполнения строки.
Как-будто интерпретатор для получения каждого символа в строке кода натужно кучу функций выполняет. Именно такое впечатление создалось, может и правда какой жуткий вызов функции RT-11 на каждый символ делает ибо строки с REM - тоже тормозят.
Вообщем надо код копать (а он большой).

UPD: кажется нашел в чем дело - на каждый чих этот васик делает EMT 224(10) (типа проверяет на нажатие ESC или УПР-Ц или еще чего), надо попробовать его от этого непотребства отучить

[BlaireCas]

Отучил BBC васик от нехорошего вызова EMT на каждый чих.
Стало 231.2сек что видимо уже куда ни шло. Реальная УКНЦ.

Скрытый текст

[свернуть]

Дальше можно видимо поковыряться и остальное тоже так-сказать "улучшить" в вызовах RT-11, но большого смысла не вижу (у нас и так уберскоростной бейсик есть).
Тормоза отключились добавлением в RT11IO файле такого

Скрытый текст

...
; Check for Escape state
; ======================
.IO_Escape
; +Blaire:
rts pc
; +Blaire: lets check if can use without this
tstb SV_ESCFLG ; Check local Escape flag
bmi errEscape ; Background Escape pending
...

[свернуть]

А также закомментировал в файле Execute на всяк.пож. вызов этой процедуры.

Скрытый текст

...
; Execute program code
; =====================
; R5=BASIC program pointer
; R4/R3=32-bit accumulator
; R2=value type/exponent
; R1/R0=working
;
.Execute
;jsr pc,IO_Escape ; Check Escape state
.ExecLineNext
movb (r5)+,r0 ; Step past space
...

[свернуть]

Процедура судя по комментам чекает нажатия кнопок (вообщем ttyin какой-то ждет) и соответственно тормозит весь интерпретатор.

BBC.SAV скомпиленный с данными изменениями:
bbc.zip

[litwr]

BBC Basic PDP11 можно оптимизировать для УКНЦ, сейчас не используются команды умножения и деления, и текущие реализации не самые быстрые (особенно деление).

Автор что-то по этому поводу разъяснял. Типа что аппаратные умножения и деления хороши только для небольших мантисс, а для больших растут какие-то издержки. Возможно, что идея сделать бейсик более портабельным также как-то учитывалась.

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

Отучил BBC васик от нехорошего вызова EMT на каждый чих.
Стало 231.2сек что видимо уже куда ни шло. Реальная УКНЦ.

Реально круто! На UKNCBTL - 226.92c - почти в точности как на железе - респект автору эмулятора, его бы ещё в Linux...
Прежде чем сообщать автору, который и попросил меня потестировать бейсик, надо разобраться с некоторыми вопросами.
1) сверхтормознутость этого EMT 224(10) - это особенность RT-11 вообще или только порта RT-11 для УКНЦ? Может кто запустит оба бейсика на ДВК или ещё какой PDP-11? Прикрепляю архив с обоими бейсиками: исходным, тормозящим (BBC.SAV) и исправленным (BBC1.SAV).
2) не пострадала ли функциональность бейсика после правки? Может ли он сейчас отлавливать нажатия критических клавиш?
bbcbasic1.zip


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

[Advertiser]

[Hunta]

порта RT-11 для УКНЦ

Никакого специального портирования RT-11 на УКНЦ не требуется.

[litwr]

Прогнал тест на эмуляторе RT-11. Исходный тормознутый работает под этим эмулятором также как и на УКНЦ тормознуто. А исправленный работает очень хорошо. Он даже обогнал вильнюсский бейсик для ДВК. BBC Basic работал 1.8 c, а ДВК бейсик - около 3 с - не знаю как под ДВК использовать таймер, поэтому использовал секундомер. Таким образом мой первый вопрос отпадает.
Странно, что под эмулятором BBC Basic почти в 2 раза быстрее, а на УКНЦ в 6 раз медленнее - новая загадка.

[BlaireCas]

не пострадала ли функциональность бейсика после правки?

Ясное дело что пострадала. Автор ведь не случайно поставил в обработке каждой строки вызов обработки ESC-последовательностей.
Могу предположить что от моего изменения кода пропала остановка выполняющейся программы по ESC, а также после еще каких-либо кнопок которые генерят ESC-последовательности. А может и еще чего навернулось связанное с этим.

Что такое EMT 340(8) - оно-же .TTINR - это поместить код нажатой кнопки в R0 и установить флаг С если кнопка не нажата. Вроде как это "быстро" действует. Тем не менее фиг его знает насколько быстро. Я не разбирал потроха RT-11 для УКНЦ.
И если запустить этот васик в rt11.exe (кажется эмулятор Patron'a) который вообще под windows и работать должен с бешеной скоростью - задержка там очень большая тоже есть. То-есть возможно в опросе клавиатуры участвует таймер.

Имхо надо просто автору сказать что мол "тормозит из-за вот этого". (показать в моем посте код для Execute). Он вызывает EMT 340(8) аж два раза.
Посоветовать для УКНЦ (а он кстати чекает машину уж не знаю верно-ли) не делать постоянные вызовы .TTINR когда это не требуется. Тогда правда неясно как из бесконечного цикла выходить (ахах - reset-ом)...
Для УКНЦ можно конечно какие-нибудь специфические регистры заюзать, но это не RT-11 way уже будет.

Странно, что под эмулятором BBC Basic почти в 2 раза быстрее, а на УКНЦ в 6 раз медленнее - новая загадка.

Ну это как-раз и не странно. Сравнивать эмулятор просто системы RT-11 с эмулятором реального железа это скажем-так - неправильно. (типа соленое круглее чем красное получится).

[Sandro]

Посоветовать для УКНЦ (а он кстати чекает машину уж не знаю верно-ли) не делать постоянные вызовы .TTINR когда это не требуется. Тогда правда неясно как из бесконечного цикла выходить (ахах - reset-ом)...

Что мешает поставить счётчик и проверять ввод, скажем, только каждую сотую строку исполняемой программы?