This is a great effort!

I have some remarks though:

• For future easy of maintenance each new architecture needs JSON data in instruction database. I personally don't mind if you can just have a script for creating it from official sources, etc... But this database is important and I would like to use it to generate the assembler instead of having it hand-written (how to do that can be seen in a32_port). It can also be used to generate tests (most X86 and AArch64 tests were generated from the database by executing LLVM-MC with instructions). Basically, all assembler tests should be generated by other assemblers and not based on AsmJit or AsmJit instruction database.
• This is a consequence of not having the DB - The database doesn't provide RW info -> there is no working Compiler without this
• Since there is no database, there is no instruction validation as well

I think it's good overall, but there is a work to do and this would all have to be resolved before it's merged to upstream. I haven't merged my own a32_port branch yet as it's not complete, and I'm going to do the same in this case.

Regarding the usefulness of instruction database. When more and more architectures are added to AsmJit I have found out that I cannot maintain ALL of them - basically keeping track of all architectures, new extensions, instructions, etc... So I spent time in a32_port to actually develop a different approach - let's generate assembler and most data from instruction database to simplify maintenance - when adding a new instruction, just a line is added to the database and it all works. So unless a totally new extension with new register sets, etc... is added to the ISA, it's pretty easy to extend.

And this is how I see the future of AsmJit, because it's impossible to keep maintaining and extending it if there is a lot of hand-written stuff.

Thank you very much for your patience in explaining the role and importance of DB, I will refer to aarch64 to write DB for loongarch architecture.

Hello~ @kobalicek
I generated loongarch's instruction database based on LoongArch-Vol1-EN

rebase code

Hi, what else can be done to improve the loongarch support code, looking forward to your suggestions!

Well, what I have written previously still holds. AsmJit is moving in direction of generated assemblers and instruction metadata accessors, so this should be possibly implemented here as well - there should be working tools such as queryRWInfo, etc... so Builder/Compiler tools can work with loongarch as well. Basically the JSON database of instructions should be actually used here - when you make a change in the database the generator should be able to regenerate the code as well. It's a lot of work, but I seriously cannot maintain handwritten assemblers for multiple architectures - this doesn't scale anymore.

In a nutshell, this PR should be as clean as it can get as I cannot maintain this code on my own - I have no loongarch hardware to even test this on, there is no loongarch support on CI, and I won't be able to fix any bugs if they are reported.

My own arm32 port is still in a separate branch for similar reasons, so I would not push this one if there are TODOs or there is unfinished code that even I cannot fix.

And last point - remove all copy pasted code from AArch64.

Thanks for the reply, I will continue to improve the code to make the json database actually work.
For the problem of not having loongarch hardware, we can provide ci machines that can be logged in remotely and help set up the ci, while loongarch has qemu available upstream, which might also be a way to go, or we can also send loongarch hardware for testing.
Finally, if the code is merged in, we will also participate in the maintenance to reduce the pressure on the back-end maintenance.

Would it be possible to get a loongarch board so I can test stuff locally?

Okay，I'll apply to loongson, but China recently had Chinese New Year, so I'm expected to start work on February 5

• For future easy of maintenance each new architecture needs JSON data in instruction database. I personally don't mind if you can just have a script for creating it from official sources, etc... But this database is important and I would like to use it to generate the assembler instead of having it hand-written (how to do that can be seen in a32_port).

Hello, I want to do some development on RISCV architecture recently. I found that isa_xxarch.json seems to be handwritten? (I may have misunderstood). So I want to know how to generate it automatically. Is there any command or operation that can be given? :)

@LiqinWeng Yeah ISA DB is hand-written, similarly to ISA DB used by LLVM, for example.

The problem of generating it from other sources is the following:

• does it have all the information necessary for AsmJit?
• is it possible to generate a 100% assembler replacement based on that DB?
• what about alternative forms, etc... well described?
• what about instruction read/write info?
• does it have ALL the instructions, even future extensions?
• what about vendor specific instructions/extensions?

Etc...

So, the best way is to maintain a database that can be extended and where there is a single instruction per line. This way, it's easy to edit, and that if there is a generator that generates assembler based on that - it's easy to maintain.

At the moment ARM32 backend is the first to go this route (fully generated assembler), and the existing ISAs (x86 and aarch64) will go this route too. And this is the reason I don't want another hand-written assembler in asmjit - it's not sustaintable to maintain it, and I have almost no time, so I would not commit to maintaining something I know already I cannot.

Hi, I wonder wether this PR is still in active development? @junchao-loongson It seems the code still needs some cleanup, and have we resolved all issues @kobalicek mentioned? If not, what the barrier is?

BTW, if the real hardware is blocking this from merge, I could donate a LoongArch motherborad for CI or testing, Thanks!

I would recommend forking asmjit and using the fork for developing/using Loongarch.

I have already received a small machine from Loongson to test LA64 locally, but the problem is that I have no time to actually do any testing with it. I simply cannot work for free (and Loongson doesn't seem to be interested in supporting this effort financially).

This all means that I don't even have time to review this long PR, and I believe the comments I have made weren't fixed.

EDIT: I have updated the last sentence (the things to do weren't fixed I think)

I would recommend forking asmjit and using the fork for developing/using Loongarch.

I have already received a small machine from Loongson to test LA64 locally, but the problem is that I have no time to actually do any testing with it. I simply cannot work for free (and Loongson doesn't seem to be interested in supporting this effort financially).

This all means that I don't even have time to review this long PR, and I believe the comments I have made were fixed.

Thanks for your in time reply, thus we'll fork this repo and maintain the LoongArch port separately.

Yeah that's the right way to go in this case I think.

I mean whoever wants to use LA would use your repo and fill bugs in your repo. This definitely works for me as I would not have to maintain it.