flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Compiler Internals > [fasmg.x86] the long road ahead

Author
Thread Post new topic Reply to topic
Mike Gonta



Joined: 26 Dec 2010
Posts: 189
[fasmg.x86] the long road ahead
As a proof of concept I've added (the relatively easy) x86 nop instruction to the fasmg core so that it assembles
that instruction's opcode (0x90).
I added this line to tables.inc symbols:

Code:
  db 3,'nop',SYMCLASS_INSTRUCTION,VALTYPE_NATIVE_COMMAND,VAL_INTERNAL,1
  dd x86_nop

which is the same as the 'db' (define_data) entry with a x86_nop handler:

Code:
x86_nop:
  pusha
  mov ecx1
  call initialize_output
  mov byte [edi], 0x90
  popa
  jmp instruction_assembled


_________________
Mike Gonta
look and see - many look but few see

http://mikegonta.com


Last edited by Mike Gonta on 29 Apr 2017, 22:10; edited 2 times in total
Post 29 Apr 2017, 13:29
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14673
Location: Origae-6
But x86 nop is more than just "db 0x90", it can also have arguments to give longer no-ops. Plus it is processor specific. Other CPUs can also use the nop opcode but have entirely different binary outputs.
Post 29 Apr 2017, 13:32
View user's profile Send private message Visit poster's website Reply with quote
Mike Gonta



Joined: 26 Dec 2010
Posts: 189

revolution wrote:
But x86 nop is more than just "db 0x90", it can also have arguments to give longer no-ops. Plus it is processor
specific. Other CPUs can also use the nop opcode but have entirely different binary outputs.

Of course, but this would be for an x86 specific fasmg version which would use an api that Tomasz hinted at here.

_________________
Mike Gonta
look and see - many look but few see

http://mikegonta.com
Post 29 Apr 2017, 14:11
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6310
Location: Kraków, Poland
You do not need to preserve all the registers, in fact the only register that matters when jumping to "instruction_assembled" is ESI.
You may find some info about the instruction handler interface in DIRECTIVES.INC around line 290.
Post 29 Apr 2017, 14:20
View user's profile Send private message Visit poster's website Reply with quote
Mike Gonta



Joined: 26 Dec 2010
Posts: 189

Tomasz Grysztar wrote:
You do not need to preserve all the registers, in fact the only register that matters when jumping to "instruction_assembled" is ESI.
You may find some info about the instruction handler interface in DIRECTIVES.INC around line 290.

Thank you.
I'll start digging for the rest of the api.

http://mikegonta.com/fasmg.x86

_________________
Mike Gonta
look and see - many look but few see

http://mikegonta.com
Post 29 Apr 2017, 15:01
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6310
Location: Kraków, Poland
I think it is worth noting why have I not started working on native implementation x86 instruction set myself. I was a bit overwhelmed by my own ideas. I knew that to include everything I wanted I would have to put so much work into it that I'm not even sure if it could pay off. And fasmg by itself is enough to keep me busy for a long time, while I find writing macros for it very satisfying.

What I had in mind for "fasm 2" instruction encoder (I only shared it with revolution back then, but we did not discuss this much) was to include many switchable settings. In case of fasm 1 there is just a few settings for the instruction encoder - USE16, USE32 and USE64, and recently added USEAVX256 and USEAVX512. For a new encoder I wanted to have many more, including choice of supported CPU lines / instruction sets, but also including options of encoding instructions differently, like enforcing long immediates, or choosing to use a different "assembler fingerprint".

In this vision the options could be set globally (like USE32 does) or just for a single instruction by adding a "decorator" to the line. For example, there could be settings called "rmdst" and "rmsrc" to select whether the instruction with "reg,reg" operands should be encoded using the "r/m,reg" opcode, or the "reg,r/m" one. It would be possible to select this option globally with line like:

Code:
use rmdst

but also it would be possible to select it just for a single instruction:

Code:
xor eax,ebx {rmsrc}



Similarly an instruction set could be selected for the whole source, but then a single instruction from an other instruction set could be assembled using the local setting:

Code:
use i286
bsr ax,bx {i386}

Some other examples of what I had in mind:

Code:
add eax,0 {imm32; like "add eax,dword 0" in fasm 1
loadall {i286; like loadall286 in fasm 1


These are just to give an general idea of what my plans for fasm 2 were, the actual implementation could end up different. At the time when I first envisioned these ideas braces were not used in any of the Intel assembly syntax. This changed with AVX-512 and perhaps if I was to implement these ideas nowadays, I would reconsider the syntactic choice. But I do not really see myself starting such project anytime soon. Or perhaps I would start working on a set of macros for fasmg that would have it all.
Post 02 May 2017, 22:00
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.