flat assembler
Message board for the users of flat assembler.

Index > High Level Languages > Standard Library for FASM?

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



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
Yeah, I've heard of HLA but that's a little too high level for me. I was thinking we could have a library specification that has some commonly used routines- some OS independent, some OS dependent- and for each OS FASM is used on (DOS, Windows, Linux, MenuetOS, etc.) we could have the library for that. This way we could have a fairly low-level library, yet portable between the different OSs. For example, in each OS we could have a function called "print" that prints something on the screen using the system calls/APIs of that OS. We could use either macros, such as

print "Hello, World!"

or function calls, such as

mov ax,hwstring
mov bx,strlength
call print

we would have one for each OS FASM is used on. Of course, some would use 32-bit and some would use 16-bit, but since the libraries are low-level that's OK.

We would also have OS-independent routines such as mathematical ones, etc. Of course, these could use system calls if such system calls exist and if those system calls would be faster- but how they work does not change how they are called, etc.

What do you think?

_________________
FASM Rules!
OS Dev is fun!
Pepsi tastes nasty!
Some ants toot!
It's over!
Post 09 Jun 2005, 18:27
View user's profile Send private message AIM Address Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
I think that is a great idea. I thought about it some time ago. I even started to create my own library and have some procs like: atof, ftoa, itoa, atoi, sprintf, strlen, .... There is also a polish project called asmpak which is downloadable on www.ctrl-d.prv.pl, but sources are in MASM.

If such an idea would be appreciated by more people I can also particpate in coding
Post 09 Jun 2005, 18:37
View user's profile Send private message Visit poster's website Reply with quote
coconut



Joined: 02 Apr 2004
Posts: 326
Location: usa
coconut
the asmpak contains very clean code - not any of the stranger masm stuff. it doesnt look like many changes will need to be made to convert to fasm syntax
Post 09 Jun 2005, 18:47
View user's profile Send private message Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
Yes, asmpak is quite good, but we should standarize it. In asmpak, some proces are given parameters via registers in others via stack. Some preserve ebx, esi, edi, some do not. Also if we want to have completly independent code we should have asm64 version I think
Post 09 Jun 2005, 18:54
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
Sometime ago there was similar idea (and an attempt to code such library). But I don't think that many of us use it now... we could start again, involve more people, and code something really good.
asmpak it is rather a collection of snippets than a library. So it doesn't have conventions about preserving registers, passing parameters etc. Of course we would have to discuss them, as well as some conventions for function names...
Post 09 Jun 2005, 19:32
View user's profile Send private message Visit poster's website Reply with quote
coconut



Joined: 02 Apr 2004
Posts: 326
Location: usa
coconut
so, where do we start?
Post 09 Jun 2005, 22:15
View user's profile Send private message Reply with quote
Kain



Joined: 26 Oct 2003
Posts: 108
Kain
coconut wrote:
so, where do we start?


At the very beginning: Memory management.
The routines should probably be called via macros and a compile-time constant will determine which version of the routine to call (16/32/64 bit).

If some code examples are needed, the HLA (and the HIDE package) can compile the HLA standard library into FASM syntax (format COFF). The HLA standard library is already Win32/linux compatible.

_________________
:sevag.k
Post 09 Jun 2005, 22:37
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i think making that project such high-ranged to handle 16/32/64 code would make it overbloated and sloppy. Let's just make 32bit library, 16bit wouldn't be used a lot anyway, just like 64, and these can be added easily later.

And we should start by defining internal hierarchy, naming standard, calling standard, coding standard, commenting standard, filenaming/directories standard, cooperation with privalov's standard macros, priority of modules (what to code first), etc etc

In my opinion we should first find out all these categories. Then we should find out what are possibilities for each of these categories. When we sould make a poll where people will vote for best of them. Onlt then we can go on to coding. This will require one thread for choosing such categories, then two threads for each category (one for proposing possibilites and later one with poll for voting for them). I think if we really want to go on with this it should even have it's own section in board, if it's to be taken seriously we'll need many topics.

