An alternative Assembler

[MyCo]

Hi,

So here after I figured this out, here is my attempt to implement an assembler.

I've gone a bit crazy in the Ruby code of the project, but that was required to get the most out of it. So I could add error checks and support some weird constructs like "mov ebx,var[eax+ecx*8+1234];". It also supports different argument ordering for the calculation in there.

I just added a bunch of instructions, not all. Some could be very easy to add (just a lookup table entry), some others require some more work in the instruction compilation part.

Use on your own risk It might crash when compiling the code while the audio is running.

[TheAudiophileDutchman]

Wow, incredible stuff!

[martinvicanek]

Yes, some serious hacking there! MyCo, are you planning to demo some stuff that you can do with this which would not be possible otherwise? I saw some mems in there witch 16 byte alignment checking...

[MyCo]

Yes, some serious hacking there! MyCo, are you planning to demo some stuff that you can do with this which would not be possible otherwise? I saw some mems in there witch 16 byte alignment checking...

The main memory is not aligned, it doesn't have to anyway. However the stored variables in the memory are aligned, else SSE instructions wouldn't work on them.

I don't have any demo at the moment, but you can do a lot of things much quicker than with the built-in assembler. eg. you can copy one array element with an offset counter in eax to a relative position:

Code: Select all

movaps xmm0,array[eax];
movaps array[eax+4],xmm0;

doing the same in the built-in assembler would be like that:

Code: Select all

movaps xmm0,array[eax];
add eax,16;
movaps array[eax],xmm0;

This would also only work if "array" is a memory defined in the assembler primitive itself... else it won't be aligned for movaps... whereas in my assembler you could use movups instead of movaps for unaligned memory and it work just fine

PS: Updated schematic in the first post.

[KG_is_back]

This is really cool myco... It opens up almost endless possibilities. Only downside is that we can't use it in poly. Perhaps if we stored variables in separate array, we could make an array of arrays, which could hold variables for poly section (and then use voice id to determine which array to use).

[MyCo]

I've updated the schematic in the first post.

This is a complete rebuild. It's a full parser now, not only one that recognizes a pattern. This step was necessary to support math and static (compile time) functions. The parser itself supports highlevel code (like FS DSP code) as well, but the compiling process doesn't at the moment. It would have to create instructions from the math tree (witch is already decoded)... not a big thing, but it has an anoying downside: You wouldn't know which registers your DSP code uses, so after a DSP code line you'll have to assume all registers were used.

The assembler now supports "automic constants". That's something actually very convenient, you can for example write:

Code: Select all

movaps xmm0,5;

And it turns the "5" into a value in memory automatically, so you don't need to declare a variable for it.

Have fun!

[martinvicanek]

MyCo, that's amazing work!
However, it will need documentation and preferrably also examples if others are to use it.

[TheAudiophileDutchman]

This is a complete rebuild. It's a full parser now..

MyCo for president!

Seriously, FWIW you have my endorsement to become part of a 64-bit FS development team!

More votes supporting this idea are welcome in order to trigger the FS Dev(s), people.

[martinvicanek]

+1

[MyCo]

I would like to work on FS, when Malc would allow it

I've updated the schematic with some minor changes, mainly fixes for "[base+index+displacement]" memory access. This is a weird brainfuck. Still not all problems sorted out for this. Trying to get "ebp" register working with this, which is treated differently by the cpu.

@Martin: I don't know how I should demonstrate the possibilities. You can basically do anything except "poly" and accessing DLLs (unless you hack it in, which is possible, but extremely difficult).

Thought about reading out CPU features using cpuid instruction... maybe I'll try it when I'm done with my todo list.