Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial e2k support. #7

Merged
merged 45 commits into from
Mar 9, 2025
Merged

Initial e2k support. #7

merged 45 commits into from
Mar 9, 2025

Conversation

helce
Copy link

@helce helce commented Mar 2, 2025

Hello there.

Interpreter part for e2k(elbrus) architecture. JIT is not implemented yet. Backported to the openxray's luajit state. Can be built by LCC (Elbrus C Compiler). Additional information and remote access here: https://dev.mcst.ru/

Prefered configuration options for LCC:
XCFLAGS="-O3 -fexceptions"

helce and others added 30 commits October 19, 2023 15:20
Basic support, but can't publish codegen itself (dasm_e2k.lua). Will add generated code later, and make rules to use it.
vm_e2k.dasc under development yet, its tested, but should be omptimized more and more...
No jit support yet.

Recommended flags for build:
XCFLAGS="-DLUAJIT_UNWIND_EXTERNAL -fexceptions -O3"
I cannot publish NDA code with opcodes and instruction coding for e2k architecture, so just use pregenerated code.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
This is final version, I think. The architecture of LuaJIT is adverse for e2k.  Random access to BC templates and all operands from memory slows down compiler.
To make optimal lua jit compiler for e2k, should be done template-chain architecture and most data in registers with JIT planning of operations and codegen. But within the framework of this project, it is not advisable
Rare errors detected by EntityFX-Bench: incorrect read of MULTRES, and incorrect branch in string_sub fastcall.
found in shaders\gl\accum_volumetric_nomsaa.s shader from openxray engine.
Incorrect shifting results, when more results expected (garbage instead of nill). (bug from openxray).
Incorrect  parameter for lj_tab_getinth call and incorrect logic block of resulting value, found in lua-Harness/suite/test_lua/015-forlist.t
incorrect branch cos of too late preload of PC, found  in lua-Harness/suite/test_lua/108-userdata.t
incorrect logical operations near fallback case, found in lua-Harness/suite/test_lua/301-basic.t
error cos of incorrect reusing registers and the bitness of data , found in lua-Harness/suite/test_lua/306-table.t
incorrect planning of operations, sequential commands in single wide instruction.
    We should reserve 64 bytes in stack frames for parameters in registers. Our api doesnot use it, but external code, may write or read from this space. Bug found on https://github.com/ThePhD/sol2 during work on openmw.
    It appeared in iset2, currently it is generic, so we can skip it and use single instruction instead of original code.
That's unreadable!
This is a workaround for compatibility with scripts written for LuaJIT
1.1.x
BuildVM were generating invalid headers
@Xottab-DUTY Xottab-DUTY added the enhancement New feature or request label Mar 9, 2025
@Xottab-DUTY Xottab-DUTY merged commit 011b8db into OpenXRay:v2.1 Mar 9, 2025
@Xottab-DUTY
Copy link
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants