Index
> Main > flat assembler 1.57Goto page 1, 2 Next |
| Author |
|
|
Tomasz Grysztar 19 Jan 2005, 09:36
Now available in the Download section.
This is another cleanup release, I have separated the core variables from the interface data definitions, this should make maintaining fasm ports much easier. By finally separating the executable code from the writeable data I've made fasm run correctly on my OpenBSD machine (with Linux emulation enabled). Also Linux interface will now set executable permissions on the output file when the "format ELF executable" is selected. Last edited by Tomasz Grysztar on 12 Feb 2005, 13:20; edited 1 time in total |
|||
19 Jan 2005, 09:36 |
|
|
tom tobias 19 Jan 2005, 10:29
Thanks, always appreciated by everyone
 |
|||
|
19 Jan 2005, 10:29 |
|
|
scientica 19 Jan 2005, 16:00
an update ebuild is avalible for download, it's atteched here: http://bugs.gentoo.org/show_bug.cgi?id=78358
(you'll need to generate the digest for it if you try it - unless someone desperatly needs it I'll not write how to generate the digest here -- hopefully it'll not be long before it's in the portage... ) updates in the ebuild: * libc patch not avalible for 1.57 (at least not yet) * the permissions patch is removed (due to the changes privalov mentioned above.) * generall clean up (now uses the "unpack" - the 'propper' ebuild method since a minor packaging isse has been resolved) |
|||
|
19 Jan 2005, 16:00 |
|
|
scientica 20 Jan 2005, 23:01
good
hmm... did I do something wrong or are there (intensionall) changes to source/expressi.inc ? (namely a few removed "jc bad_number", hex_letter_digit stuff). will make an updated ebuild to morrow (to tired to do it now and getting it right, also pending above) |
|||
|
20 Jan 2005, 23:01 |
|
|
Tomasz Grysztar 20 Jan 2005, 23:10
These changes are in base packages, too. The late update, sorry.
 |
|||
|
20 Jan 2005, 23:10 |
|
|
madmatt 21 Jan 2005, 10:00
Hi Privalov,
Thanks for the update, things settling down in your life now? A question, would like to do something like this: mov [var],1.0 but it doesn't work, could this be a feature in a future version of fasm? Matt |
|||
|
21 Jan 2005, 10:00 |
|
|
Tomasz Grysztar 21 Jan 2005, 10:04
If you define "var" as double word, it does work (since earliest releases). For other floating point types (64-bit and 80-bit) there is simply no "mov" opcode that would do such work.
|
|||
|
21 Jan 2005, 10:04 |
|
|
madmatt 21 Jan 2005, 16:15
Yep, you are right, it does work, stupid me forgot to FLD the number on the fpu before printing
 
This is a nice feature to have, Hopefully you can expand this feature for 64-bit floats? |
|||
|
21 Jan 2005, 16:15 |
|
|
vid 21 Jan 2005, 22:23
he just told there isn't mov instruction for 64bit values
|
|||
|
21 Jan 2005, 22:23 |
|
|
madmatt 22 Jan 2005, 09:31
Well, yes thats true, except for the FLD instruction FLD [1.0], but that would require some special handling.
|
|||
|
22 Jan 2005, 09:31 |
|
|
gunblade 22 Jan 2005, 12:42
I've been puzzling over this, and trying to find a reason why....
but why is there a libc version of fasm? is it so that its portable to FreeBSD? (as most of the problems from porting would be the syscalls) and a very good job on the latest release privalov, and on fasm in general, beats the hell out of any other assembler  |
|||
|
22 Jan 2005, 12:42 |
|
|
Tomasz Grysztar 22 Jan 2005, 15:32
Quote: Well, yes thats true, except for the FLD instruction FLD [1.0], but that would require some special handling. The FLD instructions don't use immediates - and there is no instruction that would use 64-bit immediate at all in the IA-32 architecture. If there was one, fasm would allow using 64-bit floating point value there automatically, since its internals are designed this way. And the "fld [1.0]" for fasm means the FLD with memory operand, with address defined by 32-bit floating point value (this is useless, but works because of the fact that fasm allows floating point values as immediates everywhere where possible, as it was already noted above), so is the same as "fld [3F800000h]", only the size operator is missing, since there are different FLD variants. |
|||
|
22 Jan 2005, 15:32 |
|
|
vid 22 Jan 2005, 16:19
really, what is this feature (floating point number as address) good for?
|
|||
|
22 Jan 2005, 16:19 |
|
|
Tomasz Grysztar 22 Jan 2005, 16:24
Nothing I'm aware of - it's just needed for some macros to pass the parsing stage without an error message. And it completes the fasm's logic.
|
|||
|
22 Jan 2005, 16:24 |
|
|
madmatt 22 Jan 2005, 20:29
Well, the reason I ask is because after converting/writing the 'Windows for game programming examples", I found myself constantly scrolling up to where my variables are just to make a floating point constant, then having to scroll back down trying to remember where I left off. So this is just for convenience sake. If it is going to be to complex to implement then the mov [var],1.0 feature will be more than adequate.
|
|||
|
22 Jan 2005, 20:29 |
|
|
vid 22 Jan 2005, 23:06
privalov: so if you will adapt if-processing at parsing stage this feature will become obsolete.
|
|||
|
22 Jan 2005, 23:06 |
|
|
scientica 23 Jan 2005, 10:41
madmatt, wouldn't it be possible to take a look at "my" OpenGL macros, and make a "mov64" or "movq" macro that instead of like that glPhush-something "mov" a float instead of "push"(ing it to the stack)...
|
|||
|
23 Jan 2005, 10:41 |
|
|
scientica 23 Jan 2005, 10:48
modifying this:
Code: macro glPush2 GLfloatVar { name = GLfloatVar virtual at 0 dq GLfloatVar load name#.l dword from 0 load name#.h dword from 4 end virtual push dword name.h push dword name.l } gives (note: untested!!!): Code: macro movq variable, floatVar { name = floatVar virtual at 0 dq floatVar load name#.l dword from 0 load name#.h dword from 4 end virtual mov [variable], name.h mov [variable+4], name.l } should be used like this: Code: movq variablename, 1.0f thoug, I'd really want to beable to make it: Code: movq [variablename], 1.0f but that'd probably make the macro: Code: macro movq variable, floatVar { name = floatVar virtual at 0 dq floatVar load name#.l dword from 0 load name#.h dword from 4 end virtual push eax mov variable, name.h lea eax, variable add eax,4 mov [eax], name.l pop eax } It's proably possible to fix above in a much simpler and more elegent and in less opcodes/ticks... but I just woke up so my brain hasn't yet been reached by the coffee |
|||
|
23 Jan 2005, 10:48 |
|
|
madmatt 23 Jan 2005, 18:56
How about nameing the macro movdf so it won't get mixed up with mmx 64-bit movq. My fasm macro abilities are minimal right now, hopefully will take the time to experiment with them. And, Yes!, it is always good to have at least one FULL cup of coffee, before putting fingers to keyboard, or power switch!
While looking at your code this inspired me to write the macro below. Thanks for your help scientica 
Code: macro fldq dfloat { local mynumber jmp @f align 8 mynumber dq dfloat @@: fld [mynumber] ;more of your code here } |
|||
|
23 Jan 2005, 18:56 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|