a portable Os?

[turdus]

Not really assembly anymore then, is it?

You're right, fasm is not just an assembler, it's a HLA.

It's "using the assembler's pre-processor to construct an entirely new/different language that isn't assembly at all", which I'd expect to lead to crappy executable code because the underlying assembler won't do any optimisation whatsoever.

Not necessarily.
First you could write optimized assembly with macros (it's preprocessor is *really* featurefull). You can create code specific to argument size, for example (it's a silly example, but I hope you get the point)

Code: Select all

macro mymacro arg
{
if ~ arg in rax, eax, ax
push rax
end if
if arg in rbx,rcx,rdx,rsi,rdi
 mov rax, arg
else
 if arg in ebx, ecx,edx,esi,edi
  xor rax, rax
  mov eax, arg
 else
  movzx rax, arg
 end if
end if
 ... do something ...
if ~ arg in rax, eax, ax
pop rax
end if
}

Second, fasm is able to modify already assembled code on-the-fly from macros.
Third, it repeats optimalisation until code unchanged (no further optimalisation can be done). This could mean thousands of passes (not just 2 passes like most assemblers do).

Finally it's not just theory, I use this for real, from a C like source my compiler generates assembly primarily for fasm, which can be assembled using a massive macro header file. The results are pretty good.

ps.: writing the macros to be efficient could be really tricky, it's not an easy task at all. But the point is, it can be done.

[turdus]

Lets take a OS coded in fasm using it's macro, it would be easy to port to ARM using FasmArm.

You are wrong about that. It's not just the architecture use different registers, but the environment and the ABI differs too.
You have to use other tricks as well, using only macros is not enough for a kernel. I've done this, believe me. I ended up with a thin run-time HAL to achieve architecture independent macro assembly in userspace (and only in userspace, but hey, it's fair enough!).

[Combuster]

Lets take a OS coded in fasm using it's macro, it would be easy to port to ARM using FasmArm.

You are wrong about that. It's not just the architecture use different registers, but the environment and the ABI differs too.

That isn't any different from porting a C kernel.

The real question is, how much more efficient (both in code production and actual execution speed) is writing a preprocessor script to turn x86 assembly into ARM assembly, then writing x86 kernel code on top of that and magically getting arm code as a byproduct, or using C from starters and skip writing your tools altogether.

I honestly believe that if the former turns out to be more efficient, that property will be limited to the original author of said system. Depending on the person in question, some sarcasm needs to be added as well.

[turdus]

That isn't any different from porting a C kernel.

Yes it is, the main purpose of high languages like C is to hide the details of ABI The hard part is done by the C compiler and linker, but here we're talking about implementing what's under the hood.

is writing a preprocessor script to turn x86 assembly into ARM assembly

I don't think it can be done. It's more likely that you create common menomonic set with macros that can be turned into x86 or arm assembly depending on which macro definition file included. The difference seems small, but it's essential since it introduces a new abstraction level.

The results can be better than what a C compiler compiles. But you have to be a very very good assembly programmer in both x86 and arm for that. And experience in creating cross-toolchains also necessary. If you ask will the first try generate better code, the answer is definitely not, imho. I used this approach in my OS only because I have my own ABI and object format, and because it's fun. Effectiveness was not a goal in my case on this matter, portability was. I don't care if gcc creates better code, as long as my code works. (You have to leave something for v2.0 )

[guyfawkes]

It's more likely that you create common menomonic set with macros that can be turned into x86 or arm assembly depending on which macro definition file included. The difference seems small, but it's essential since it introduces a new abstraction level.

The above was the way i was thinking about, when i posted the original post.