flat assembler
Message board for the users of flat assembler.

Index > Main > Fasm Standard Library concept by vid

Goto page 1, 2  Next

Do you accept my concept for library?
Yes
83%
 83%  [ 10 ]
No
16%
 16%  [ 2 ]
Total Votes : 12

Author
Thread Post new topic Reply to topic
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Here is my suggestion for general concept of library + details to discuss. Please read it and THEN vote if you like it. If it is accepted we can start discuss details. If you don't like it please be constructive and explain why.

In texts subjects marked "-" are considered agreed or obvious (let me know if no), subjects marked "?" are to be discussed.


Description:
Download
Filename: fasmlib.zip
Filesize: 2.91 KB
Downloaded: 303 Time(s)



Last edited by vid on 18 Jun 2005, 13:40; edited 1 time in total
Post 16 Jun 2005, 08:34
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
I agree on most of your rules.

For the naming, I don't like the "__" before the name. It will be better to use the descriptive name of library section where the function has be taken, for example:
fasmlib_mem.free
flib_stat.avg
math.round

(I prefer the second, to identify the library)
Post 16 Jun 2005, 12:52
View user's profile Send private message Yahoo Messenger Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
I agree on most of your rules.

For the naming, why to reinvent the wheel? if some subroutine already exits on some HLL library we can use the same name like: malloc printf
write etc...
functions used frecuently should use a shorter name.
functions used very rarelly should use a longer or composite name like:
malloc_init or malloc.init
Don´t understand well the question about 'tabs' , is the editor program and not the user who decides where to place them, and i think it should be used only at the begining of the line. The coding style is not very important for me but in general i'm against the use of macros ,i want to make a equivalent library for Octasm and macros are difficult to translate.
And the most important ,please don´t put a copy of the GNU license before every routine like in linux sources , some people has a slow
internet connection. Laughing
Post 16 Jun 2005, 13:43
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
pelaillo: names preceeded by __ are only global names used only by library (like some temporary equ's in macro definition) that shouldn't be accessed by user directly. All local and public names in library won't have '__' of course.

vid: good point about macros with dot before name. 100% agree.
But I don't like the idea to include each part of macrolibrary separately. I don't want my program to look like this:

Code:
format PE
include '%fasmlib%\macro\struct.inc'
include '%fasmlib%\macro\globals.inc'
include '%fasmlib%\macro\proc.inc'
include '%fasmlib%\macro\win32.inc'
include ... and so on    


I prefer only including one file with macros. There are several reasons for that:
1. FASM Lib programs should be easy to read and write (including only one file will save a few lines).
2. Each library can depend on any part of macro library. User would have to know all dependencies and include required files.
3. Including unused routines is not a reason: nothing unused won't be present in output file, and FASM preprocessor is fast enough so there will be no noticeable difference in compile code.
Post 16 Jun 2005, 14:52
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Quote:

if some subroutine already exits on some HLL library we can use the same name like: malloc printf write etc...

That's the point, to identify procedence of functions used (ie. you have a malloc implemented and in other parts of your code you use flib_mem.alloc)

A side note: I hope the fasmlib won't have printf and relatives implemented. imho this kind of functions is one of the worst inventions in the programming history, their advantages don't justify the drawbacks. I prefer a more assembly way of doing things.
Post 16 Jun 2005, 16:25
View user's profile Send private message Yahoo Messenger Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
I agree with both Vid and Pelaillo, and hope that one can avoid bloat, and improve readability. To that end, I would argue, perhaps not in harmony with anyone else on the forum, AGAINST using underscore _ or period . or any other punctuation element for:
macro,
data structure,
variable name,
procedure,
assembler directive,
instruction.
A good program, UNLIKE good code, is eminently READABLE. Where does the underscore nonsense originate? Yup, C, forty years ago. Late 60's. Why are we compelled to continue with that tradition??? It is so childish to me. Get rid of punctuation and improve readability. regards, tom Smile
Post 16 Jun 2005, 18:35
View user's profile Send private message Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
I agree with everything, including underscore prefixes.
However, even better than underscores might be something like "flib_" or something like that preceding each variable, unless this is too long. That way the programmer can still use the "__" prefix but not the "flib_" prefix.
I would suggest that macros begin with a "fmac_" prefix.
I thought it was humorous but possibly confusing that you called the programmer "the user" in naming.txt.
Also, I do think we should comment certain things. The FASM source code isn't over-commented, but it may be undercommented. To understand what one block does you have to read what other blocks do. Therefore, we should comment whenever procedure calls are made, whenever bitfields are used, etc.

I believe code should always be clean. If a function cannot be implemented right away, a stub function should be implemented which sets CF (or some other error flag/code) and returns. The coders should never use dirty code as this cleanups may never happen and dirty code makes maintenance and debugging difficult. Plus, if we want people to be able to read the code, dirty code isn't what we want.

Other than that, I pretty much agree with it. Here is a modified version where I clarified some things, fixed some spelling errors, and added a couple of my own things. If we want to do this the concept documents must be easy to read and understand, and free of spelling errors.

Our next step should be to decide on variable names and procedure names, correct? We need to decide what to call things to ensure that the
OS-specific modules are all at least 99% compatible.
I think I'll start a website (I'll use NetFirms) and I'll make a page for this proposed library