I think such thing would finally give the last hit to other assemblers - clear unique standard library.

btw, fresh will have to undergo MANY changes then, i think it won't be usuable for a very long time.
Post 10 Jun 2005, 20:49
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
here is my basic suggestion about what the library could be.


Description:
Download
Filename: FASMLIB.ZIP
Filesize: 3.54 KB
Downloaded: 690 Time(s)

Post 11 Jun 2005, 12:34
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Guest





Guest
i think that a specific forum for this library is needed, second the library
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.
about the calling convention we should use many calling conventions to proffit the power of assembly, some times is better to use the stack for parsing parameters and some times is better to use registers.
Most of us already have our own library ,the problem is with standarization, we need to decide the names and the routines that should form this library , something like the poxis standard. Actually is the lack of a good library what makes assebly difficult than HLLs.
Post 11 Jun 2005, 13:26
Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
My opinions:
1. Name: FASM Standard Library
2. Working name: FASMLIB
3. About macropack I agree to everything you wrote
4. Routinepack:
Quote:
- Routinepack is not dividable (eg. you have to include it whole)
I think that in all of our routine packs we shall use a 'proc' macro to avoid including routines which are not used at all. Then, even if one included whole pack, only the routines he used will be assembled
Quote:
? more routinepacks on same problem? How to solve it if user includes both?
In my opinion there should be only two version at most. One optimized for size and one optimized for speed
Quote:
? Will routinepacks declare variables to be directly accessed by user?
I think that routines shouldn't declare data for user. Any global data declared in a pack should be used only internally by this pack. Global data that is needed by pack and is accessed by user should be passed as an argument to current function
I agree to rest of statements

5. Naming coventions
Quote:
let us not forget about exception, like "PROC" everyone is used to have it uppercase
In fact I got used to lowercase version while using fasm, but that's not a problem
I dont' have currently any idea concerning macro naming. I wiil post something here later
Quote:
- I think procedures should have name of routinepack plus dot as prefix. We could use "_" instead of ".", but i think this is what "." in name should mean and is right at it's place here.

- Names of routinepacks and procedures should be capitalized, so we will have names like "Mem.Alloc", "OpenGL.InitSomething" etc.
I agree at 100%. I used such naming in my latest programs and I think it is a great idea

