flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.65.20+

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 25 Apr 2006, 09:54
Some important changes with how direct jumps are handler are being made with this release. I realized that allowing constructions like "jmp byte 0" is not really consistent with rules used in other places (though the real complete consistency is not really possible without going too far from the Intel syntax, but that's a different story...), and that omitting the "short" keyword was not really a good idea.

Thus the size operator no longer applies to the size of relative displacement of jump instruction, it now applies to the address size (so "jmp word" will fill just IP [clearing the upper bits], while "jmp dword" will fill whole EIP). The short jumps are now made with the "short" type, like "jmp short 0", as they should always have, the "near" type jumps are always just near (not optimized to short), and jumps without type operator are optimized just as they used to.

This approach allowed me also to correct some things with jump range checking. Here's an example of jumps that wouldn't assemble with earlier versions, but assemble correctly with fasm 1.65.20:
Code:
org 10000000h

jmp dword 0FFFF0000h

jmp word 0FF00h    


However since the jump generating code have been rewritten completely, it's possible that something doesn't assemble correctly though it used to. I checked all my sources for case of such bugs, but I may have missed something - especially the 64-bit mode has to be tested a bit more.


Last edited by Tomasz Grysztar on 31 Mar 2007, 03:55; edited 3 times in total
Post 25 Apr 2006, 09:54
View user's profile Send private message Visit poster's website Reply with quote
FlashBurn



Joined: 06 Jan 2005
Posts: 87
FlashBurn 25 Apr 2006, 10:47
Why can´t I do the following and have to code it per db´s

Code:
use16
jmp 0x08:0xc0100000
    
Post 25 Apr 2006, 10:47
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 25 Apr 2006, 11:58
In 16-bit mode the standard far jump is 16:16, to make the 16:32 form (PWORD size), do it this way:
Code:
use16
jmp pword 0x08:0xc0100000    


See also sections 1.2.5 and 2.1.6 of the manual.

PS. Actually one of my aims when writing fasm was to no more need to encode anything with DBs.
Post 25 Apr 2006, 11:58
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 25 Apr 2006, 12:25
Quote:
Actually one of my aims when writing fasm was to no more need to encode anything with DBs.

like cmp rm16, imm8 Razz

Wink
Post 25 Apr 2006, 12:25
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 25 Apr 2006, 15:53
Well, doesn't fasm generate such instruction?
Functionality point of view, again. All the problems I had where I needed to use DB to create instructions in TASM were related to OS-development etc. where you needed, like above, to make 32-bit far jumps in 16-bit mode and other such things - it was the functionality of instruction, not the particular encoding, that was required (and if we needed to differ all the encodings, what about two possible encodings of "xor reg,reg", etc.?)

And so this change for the jumps syntax is one further important step into this general direction of fasm's evolution. Note that those:
Code:
jcxz word 0
jcxz dword 0
jecxz word 0
jecxz dword 0    

are four different instructions, even from functionality point of view. Too bad I have missed this earlier.


Last edited by Tomasz Grysztar on 28 Apr 2006, 06:22; edited 1 time in total
Post 25 Apr 2006, 15:53
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 27 Apr 2006, 09:19
Since so many important fixes and additions have already been done in 1.65 development line, I'm going to make it soon into another milestone releases (1.66). This moves the official fasm's own debug info format outputting to be no earlier than 1.68 milestone, same goes for the x86 Mac support.
Post 27 Apr 2006, 09:19
View user's profile Send private message Visit poster's website Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi 27 Apr 2006, 10:19
Tomasz Grysztar wrote:
Since so many important fixes and additions have already been done in 1.65 development line, I'm going to make it soon into another milestone releases (1.66). This moves the official fasm's own debug info format outputting to be no earlier than 1.68 milestone, same goes for the x86 Mac support.



hooray, evolution ftw

Razz

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 27 Apr 2006, 10:19
View user's profile Send private message MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 27 Apr 2006, 10:44
great!

btw, what is x86 mac support?
Post 27 Apr 2006, 10:44
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
gunblade 27 Apr 2006, 11:21
Well done on the amount of progress your getting through with fasm.
Impressive work.

vid, Macs now run on x86 intel chips. So im guessing hes planning to support Macs, since the cpu will be the same, just another platform to support.

Mac's used to use a BSD-style system, dunno if they do anymore on the intels, but i dont see why not. So maybe it'll work decently with the libc version of fasm.
Post 27 Apr 2006, 11:21
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 27 Apr 2006, 12:16
I would guess x86 MACH support comes down to the executable file format... what's it called now, mach-o? Smile
Post 27 Apr 2006, 12:16
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 27 Apr 2006, 12:41
Indeed, Mach-O support is on the way. Wink
Post 27 Apr 2006, 12:41
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 28 Apr 2006, 06:26
Anyway, what I tried to say here (since about Mach-O and debug info plans you could read already in other threads), making 1.65.x into a new milestone soon is mainly because the development of those new features are sustained and will stay this way at least for month (if not more), and I don't want to leave all those imporant fixes to be still only "development" version for all this time.
Post 28 Apr 2006, 06:26
View user's profile Send private message Visit poster's website Reply with quote
quiveror



Joined: 20 Jun 2003
Posts: 34
quiveror 28 Apr 2006, 17:40
I found some errors
Code:
use16
jmp dword $
; fasm: 66h ebh feh; it should be 66h ebh fdh

jmp near dword $
; fasm: 66h e9h fbh ffh ffh ffh; it should be 66h e9h fah ffh ffh ffh

use32
jmp word $
; fasm: 66h ebh feh; it should be 66h ebh fdh

jmp near word $
; fasm: 66h e9h fdh ffh; it should be 66h e9h fch ffh
    

cheers,
Post 28 Apr 2006, 17:40
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 28 Apr 2006, 19:19
I don't undestand something, why even with that bug at least the first jmp works fine anyway? using DEBUG it works as a JMP 101 and if I execute from 100 the prefix seems to have no meaning because the jmp jumps to 101, so only one iteration executes address 100, all the following executes from 101.
Post 28 Apr 2006, 19:19
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 28 Apr 2006, 20:36
The only difference between "jmp short word" (EB-xx) and "jmp short dword" (66-EB-xx) is that the first one adds the given value (after sign-extending) to IP and clears the high 16 bits of EIP, and the second one adds the sign-extended value to the EIP. So in this case (EIP=100h) there's no difference between them, that's why it works anyway.
When the difference can be noticed? For example from address 0 "jmp short word 0FF82h" is possible, while the same with "dword" is not.

As for the bug, it's fixed in 1.65.23.
Post 28 Apr 2006, 20:36
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 29 Apr 2006, 03:11
:O Thanks for the explanation and the fix Very Happy
Post 29 Apr 2006, 03:11
View user's profile Send private message Reply with quote
quiveror



Joined: 20 Jun 2003
Posts: 34
quiveror 29 Apr 2006, 18:11
fasm 1.65.22 generates wrong opcode for 'cmpsq'. If it's fixed in 1.65.23, please ignore this. thanks
Post 29 Apr 2006, 18:11
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 29 Apr 2006, 22:29
Fixed.
Post 29 Apr 2006, 22:29
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 01 May 2006, 21:09
btw, how about things like jmp pword? is it jmp far?
Post 01 May 2006, 21:09
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 04 May 2006, 07:16
"pword" size is possible only with the "far" type (so when "pword" is given without the type operator, the far jump is assumed). "dword", on the other hand can be 16-bit far jump or 32-bit near one.
Post 04 May 2006, 07:16
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:  
Goto page 1, 2  Next

< 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


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.