_________________
FASM Rules!
OS Dev is fun!
Pepsi tastes nasty!
Some ants toot!
It's over!


Last edited by THEWizardGenius on 17 Jun 2005, 16:55; edited 1 time in total
Post 17 Jun 2005, 02:51
View user's profile Send private message AIM Address Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
OK, It's http://fasmworld.netfirms.com/ and I'll be working on it (it may not be finished when you read this- if not, check a little later).
Post 17 Jun 2005, 03:10
View user's profile Send private message AIM Address Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
? Library should be same one on all systems, preserving FASM's feature to
generate same output from same source. This implies having mulptiple
versions of some modules (for different OSes) in library.

Shouldn't it be obvious - I think that BIN2ASC or HEX2DEC conversions or matrix translations are just processor specific (we are all using IA32/64) and not OS specific. We are not going to include GUI helpers, are we?
Post 17 Jun 2005, 08:25
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Octavio wrote:

For the naming, why to reinvent the wheel? if some subroutine already exits on
some HLL library we can use the same name like: malloc printf
write etc...
functions used frecuently should use a shorter name.
functions used very rarelly should use a longer or composite name like:
malloc_init or malloc.init

I agree there are some common names like "malloc" which could realy be shorter.
But these should be rare exception. I think we should vote about this later.

Octavio wrote:

Don´t understand well the question about 'tabs', is the editor program and not
the user who decides where to place them, and i think it should be used only at
the begining of the line.

No user is one who decides, otherwise it is a bad program. But some viewers have
problems with tabs. Again, thing to be voted for later.

Octavio wrote:

Don´t understand well the question about 'tabs', is the editor program and not
The coding style is not very important for me but in general i'm against the
use of macros ,i want to make a equivalent library for Octasm and macros are
difficult to translate.

I also don't want big use of macros, but at some places they are realy worthy.
Did you thik about integrating privalov's preprocessor module into your asm?

Octavio wrote:

please don´t put a copy of the GNU license before every routine like in linux
sources , some people has a slow internet connection.

Another good point, license. I suggest public domain. By the way: 50% of time i
am on dial-up, too.

Decard wrote:

But I don't like the idea to include each part of macrolibrary separately. I
don't want my program to look like this:
Code:
format PE 
include '%fasmlib%\macro\struct.inc' 
include '%fasmlib%\macro\globals.inc' 
include '%fasmlib%\macro\proc.inc' 
include '%fasmlib%\macro\win32.inc' 
include ... and so on
    

I prefer only including one file with macros. There are several reasons for that:
1. FASM Lib programs should be easy to read and write (including only one file
will save a few lines).
2. Each library can depend on any part of macro library. User would have to
know all dependencies and include required files.
3. Including unused routines is not a reason: nothing unused won't be present
in output file, and FASM preprocessor is fast enough so there will be no
noticeable difference in compile code.

i usually have one separate file with all includes, it's easier than to list
them elsewhere. Or better, such file could be part of library, like privalov's
includes. User then can decide if he want to include everything or just things
he need. I think there's no reason to disallow this possiblity to user.

tom tobias wrote:

