flat assembler
Message board for the users of flat assembler.

Index > High Level Languages > Standard Library for FASM?

Goto page Previous  1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
And what if procedure returns 64-bit value? Then IMO it should be returned in eax:edx... Proably the choice should be left for the coder. We can't standarize everything - it is FASM Library, not European Union Wink
Post 12 Jun 2005, 09:26
View user's profile Send private message Visit poster's website Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
But imagine you would want to use such proc in your C program. How will you get the 64-bit value? Using inline? It's not "clean"
Post 12 Jun 2005, 09:42
View user's profile Send private message Visit poster's website Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
decard wrote:
We can't standarize everything - it is FASM Library, not European Union Wink
Laughing Laughing Laughing
Post 12 Jun 2005, 12:19
View user's profile Send private message Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
OK, 32-bit-only is fine. I for one don't have a 64-bit PC and probably won't anytime soon, and 64-bit processing is a relatively new technology (in PCs anyways). 16-bit I was thinking we could have in order to be compatible with old stuff, but if it's too much we don't have to.

I generally like to design my libraries such that they can be included at the beginning of the program without problems (I like C)- of course, some executable file formats include a starting offset, so this is useless- by having a JMP at the beginning of the file, to a label at the end of the file. Should we do this?

Here's the plan:
We simply make one library for each OS, with the same procedure and variable and constant names where possible. That's what I mean by standard. That way, for any OS, you use the same procedure, variable, and constant names, but simply include the library forn the OS you are compiling it for, and of course you direct FASM to use a different output file format. Using same names is mostly what I mean by standard.

Quote:
should be x86 specific but not fasm or OS specific , i mean that the coding style must be like the sources of FASM that is esay to translate to other assemblers because it uses very few special fasm features, but not like FRESH
wich abuses of macros.

I disagree. We are creating a FASM library, not a generic fits-any-assembler library. Besides, what assemblers don't have macro support?
Now I know the FASM uses different macro syntax than others, but once again, this is a FASM library. No offense, but you have no say in this anyways until you register!

Goals:
-Standard everything. This way, you only have to include a different library file and modify your code minimally or not at all (depending on what OS and what it does) to port between OSes.
-Efficient. I'm no expert on optimization, I'll admit, and we want our code to be at least semi-understandable. However, with comments and using the standard optimization methods we can at least make it decently small and fast. Once again, however, we can't use such extreme optimization methods so as to completely obfuscate everything.
-Open Source. Since I mentioned above that it shouldn't be obfuscated, it should be obvious that it will be OS. If anyone doesn't like that idea, tell me, but since we're all using FASM I think most of us will agree OS is the way to go. Besides, I don't want to do all the complicated linking stuff, and I don't want a DLL- it should be a ".inc" file, or more likely, a whole bunch of ".inc" files.
-Useful. We don't need any obscure rarely-used or never-used routines such as a routine to convert a decimal number to a base-6 number.
We want a slim, trim, useful and useable library that doesn't significantly increase the size of the program which uses it.
-Modulization. If you don't need certain functions, you shouldn't have to include them- there should be many modules, such as "math.inc", "general.inc", "optimize.inc", etc.

These of course are negotiable and we should continue talking about it. When we know what we want we'll get started.

This may seem like a lot of work- that's precisely why many people should help. We can all (well, pretty much. I guess crc apparently can't)benefit from this, so let's all help. We have to come up with the specs first, in order to make sure each they are all the same.

I would prefer to use the stack for passing parameters, as there
are a limited and fixed number of registers. But, as with everything else, this is negotiable. I'm not the boss and if everyone helps then everyone gets input, etc.

Let's do this thing!
Post 14 Jun 2005, 23:28
View user's profile Send private message AIM Address Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Quote:
This may seem like a lot of work- that's precisely why many people should help. We can all (well, pretty much. I guess crc apparently can't)benefit from this, so let's all help.


