flat assembler
Message board for the users of flat assembler.
Index
> Main > flat assembler 1.65.20+ Goto page 1, 2 Next |
Author |
|
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 |
|||
25 Apr 2006, 10:47 |
|
Tomasz Grysztar 25 Apr 2006, 11:58
|
|||
25 Apr 2006, 11:58 |
|
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 |
|||
25 Apr 2006, 12:25 |
|
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 |
|||
25 Apr 2006, 15:53 |
|
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.
|
|||
27 Apr 2006, 09:19 |
|
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 _________________ When We Ride On Our Enemies support reverse smileys |: |
|||
27 Apr 2006, 10:19 |
|
vid 27 Apr 2006, 10:44
great!
btw, what is x86 mac support? |
|||
27 Apr 2006, 10:44 |
|
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. |
|||
27 Apr 2006, 11:21 |
|
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?
|
|||
27 Apr 2006, 12:16 |
|
Tomasz Grysztar 27 Apr 2006, 12:41
Indeed, Mach-O support is on the way.
|
|||
27 Apr 2006, 12:41 |
|
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.
|
|||
28 Apr 2006, 06:26 |
|
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, |
|||
28 Apr 2006, 17:40 |
|
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.
|
|||
28 Apr 2006, 19:19 |
|
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. |
|||
28 Apr 2006, 20:36 |
|
LocoDelAssembly 29 Apr 2006, 03:11
:O Thanks for the explanation and the fix
|
|||
29 Apr 2006, 03:11 |
|
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
|
|||
29 Apr 2006, 18:11 |
|
Tomasz Grysztar 29 Apr 2006, 22:29
Fixed.
|
|||
29 Apr 2006, 22:29 |
|
vid 01 May 2006, 21:09
btw, how about things like jmp pword? is it jmp far?
|
|||
01 May 2006, 21:09 |
|
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.
|
|||
04 May 2006, 07:16 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.