To that end, I would argue, perhaps not in harmony with anyone else on the
forum, AGAINST using underscore _ or period . or any other punctuation

how would you want multi-word names then: "openglcreatevortexmatrix", or "ocvm"?

THEWizardGenius wrote:

However, even better than underscores might be something like "flib_" or
something like that preceding each variable, unless this is too long. That way
the programmer can still use the "__" prefix but not the "flib_" prefix.

"__" is standard in many languages, it's easier to write for developer if
library and easier to read for someone studying library contents. Also it's
meant for macros, in modules you have module name prefix. Also "fmac" is
quite unclear.

THEWizardGenius wrote:

I thought it was humorous but possibly confusing that you called the programmer
"the user" in naming.txt.

user of the library, word programmer doesn't imply he uses library.

THEWizardGenius wrote:

Our next step should be to decide on variable names and procedure names,
correct? We need to decide what to call things to ensure that the OS-specific
modules are all at least 99% compatible. I'll start a website (I'll use
NetFirms) and I'll make a page for this proposed library

You're too fast, not yet. We haven't solved all problems. Also if this project
really starts, i believe it will be hosted on FASM's site.
And I can't download your version, please repost or send it
to me. It appears to have 0 size.

Madis731 wrote:

vid wrote:

Library should be same one on all systems, preserving FASM's feature to
generate same output from same source. This implies having mulptiple
versions of some modules (for different OSes) in library.

Shouldn't it be obvious - I think that BIN2ASC or HEX2DEC conversions or matrix
translations are just processor specific (we are all using IA32/64) and not OS
specific. We are not going to include GUI helpers, are we?

I am not getting your point. Of course such things will be there only once,
but ther _must_ be some OS dependant things - allocating memory, writing
to console, file I/O etc.
Post 17 Jun 2005, 12:00
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
Unfortunately I deleted my modified version off my computer.

I agree with having "__" to prefix all internal things but public procedures, variables, etc., should start with "flib_" to distinguish them from possible "user" (your term for it) procedures or variables which have the same name. Let's say we have a procedure called foo in our library. If the user creates their own foo there will be problems. Therefore, we should call it flib_foo so they can create their own foo. My idea for fmac_ was just an idea, give it a different prefix if you want- I just think we should prefix things with "fxxx_" so the user can create procedures, variables, and macros with the same name.

You can change "flib_" and "fmac_" to something else, but I think my idea makes sense.

As for names, I do agree we should use the same names as the ones used in C or other things, when possible. Why spend so much time thinking of new names? However, I again think we should prefix them with "flib_" in case the user has their own "malloc" (or other) procedure.
And if you ask why they would have their own when they are using the library, it might be because the one in the library doesn't fit their needs.

I agree that it will probably be hosted here, but we need some place to keep everything together, at least until Privalov sets something up. We would probably want our own forum, etc. Maybe a wiki, for ideas... That is why I am making another website. Anyways, my website will not only be about the library it will be about lots of other things too.
Post 17 Jun 2005, 17:04
View user's profile Send private message AIM Address Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
Macros can't have fmac_ prefix. Just imagine:
Code:
fmac_proc my_function arg1 arg2
fmac_local i:DWORD
(...)
fmac_ret    

horrible, isn't it? Wink IMO macros should fit elegantely in sources, just like standard fasm macros do.

For procedure names, if all procedures have to be preffixed with library name, let's at least make it shorter: fl_mem.malloc, or fl.malloc (fl_malloc ?).

I can create main website for the library, I guarantee it will be sufficent for our needs Very Happy Let's only agree how the library should be built.
Post 17 Jun 2005, 17:48
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Thanks, Vid, my post was not well thought out, and your appropriate question demonstrates that:
**********
how would you want multi-word names then: "openglcreatevortexmatrix", or "ocvm"?
**********
My opinion was insufficiently clarified in my previous post:
Let me try again.
I dislike encountering code with punctuation PRECEDING any of the above:
macros
instructions
variables
data structures
reserved words
directives,
etc.

Of course, you are absolutely correct, Vid, and my previous post improperly conveyed hostility to use of punctuation in any setting, whereas, the underscore is very properly employed in this situation you refer to:
open_gl__create_vortex_matrix (also known as ogcvm)