6. Coding
Quote:
- Keep it raw (like FASM's sources). Use macros only when they really have effort on readability of code.
In fact I think only 'iglobal' and 'uglobal' macroses would be needed, because every pack can need its own data
Quote:
- lowcase instructions, no tabs (?) - there are problems with those in some viewers.
Hmm... I don't that lack of tabs is good. I think it should be like this "TAB_instruction_TAB_arguments", eg.:
Code:
        ;       comment
        invoke  ShowWindow, [hWnd], SW_SHOW
        mov     eax, 4    
And also I always put space after coma ',', but it can be done as anyone likes it
About wraping. I think that we can define that everyone should wrap code on 81 byte so that every line has 80 bytes. I use such coding style (also concerns comments). Such code should be readable on most viewers, eg.:
Code:
        ;       this is such a long comment that it does not fit on eighty
        ;       bytes unfortunately
        mov     eax, 1
        add     eax, 2
        sub     ecx, 3
        shr     eax, 8          ; 8 is eight, and I must comment it so it
                                ; doesn't fit 80 bytes
        add     eax, 128    

I agree to the rest of your statements
Post 11 Jun 2005, 14:32
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
I won't be one of the ones using a standard library for fasm, but I do have a question: why not allow the macro and routine packs include their dependencies automatically? You can still alert the user, but it does make things simpler for the programmer.
Post 11 Jun 2005, 15:06
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Quote:
Hmm... I don't that lack of tabs is good. I think it should be like this "TAB_instruction_TAB_arguments", eg.:


Tabs are a problem for some editors and viewers. Using spaces is better IMO since the source will look the same on all viewers and not cause problems with editors that don't support tabs well.
Post 11 Jun 2005, 15:08
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
crc wrote:
Quote:
Hmm... I don't that lack of tabs is good. I think it should be like this "TAB_instruction_TAB_arguments", eg.:


Tabs are a problem for some editors and viewers. Using spaces is better IMO since the source will look the same on all viewers and not cause problems with editors that don't support tabs well.

As for me, this "TAB_instruction_TAB_arguments" is the best and clearest way of writing assembly code. Replacing TABs with spaces will require a lof of additional bytes, and placing unnecessary data is not what assembly programmers do Wink Anyway, AsmEdit can display tabs properly, and proably most of us use this program for coding, so tabs aren't a problem.

About names, I prefer writhing them in lowercase_with_underlines. Why? because I can write them faster Wink - there's no need of pressing shift Very Happy. Of course, all names can't be written this way, to avoid confusions. My suggestion is:

lowercase_with_underlines - for proc names, variables etc. Generally there should be no global variables shouldn't be available to users (only a few that are necessary).
lowercase_with_underlines - for macros. Usually most of macros are one word, and they will be used rarely, so nobody will confuse them. Anyway include_all_globals doesn't look so bad. And I would hate it if I have to write "PROC" instead of 'proc' Wink
UPPERCASE_WITH_UNDERLINES - for constants, just like in WinAPI.

Just like it was written above, I think that library should target 32bit systems only. Functions should work on any (or almost any) 32-bit system. Of course there will be some dedicated routines, like some wrappers for WinAPI.
Macro library: I agree that macros shouldn't be used so often. iglobal...endg is still the best way of declaring variables, but I see no reason in using '.if's. Macro libary should be more or less compatible with the one that comes with FASMW. Only one thing about procedures: do you prefer:
Code:
proc my_function, arg1, arg2    

or
Code:
proc my_function, .arg1, .arg2    

?

in second version, dots prefixing argument names visibly mark that those variables are locals on stack.

Quote:
Routinepack is not dividable (eg. you have to include it whole)

no, why to compile whole library everytime, even if program uses only string routines? Some macro can allow very elegant declaration here:
Code:
uselib stringlib,memlib,etc    

files stringlib.inc and memlib.inc would be included automatically with this macro.

Next thing that comes to my mind is calling conventions. Obviously, we should use stdcall. But with some exceptions, functions like printf, have to use C convention, but this will be marked in documentation.
Post 11 Jun 2005, 16:08
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Quote:
As for me, this "TAB_instruction_TAB_arguments" is the best and clearest way of writing assembly code. Replacing TABs with spaces will require a lof of additional bytes, and placing unnecessary data is not what assembly programmers do. Anyway, AsmEdit can display tabs properly, and proably most of us use this program for coding, so tabs aren't a problem.


I don't consider spaces to be unneccessary data. Any form of whitespace is helpful to aid in readability. Quick question: What OSes does AsmEdit run on? I often work Linux, FreeBSD, and BeOS, so I need a consistent editor on all of these OSes.

Quote:
About names, I prefer writhing them in lowercase_with_underlines. Why? because I can write them faster Wink - there's no need of pressing shift


Interesting. To type an underscore on all the keyboards I have, I have to press shift anyway. So for me (and most others I know), it's more typing in the end.
Post 11 Jun 2005, 16:21
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
Smile

Yes, you're right of course Embarassed. But for me, it is just easier to type a name with underscores than with mixed case letters... maybe because I'm used to write like this.
Anyway it is just my opinion, if others will agree to another convention, I will use it... maybe some poll will help to decide?
Post 11 Jun 2005, 16:30
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
I set up a poll covering the options. Let's see what the FASM community prefers Smile
Post 11 Jun 2005, 16:53
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
So what we for sure need to discuss:

1. tabs/spaces in code. I suggest poll "what would you prefer" with possibilities:
mov ax, bx <spaces> ;comment
mov ax, bx <tabs> ;comment
mov <tab> ax,bx <tab> ;comment
mov <spaces> ax,bx <spaces> ;comment
<tab> mov <tab> ax,bx <tab> ;comment
<spaces> mov <spaces> ax,bx <spaces> ;comment

2: macronames,
includeallglobals, proc
INCLUDEALLGLOBALS, PROC
include_all_globals, proc
INCLUDE_ALL_GLOALS, PROC
IncludeAllGlobals, Proc
includeAllGlobals, proc
iNCLUDEaLLgLOBALS, pROC Smile not really

to me capitalized from second word (includeAllGlobals) seems best to keep one-word macro lowcase (many are used to this), and multiword names are finely readable and differentiatd from names of other things.

3. Procedure names.
Pack_SomeProcedure
Pack.SomeProcedure
pack.SomeProcedure
Pack.some_procedure
pack.some_procedure
etc.
decard: I suppose us keyboard layout as default, where "." is much easier to write than "_" and i always keep my left hand over shift, so Pack.SomeProcedure is no problem to write.

4. IF we need to declare variables in routinepacks. I think this is problem we can properly solve later, when we have analyzed few routinepacks and see if it would be of some use.

5. Include by default - i don't like this, because you don't know what you are really including, and you have to prevent double-including of file. But we can vote on this too, but after careful thinking on pros on cons on both.

names "macropack" and "routinepack" aren't very good, especially for "routinepack". It could be "procpack", or someone could even suggest better word than "pack", i used it only for lack of terms. ("library" wouldn't be good to use, library should be set of such "packs")

