Translation of Oberon to native x86 code.

[snayaksnayak]

I see on voc webpage, "Work on native backends for arm and x86_64 is in progress." I am excited about this. Now voc converts Oberon program to a C program using ofront. Then compiles generated C code using gcc, gas and ld to emit final elf file. I hope, work is going on to directly convert Oberon to asm code which can then be assembled using as to generate object code. We will still use ld or a new linker is being made?

[norayr]

according to plans - ld.

however, native backend has not many benefits. most probably it won't generate as efficient code, as C compiler is able. for the simple reasons - number of human/years work on C compilers.

[snayaksnayak]

Ok. So plan is to use ofront, gcc and gas as usual but a new linker will be designed. You are true. native backend may not be more efficient. But still I feel it will be good enough. The feeling is due to the simplicity of Oberon. You may have better experience.

However, what is that the new linker should be able to do which current ld is not able to?

[norayr]

no no, why new linker?

I have already implemented one x86 backend, I already know the generated code won't be faster in most of the cases. It might be thinner, in cases when only Linux kernel calls are used, no call to glibc. But practically it's impossible to write a serious program that does not depend on C runtime or other libraries.

I also understand that it's much more important to have other things, like a tool to automatically generate C library bindings, have a possibility to write graphical applications more easy, etc.

Recently I started to open issues myself, in order to not forget. So the opened issues are the plans.

GNU linker is perfectly fine, does not matter if we generate asm or C code. I don't see a need in other linker.

[norayr]

so yes, native code for x86_64 and ARM is planned, but I do not consider it highest priority. I sometimes work on it, but I have many other things to do.

[snayaksnayak]

That's fine.