In that situation the readability is obviously improved by employing the underscore, JUST AS YOU implied in your excellent question.
WHAT I DO NOT AGREE WITH is this:
_ogcvm
OR, this:
.ogcvm
OR, this
!ogcvm
OR, use of ANY OTHER PUNCTUATION PRECEDING the variable, procedure, directive, etc. Regards tom
Post 17 Jun 2005, 18:25
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i have updated the specs again. Please take notes as you read it, and react to every subject marked by "?", so i can close them. Thanks
Post 18 Jun 2005, 13:42
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Thanks Vid, good job as always. I only disagree with one sentence:
"Internal macro stuff will have prefix "__". User can't declare names starting
with "__". "
As I indicated above, I dislike using punctuation to precede any directives, data, reserved words, or macros, etc. Obviously, on a public forum, like FASM, no one can be 100% satisfied all the time, and probably my own aversion to use of punctuation preceding words is idiosyncratic, and unimportant.
Thanks for taking the trouble to solicit opinions on your specification. regards, tom
Post 18 Jun 2005, 16:00
View user's profile Send private message Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
names with '__' prefix have the adventage that usually user won't think of similar name for his routines/data, so there will be no name conflict.
Post 18 Jun 2005, 18:53
View user's profile Send private message Visit poster's website Reply with quote
Vasilev Vjacheslav



Joined: 11 Aug 2004
Posts: 392
Vasilev Vjacheslav
i always use own procedures with "_" prefix, imho, it's very useful
Post 18 Jun 2005, 19:30
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Vasilev Vjacheslav wrote:
i always use own procedures with "_" prefix, imho, it's very useful

Thanks Vasilev and Decard, yes, I think 99.9% of the world agrees with you. My position, if it is not crystal clear is this:
READABILITY.
Better repeat it for emphasis: READABILITY.
Nothing else matters.
Decard and Vasilev would like to have a procedure, let's call it FFT_compute, which will perform a fast fourier computation on 1024 data values, and they would also like to have another element, maybe a macro, maybe a variable, maybe a subprocedure, but
BUT,
THEY CANNOT THINK OF ANY OTHER WORD, so, they create one:
_fft_compute
Wow. Wasn't that easy!!!
Then, next, we can have
.fft_compute,
and even $fft_compute, or, +fft_compute.
In fact, by the time these two guys (and about 99% of the rest of the FASM forum members) finish this program we will have used up about 20 different punctuation elements, in order to devise twenty different variables or procedures or macros or whatever. All of this WHY??
NOT TO MAKE THE "PROGRAM" understandable to others, but rather to generate the "CODE" QUICKLY.
FAST.
RAPID. HURRY.
Throw in another punctuation and get on with important things. Don't worry if anyone else can understand the distinction between, for example, -fft_compute and _fft_compute. You guys CAN understand, and that's all that counts, RIGHT???
But for me, no. I am only interested in READING programs, NOT CODE. Why? Because, in my experience, CODE is useless. ONLY programs are readily modifiable. CODE is so difficult for other programmers to comprehend that, in the end, one simply throws it all away, and commences anew, as if all the preceding activity were non-existant. Punctuation in front of variable names has its origin, as I remember, in the 1960's in Bell Labs. I am not a true believer in anything, but especially not in the sacred nature of UNIX, or C, or C++, and I certainly have no idea why anyone would want to perpetuate that nonsense today. Leave punctuation out of the assembler, out of the programs, save it for its intended purpose: to assist us in comprehending a program, by encountering it in the COMMENTARY, i.e. description, of what is going on. Just my two kopecs. regards, tom Smile
Post 18 Jun 2005, 22:03
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
also there was a standard of naming strings wiht names stating by "_", like
Code:
_error_memory_full db "There was an error. Memory seems to be full"    


vasilev: what does the "_" mark there?
Post 18 Jun 2005, 22:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
You have so vigorously fought against it but have not suggested any right way ^o)
What should we do then? m_ for macro p_ for proc or just serrormemoryfull so that the first letter always shows the type of the label?
Oh these horrible label names: mogcvm, pogcvm, sogcvm, fogcvm, etc.
Post 20 Jun 2005, 08:48
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  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.