Quote:

Quote:
Routinepack is not dividable (eg. you have to include it whole)

no, why to compile whole library everytime, even if program uses only string routines? Some macro can allow very elegant declaration here

No, you wouldn't have to recompile whole library. library is set of routinepacks, so you will do
useroutinepacks string, ddraw, opengl, h4x0rz
Seems we want same thing, you just misunderstood me.

6. Calling convention:
registers only with preserving
registers only without preserving
stdcall with all regs preserved
stdcall with no regs preserved
ccall/stdcall with all regs preserved
ccall/stdcall with no regs preserved
reg only mixed with ccall/stdcall with all regs preserved
reg only mixed with ccall/stdcall with no regs preserved
well, i think to keep clearness it should be like decard said, only problem is preserving of registers. Always preserving of all registers will make usage of library much much much easier, but also means some loss of speed of library. I think it is worth of it.
Return in EAX always of course (for 8 and 16 bit values rest is zeroed/sign extended)
Post 11 Jun 2005, 18:12
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
coconut



Joined: 02 Apr 2004
Posts: 326
Location: usa
coconut
the fasm source to me is the most clearest and beautiful form of coding ive ever seen. i say we adopt that style for the fasmlib.

also: im not familiar with other operating systems, but certainly on windows (and to me most other OS's) i think theres no excuse why any modern day editor does not support tabs properly. to me a fundamental part of readability is tabbing between the instructions and operands.
Post 12 Jun 2005, 01:06
View user's profile Send private message Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
I think that only esi, edi, ebx, ebp should be preserved as this is needed by windows. Also one thing that no one told before. What to do if a proc returns more than one thing? For me the best soultion is to declare a structure and return values in it. I don't want any return value in ecx, edx, or any other, because I think that our lib can be easily adopted to static lib using 'format MS COFF' and then I would surely use such lib with my C/C++ programs. Of course any HLL compiler gets returned value only in eax

Adapting our code to HLL compilers also forces us not to pass any argument via registers. It can be done only by stack.

The calling convention is not so important as nowadays any compiler can create STDCALL and CCALL code so it's just a matter of correct header files and documentation. Of course it's better when it's unified, so I personally prefer stdcall. I would use ccall only where it's neede as in printf for example


Last edited by Reverend on 12 Jun 2005, 09:39; edited 1 time in total
Post 12 Jun 2005, 09:21
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, 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 YouTube, Twitter.

Website powered by rwasa.