OberonCore

на всякий чуть разверну: FPU совершенно, полностью не нужен. есть ровно одно место, где надо забрать значение со стека FPU: x86 cdecl ABI (и другие x86 ABI, да). вся плавающая точка делается на SSE. компилятор, собственно, просто откажется запускаться, если SSE не увидит — потому что SSE-инструкции много где, в том числе и для нового типа `VEC4`. никакого смысла писать обвязки для не-SSE камней нет. соответственно, вся работа с FPU — это мёртвый код, который не будет активирован никогда вообще. из плавающих типов в O/Ur только `REAL` и `SHORTREAL` (double и float соответственно).

да, в SSE нет синусов, косинусов и прочих гитик. но в Nanojit и инструкций таких нет, это всё равно интринсики, так что даже это не теряется. есть инструкции round/trunc/ceil/floor, но я их добавил сам, и они требуют SSE4.2 (или 4.1, не помню). а при отсутствии такого SSE опять будут интринсики (пришлось, потому что мой валгринд умеет только в SSE2).

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

p.s.: «быстрее» — это примерно 500 мсек на Эксперименте. в итоге Эксперимент сейчас исполняется за 9.28 секунд (было 10.2 или около того). в общем, код определённо быстрее, чем был. с CP2 там 12 секунд, кажется.

как-то пропустил очевидное: CSE довольно часто в состоянии опредлить, что проверки на `NIL` или на корректность индекса массива одни и те же (типа `r.field1 := 1; r.field2 := 2;` — ну, вы поняли), и заменяет одинаковые условия в переходах на самое первое вычисленое. а поэтому в принципе нет никакого смысла сохранять и все такие переходы кроме первого: или первый же триггернутлся, или ни один не триггернулся.

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

забавно: в коде Threat убралось чуть больше тысячи таких переходов; и почти все они были переходами на трапы, так что и больше тысячи вызовов трапов — около 10 кб сгенерёного кода. пусть мелочь, но всё равно приятная.

более сложные штуки (типа символического анализатора и VRP), чтобы убирать проверки индексов в циклах, например, стоят намного дороже (как в плане времени, так и в плане сложности кода). пока не вижу смысла их делать.


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

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