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?

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

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

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

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...

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.

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.

here is my basic suggestion about what the library could be.

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.

My opinions:
1. Name: FASM Standard Library
2. Working name: FASMLIB
3. About macropack I agree to everything you wrote
4. Routinepack:
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
In my opinion there should be only two version at most. One optimized for size and one optimized for speed
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
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
I agree at 100%. I used such naming in my latest programs and I think it is a great idea

6. Coding
In fact I think only 'iglobal' and 'uglobal' macroses would be needed, because every pack can need its own data
Hmm... I don't that lack of tabs is good. I think it should be like this "TAB_instruction_TAB_arguments", eg.:
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.:

I agree to the rest of your statements

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.

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 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 - there's no need of pressing shift . 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'
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:

or

?

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


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

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.

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.



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.

Yes, you're right of course . 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?

I set up a poll covering the options. Let's see what the FASM community prefers

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 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")


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)

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.

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