flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.57

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



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
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
Post 19 Jan 2005, 09:36
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Thanks, always appreciated by everyone Smile
Post 19 Jan 2005, 10:29
View user's profile Send private message Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica
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)
Post 19 Jan 2005, 16:00
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
Here's the libc version of fasm 1.57

(obsolete attachment has been removed)


Last edited by Tomasz Grysztar on 10 Oct 2005, 21:21; edited 1 time in total
Post 19 Jan 2005, 16:47
View user's profile Send private message Visit poster's website Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica
good Smile
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)
Post 20 Jan 2005, 23:01
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
These changes are in base packages, too. The late update, sorry. Wink
Post 20 Jan 2005, 23:10
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
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
Post 21 Jan 2005, 10:00
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 21 Jan 2005, 10:04
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
Yep, you are right, it does work, stupid me forgot to FLD the number on the fpu before printing Embarassed Embarassed Embarassed Rolling Eyes
This is a nice feature to have, Hopefully you can expand this feature for 64-bit floats?
Post 21 Jan 2005, 16:15
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
he just told there isn't mov instruction for 64bit values
Post 21 Jan 2005, 22:23
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
Well, yes thats true, except for the FLD instruction FLD [1.0], but that would require some special handling.
Post 22 Jan 2005, 09:31
View user's profile Send private message Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
gunblade
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 Cool
Post 22 Jan 2005, 12:42
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 22 Jan 2005, 15:32
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
really, what is this feature (floating point number as address) good for?
Post 22 Jan 2005, 16:19
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: 7797
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 22 Jan 2005, 16:24
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
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.
Post 22 Jan 2005, 20:29
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
privalov: so if you will adapt if-processing at parsing stage this feature will become obsolete.
Post 22 Jan 2005, 23:06
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica
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)...
Post 23 Jan 2005, 10:41
View user's profile Send private message Visit poster's website Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica
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 Wink
Post 23 Jan 2005, 10:48
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
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 Wink Very Happy

Code:
macro fldq dfloat
{
     local mynumber
     jmp @f
     align 8
     mynumber dq dfloat
@@:
     fld [mynumber]
    ;more of your code here
}

    
Post 23 Jan 2005, 18:56
View user's profile Send private message 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-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.