OberonCore

да блин, тварь я дрожащая, или?! щаз придумаю синтаксис для преобразования `Log.Write` и `Log.WiriteLn`. точнее, тут даже синтаксиса не надо — просто компилятор проверит, есть ли в соответствующем модуле нужные процедуры, да перепишет. а то ужасно надоело `Log.String("boo="):Int(boo):Ln;` и так далее. хоть двоеточия и помогают, но всё равно задолбало. пусть машина работает, перепишет мне `Log.WriteLn("boo=", boo);` в то, что выше. у неё вся нужная инфа для этого есть.

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

и… не надо было делать checked integer math! потому что угадайте кто нашёл что где? да: я, баги в соответствующих опкодах, в наножите. в итоге пришлось убирать старые опкоды, делать новые, заниматься сексом в гамаке. но теперь математика — checked. иба. флоаты пока не чеканы.

из хорошего: опкодов стало меньше, а могут они теперь больше. потому что по какой-то причине авторы наножита решили объединить сложение и бранч в одну инструкцию. и пофигу, что кодоген от этого приходит в яростный восторг настолько, что иногда не может правильно спильнуть регистры. очевидно, у авторов в их юзкейсе всё работало — и ладно. зачем так сделано — я не понимаю, и, похоже, это делал не оригинальный автор (или над ним стоял манагер с молотком и требовал «уже позавчера»). в общем, там налицо странное непонимание того, как в принципе наножит сдизайнен. и плюс лишняя копипаста ещё.

а теперь надо переписать компилятор. сейчас я генерирую проверку, и прыжок через акулу. то есть, "branch always taken" — что не лучшая идея. надо поменять условия бранчей, а всех акул сложить в конец кода процедуры. поскольку трапы у меня явно сохраняют строку и модуль, где трапнулось — то нет смысла пытаться держать их рядом с проверками. да и всё равно пока нет способа из адреса получить location.

arisu, а вот ты как считаешь, тип ADDRESS должен быть в SYSTEM или нет (просто ADDRESS, как в A2)?
И обязательно ли должен быть беззнаковым?

сменил проверки NIL deref, индексы массивов и прочее на "jump not taken", перенёс код трапов в конец процедур. результат: минус три секунды на версии с `NEW()`, минус секунда на версии со статик массивами. вау.

p.s.: тут, я думаю, дело не в улучшении начального условия для предиктора, а как раз в том, что код трапов уехал далеко-далеко. соответственно, в 99% случаев спекулятивное исполнение раньше спекулировало код, который не выполнится. а теперь наоборот: спекулятивка правильно спекулирует то, что почти всегда выполнено будет. отсюда и такое офигенное ускорение. особенно это видно на версии с `NEW()`, потому что там овердовига проверок на «NIL pointer dereference».

ну, я считаю ровно так, как сделал в Oberon/Ur. ;-)

никакому нормальному коду `ADDRESS` не нужен, и нужен быть не должен никогда. поэтому место ему — в SYSTEM, и никак иначе. в том числе чтобы отбить охоту к дурацким микрооптимизациям типа: «я заюзаю ADDRESS, он натурального размера для камня, вот я мамкин оптимизатор!»

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

я сделал беззнаковый, потому что адреса сами по себе беззнаковые, и это логично. но с учётом обязательных явных кастований (тоже через `SYSTEM.CAST()`) — оно неважно. надо только учесть, что на 64 битах 32-битное знаковое целое должно кастоваться в адрес с расширением знака. ну, чтобы `adr + SYSTEM.CAST(INTEGER, intvar)` нормально работало, если `intvar` отрицательное.

p.s.: а, да. ещё аргумент за беззнаковость — деления быстрее. поскольку знака нет, то не надо руками приводить обычный для железа симметричный вид в асимметричный, чтобы DIV оптимизировалось в сдвиги, а MOD в маски. соответственно, минус бранч на современном железе.

очередное волевое решение: я решил `LONGINT` тоже не делать.

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

второе: Nanojit в режиме 32 бита этих операций не имеет. надо лепить заглушки, а мне лень.

единственный случай, когда это может понадобиться — для получения размера файла. и с этим прекрасно справится `REAL` — потому что камон, файлы больше… чо там за терабайтом-то идёт? в общем, не бывает таких файлов. 52 бита в `REAL` вполне достаточно как на сейчас, так и на обозримое будущее.

p.s.: `LONGINT` — такой же рудимент шестнадцатибитной эпохи, как и `SHORTINT`. это всё скучные микрооптимизации.

Ash nazg durbatulûk,
Ash nazg gimbatul,
Ash nazg thrakatulûk,
Agh burzum-ishi krimpatul.

