Message board for the users of flat assembler.
> High Level Languages > Standard Library for FASM?
Goto page 1, 2, 3, 4 Next
THEWizardGenius 09 Jun 2005, 18:27
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
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?
OS Dev is fun!
Pepsi tastes nasty!
Some ants toot!
|09 Jun 2005, 18:27||
Reverend 09 Jun 2005, 18:37
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
|09 Jun 2005, 18:37||
coconut 09 Jun 2005, 18:47
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
|09 Jun 2005, 18:47||
Reverend 09 Jun 2005, 18:54
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
|09 Jun 2005, 18:54||
decard 09 Jun 2005, 19:32
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...
|09 Jun 2005, 19:32||
coconut 09 Jun 2005, 22:15
so, where do we start?
|09 Jun 2005, 22:15||
Kain 09 Jun 2005, 22:37
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.
|09 Jun 2005, 22:37||
vid 10 Jun 2005, 20:49
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.
|10 Jun 2005, 20:49||
vid 11 Jun 2005, 12:34
here is my basic suggestion about what the library could be.
|11 Jun 2005, 12:34||
Guest 11 Jun 2005, 13:26
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.
|11 Jun 2005, 13:26||
Reverend 11 Jun 2005, 14:32
1. Name: FASM Standard Library
2. Working name: FASMLIB
3. About macropack I agree to everything you wrote
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
- Routinepack is not dividable (eg. you have to include it whole)
In my opinion there should be only two version at most. One optimized for size and one optimized for speed
? more routinepacks on same problem? How to solve it if user includes both?
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
? Will routinepacks declare variables to be directly accessed by user?
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
let us not forget about exception, like "PROC" everyone is used to have it uppercase
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
- 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.
In fact I think only 'iglobal' and 'uglobal' macroses would be needed, because every pack can need its own data
- Keep it raw (like FASM's sources). Use macros only when they really have effort on readability of code.
Hmm... I don't that lack of tabs is good. I think it should be like this "TAB_instruction_TAB_arguments", eg.:
- lowcase instructions, no tabs (?) - there are problems with those in some viewers.
And also I always put space after coma ',', but it can be done as anyone likes it
; comment invoke ShowWindow, [hWnd], SW_SHOW mov eax, 4
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.:
; 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
|11 Jun 2005, 14:32||
crc 11 Jun 2005, 15:06
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.
|11 Jun 2005, 15:06||
crc 11 Jun 2005, 15:08
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.
|11 Jun 2005, 15:08||
decard 11 Jun 2005, 16:08
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:
proc my_function, arg1, arg2
proc my_function, .arg1, .arg2
in second version, dots prefixing argument names visibly mark that those variables are locals on stack.
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:
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.
|11 Jun 2005, 16:08||
crc 11 Jun 2005, 16:21
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.
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.
|11 Jun 2005, 16:21||
decard 11 Jun 2005, 16:30
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?
|11 Jun 2005, 16:30||
crc 11 Jun 2005, 16:53
I set up a poll covering the options. Let's see what the FASM community prefers
|11 Jun 2005, 16:53||
vid 11 Jun 2005, 18:12
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
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.
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)
|11 Jun 2005, 18:12||
coconut 12 Jun 2005, 01:06
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.
|12 Jun 2005, 01:06||
Reverend 12 Jun 2005, 09:21
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
|12 Jun 2005, 09:21||
|Goto page 1, 2, 3, 4 Next
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.