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

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"

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.


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!

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

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?

I suggest the thread for now - if then we see it's not enough, we may think of a section.

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.

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.

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.

Hello guys,

can anybody tell me about the status of this project?

dead. nobody to write it.

S**t, I've totally forgotten about this project, shame on me
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.

What about creating simple set (library) of functions, without dedicated macro library?

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?

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"

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.

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

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:

How it works:


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

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.

That's a good point!



So let's use standard FASM macro library + globals.inc from Fresh. Then library could be compiled with both FASM and Fresh libraries.