Правильное-е-е-е решение-е-е-е!!! ШУТКА!
Перемножаем 32 бита на 32 и...

PS: я тут намедни с ARM-v7M (Cortex-M4) забавлялся, так вот, аппаратно он 32 бита на 32 перемножает (естественно, 64 бита результат), а вот делить 64 бита на 32 - неа. Буквально, таблица Пифагора (произведение однозначных - двузначные числа) только в одном направлении.


Проставишься (да, во сне) - и всех-то делов (((-8Ж

получаем 32. нормально. если не влезло — получаем трап. нет, а зачем больше-то? а если надо больше — то REAL. там аж 52 бита есть.

вот я натурально не помню, когда мне в коде надо было LONGINT/int64_t. за исключением написания компилятора, чтобы переполнение интов в constant folding ловить, да. ;-) но это и реалами можно.

довольно много железа так. а для реализации лонгинтов нам вообще надо 64 делить на 64. и вот стоит этого геморроя фича, которая нафиг не нужна? ;-)

так он же ЗОЖник был, вроде как… никто, увы, не идеален.

p.s.: надо бы и из LC выкинуть. зачем оно там…

p.p.s: CP2, кстати, тоже лонгинты не использует. они там вместо этого используют комбо из инта и реала, чтобы все 64 бита хранить.

тащемта, остался более-менее последний шаг до относительно полноценной системы: создание и регистрация/дерегистрация карт указателей в стеке, да GC. и, в общем, будет юзабельно.

конечно, там внутре неонка^w много ещё на соплях. например, нет таблиц наследования, так что `IS` не O(1). не то чтобы их сложно делать было — просто как-то всё не соберусь. самое смешное то, что в крестокоде как раз самопальная реализация динамик кастов с построением этих табличек.

а GC, кстати, уже можно на самом O/Ur напилить. вообще, некоторые буилтины можно из крестокода в кернел вытащить.

кстати, надо бы посмотреть в каком-нибудь… где-нибудь, короче, как там на ссе делаются всякие `trunc()`, `round()` и прочие синусы с косинусами. а то как-то неприлично для этого генерировать вызовы функций. в наножите отчего-то таких инструкций нет.

ах, да. SSE2 — вроде как минимальное требование. для дотпродукта VEC4 надо SSE4.1, но я этот опкод не использую.

сделал `WRITE` и `WRITELN`. большими, потому что технически это зарезервированые «макросы». для чисел разрешил синтаксис `n:width` и `n:width:precision` (раскрываются в `xxxFormat()`). удобно же. компилятор переписывает их в честные вызовы с прибитыми гвоздями именами процедур.

на самом деле это не единственная «хитрая» процедура: есть ещё `INC()` и `DEC()`, которые имеют опциональный аргумент. а раз прен-цен-дент, как говорится, есть, то… гуляй, рванина!

заодно глянул в gcc — и он для всяких там `ceil()` вызывает библиотечные функции, а не вставляет код. а раз gcc можно — то и я напрямую "libm" дёргаю. отчего бы и да. правда, на шынде нет "libm", и там надо будет враперы, видимо.

заодно сделал недокументированые, но удобные суффиксы "R" и "S" — для задания даблов и флоатов в шестнадцатиричном виде. в CP2 они тоже есть, например, хоть в документации о них и не сказано. удобно задавать константы не завися от точности парзера. типа: `PI* = 4009_21FB_5444_2D18R;`.

В ARMv7E-M:


NanoJIT так умеет?

для x86. ;-) для армов дотпродукты вообще не поддерживаются как инструкции.

впрочем, арм-бэкэнд всё равно сломан сейчас. и x86_64 тоже. я много всяких инструкций добавил, и реализовал их только на x86 пока. для x86_64 потом доделаю, наверное. для арма — не уверен: оно мне не надо ваще-ваще.

ну, и я в компиляторе ни преобразования кода, ни паттерн матчинг не делал пока — так что он не поймёт, что это дотпродукт. признаюсь: я боюсь этим заниматься. запиливание оптимизаций — это такая же фигня, как ремонт: начать можно, закончить нет. я отчасти и кодоген поэтому сам не хочу делать: каждый раз пытаюсь в кодогене запилить многопроходный instruction selector, с хинтами и кошкодевочками.

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

p.s.: алсо, посмотрел в libJIT… (окей, окей, не имею права. но я только одним глазком!) так вот: там тоже для всяких `ceil()` тупо вызывается libm. ну так нечестно! а смотреть в libm — это уже два глаза будет.