I'm willing to help develop the macros and routines, even if I don't plan to use them. (For what it's worth, I maintain my own set of macros and routines. This is essential due to the internal design of my applications).
Post 15 Jun 2005, 01:12
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
i agree with THEWizardGenius mostly. I think the standard should start being written. Someone (who is often online) should be chosen to keep it somewhere. i suggest thread (or even section, in thinking to future), for example - "FASM Standard Library - General Standard", where one post will try to summarize standard. People will submit there and moderator will often update standard as we agree on anything.

Privalov - willing to make such section?
Post 15 Jun 2005, 13:04
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: 7796
Location: Kraków, Poland
Tomasz Grysztar
I suggest the thread for now - if then we see it's not enough, we may think of a section.
Post 15 Jun 2005, 13:15
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
We could use parts of old FASM library - it was maintained by aaro, although the project was stopped I think. Maybe aaro take part in this project too...
Now let's decide how macro library should look. I have created topic about it in main section.
Post 15 Jun 2005, 13:23
View user's profile Send private message Visit poster's website Reply with quote
aaro



Joined: 21 Jun 2003
Posts: 107
Location: hel.fi
aaro
Project was stopped because of hard drive failure where i lost the newest version of the project, which had much more code than the version you can download from the board. If you wish you can freely use anything from the package.

If you use my string functions i recommend that you modify those so there's one more parameter in all of them, that's pointer to buffer for new string. Now they allways allocate new string, i suggest you do that only when the pointer to new string is 0.
Post 15 Jun 2005, 19:39
View user's profile Send private message Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
I would be willing to use his code, though I haven't looked at it yet, but it might make more sense just to write our own code.
Post 17 Jun 2005, 03:30
View user's profile Send private message AIM Address Reply with quote
mrpink



Joined: 03 Jun 2005
Posts: 27
Location: Germany
mrpink
Hello guys,

can anybody tell me about the status of this project?
Post 17 Oct 2005, 13:37
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
dead. nobody to write it.
Post 17 Oct 2005, 16:31
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
S**t, I've totally forgotten about this project, shame on me Embarassed
I am eager to code it, but once again we should gather more coders, they should all agree to code it and start it now, not later as the project may really die in its infancy. And I guess it's not what we want.
Post 17 Oct 2005, 18:40
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
What about creating simple set (library) of functions, without dedicated macro library?
Post 17 Oct 2005, 19: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
i think we cannot go ithout any macro. we need at east idata and udata. So how about this:
1. "idata" and "udata" (whatever they are called) must be declared by user of library
2. arguments in registers, return values in registers
3. assume CS=DS=ES (flat model)
4. preserve all registers except those which return values
5. as few special features as possible (like FASM source)

i think this is easiest "standard" to start writing routines. about the routines IMHO memory & string libraries are the most commonly needed ones and good to test our concept. we can change naming & other stuff easily later. okay?
Post 17 Oct 2005, 20:19
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Kain



Joined: 26 Oct 2003
Posts: 108
Kain
Have the basics been decided?

1. Should it be cross-platform?
2. How to pass arguments?
3. register thrashing

My own votes on this would be:
1. yes, otherwise it wouldn't be "standard" Smile

2. stack
This may not be the fastest, but it beats having to remember which arguments go in which registers.

3. If library is for only Windows preserve ABI, otherwise preserve all except registers used to return values.
Post 18 Oct 2005, 02:30
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
1. yup
2. not decided
3. preserve - we want to use it in assembly

i think using stdcall stack is fine. but generally, to allow us start writing code, we can say it can be however creator decides
Post 18 Oct 2005, 08:00
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
1. Of course. We just have to avoid using (or better forbid) APIs.
2. STDCALL or CCALL for sure. Using registers makes our lib useless for HLLs.
3. Preserve all except eax, ecx, edx

So maybe I'll start. I wrote my 'itoa' proc, it is in the attachment and also posted here. Maybe when we have a real proc written we can easier get to solution:
Code:
iglobal
  d_itoa_digits                 db '0123456789ABCDEF', 0
endg

proc    itoa                    number, radix, result_buffer, signed
  locals
    temp_buffer                 rb 32+1
  endl
        push    esi edi ebx
        mov     esi, [radix]
        lea     edi, [temp_buffer+32]
        mov     ebx, d_itoa_digits
        std
        xor     al, al
        stosb
        mov     eax, [number]
        cmp     [signed], TRUE
        jnz     @F
        test    eax, 80000000h
        jz      @F
        neg     eax
    @@:
        xor     edx, edx
        idiv    esi
        xchg    eax, edx
        xlatb
        stosb
        xchg    eax, edx
        test    eax, eax
        jnz     @B
        lea     esi, [edi+1]
        mov     edi, [result_buffer]
        cld
        cmp     [signed], TRUE
        jnz     @F
        test    [number], 80000000h
        jz      @F
        mov     al, '-'
        stosb
    @@:
        lodsb
        stosb
        test    al, al
        jnz     @B
        pop     ebx edi esi
        ret
endp    

How it works:
Code:
        push    FALSE
        push    buffer
        push    10
        push    128
        call    itoa ; result = '128'

        push    FALSE
        push    buffer
        push    10
        push    -128
        call    itoa ; result = '4294967168'

        push    TRUE
        push    buffer
        push    10
        push    128
        call    itoa ; result = '128'

        push    TRUE
        push    buffer
        push    10
        push    -128 ; result = '-128'
        call    itoa    


In this code:
- used 'iglobal' macro
- data labels are defined like this: 'd_' # PROC_NAME # LABEL_NAME so like: d_itoa_digits, d_memcpy_blah, ...
- word 'proc' is in lowercase
- proc name is in lowercase as all other local variables and arguments


EDIT: Btw. there was some discussion about whether to use tabs or spaces. When using fasmw, we can disable 'Optimal fill on saving' and then there will be noe tabs, as all tabs will be converted to spaces


Description: itoa proc
Download
Filename: itoa.asm
Filesize: 687 Bytes
Downloaded: 433 Time(s)

Post 18 Oct 2005, 13:08
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
reverend - preserve all registers! (except those which hold return value - usually EAX) not preserving ECX & EDX is hell to use.
naming will be important later... but generally if routine is called "itoa" then everything could be called "itoa.digits" etc. just define as few things as possible.
Post 18 Oct 2005, 14:28
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
vid wrote:
but generally if routine is called "itoa" then everything could be called "itoa.digits" etc. just define as few things as possible.


That's a good point!


Quote:
1. "idata" and "udata" (whatever they are called) must be declared by user of library

So let's use standard FASM macro library + globals.inc from Fresh. Then library could be compiled with both FASM and Fresh libraries.
Post 18 Oct 2005, 14:36
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 Previous  1, 2, 3, 4  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.