кстати. надо бы пессимизировать немого constant folding. сейчас `func() * 0`, например, сфолдится просто в ноль. а так нельзя, если `func()` не pure (я для этого детект pure и делал). конечно, и писать код, где возможны подобные сайд-эффекты тоже нельзя, но пишем же.

вообще, конечно, я бы весь constant folding оставил наножиту, но… он нужен для констант, гыг.

кстати. в теории в константах можно разрешить использовать функции из других модулей, если они pure. `CONST xsin = M.Sin(0.666);` — вполне да. потому что на это время у компилятора уже есть код для `Math`. хотя это и перебор, но было бы забавно.

а кстати! я ж могу теперь сделать правильное поведение `FOR` с граничными значениями! у меня есть новая красивая инструкция `addov`, и переход по «integer overflow». соответственно, цикл надо прекращать как по превышению лимита, так и по переполнению.

а ещё подумал — и запилил полезную оптимизацию. две, точнее.

во-первых, `smth := smth + …;` и `smth := smth - …;` перобразуются в `maddi` и `msubi` (работа напрямую с памятью, не загружая значение в регистр). в итоге `a := a + 1;` почти так же эффективно, как и `INC(a);`. и ещё делает проверку на переполнение.

во-вторых, `a[expr] := a[expr] …;` (то есть, что угодно с массивами такое бинарное) вычисляет адрес элемента массива только один раз. это уже серьёзней, потому что скипает всякие проверки индексов и прочую дребедень.

опять таки: подобную оптимизацию можно было сделать вручную через `INC()`/`DEC()`, но они — by design — не проверяют переполнение. а как я есть мамкин оптимизатор, и знал, что компилятор для присваивания, подобному выше, генерит УЖОС — то всё время ходелось inc/dec зафигачить. а теперь я знаю, что сгенерит нормально — и попустило.

ваще, это задел на CSE получился, потому что ноды теперь имеют метод `isSame()`.

впилил встроеные `ISINF()`, `ISNAN()`, `ISFINITE()`, `ISDENORMAL()`. глупо делать вид, что флоаты этих всех свойств не имеют. а раз имеют — довольно глупо не иметь штатной возможности их проверить. конечно, в `System:Math` это всё есть, но со встроеными компилятор делает красивый инлайновый код.

и внезапно вспомнил, что забыл сделать `WITH`. после чего напоролся на радость жизни:

потому что по старой доброй традиции `WITH` энфорсит тип… прямо в `NodeVarDecl`. придётся делать механизм прокси-нод для переменных.

и, кстати: подумал, что точку с запятой после всяких `END` надо сделать опциональной. чисто для красоты.

да камон! хватит уже делать вид, что на свете флоатов не существует: очевидно, что они есть. и обероны их поддерживают. не вижу ни одной причины не повысить `ROUND()`, `TRUNC()`, `CEILING()`, `FLOOR()` до встроеных. прибиваем гвоздями требование IEEE-754 32/64, и повышаем.

я понимаю, что Так Исторически Сложилось: это всё было в модуле потому что использовало подпрограммы в машинном коде. но довольно это терпеть! продолжаем избавляться от наследия первобытных времён.

и если что — это просто в SSE 4.2 есть специальные инструкции для этих операций. грешно не использовать. а если SSE 4.2 не поддерживается — то фолбэк обратно в libm. вай нот.

впилил синтаксис для арифметики без проверок переполнения: `[unchecked](expr)`, `INC[unchecked](var, expr)`, `DEC[unchecked](var, expr)`. зачем? а чтобы проверить свою реализацию RIPEMD160 из LC.

проверил. допилил немного отсутствующего (частичный `SYSTEM.THISARRAY()`, например). с удивлением увидел такое:
"766 tests passed, 0 tests failed."

кстати, Oberon/Ur очень хорош для криптокода. потому что компилятор не умничает, а поёт ровно то, что напрсано. вот написано, например, `ERASE()` — так и будет зануление памяти, и никто его не соптимизирует в ничего, потому что «какой смысл занулять локалы, хаха». бранчи проверок индексов можно во внимание не брать, потому что они хоть и data-dependent, но у них на входе всегда одно и то же.

и дофига умные преобразования кода тоже никто не сделает. написал битовую операцию — будет битовая операция. никакой VRP не придёт, не увидит, что там в итоге один бит остаётся, и не заменит на дофига умную конструкцию с проверкой конкретного бита и командой-с-условием. (привет, шланг и гоцэцэ!)

да, синтаксис кривой и неудобный. это так и задумано. и для него надо `SYSTEM` импортировать, иначе компилятор удивится. и нет, bounds checking так отключить нельзя.