Index
> Main > Fasm Standard Library concept by vidGoto page 1, 2 Next |
| Do you accept my concept for library? | ||||||||||||||
|
||||||||||||||
| Total Votes : 12 |
| Author |
|
|
vid 16 Jun 2005, 08:34
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.
Last edited by vid on 18 Jun 2005, 13:40; edited 1 time in total |
|||||||||||
16 Jun 2005, 08:34 |
|
|
Octavio 16 Jun 2005, 13:43
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.  |
|||
|
16 Jun 2005, 13:43 |
|
|
decard 16 Jun 2005, 14:52
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. |
|||
|
16 Jun 2005, 14:52 |
|
|
pelaillo 16 Jun 2005, 16:25
Quote:
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. |
|||
|
16 Jun 2005, 16:25 |
|
|
tom tobias 16 Jun 2005, 18:35
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  |
|||
|
16 Jun 2005, 18:35 |
|
|
THEWizardGenius 17 Jun 2005, 02:51
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 |
|||
|
17 Jun 2005, 02:51 |
|
|
THEWizardGenius 17 Jun 2005, 03:10
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).
|
|||
|
17 Jun 2005, 03:10 |
|
|
Madis731 17 Jun 2005, 08:25
? 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? |
|||
|
17 Jun 2005, 08:25 |
|
|
vid 17 Jun 2005, 12:00
Octavio wrote:
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:
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:
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:
Another good point, license. I suggest public domain. By the way: 50% of time i am on dial-up, too. Decard wrote:
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:
how would you want multi-word names then: "openglcreatevortexmatrix", or "ocvm"? THEWizardGenius wrote:
"__" 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:
user of the library, word programmer doesn't imply he uses library. THEWizardGenius wrote:
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:
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. |
|||
|
17 Jun 2005, 12:00 |
|
|
THEWizardGenius 17 Jun 2005, 17:04
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. |
|||
|
17 Jun 2005, 17:04 |
|
|
decard 17 Jun 2005, 17:48
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?  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  Let's only agree how the library should be built. |
|||
|
17 Jun 2005, 17:48 |
|
|
tom tobias 17 Jun 2005, 18:25
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 |
|||
|
17 Jun 2005, 18:25 |
|
|
vid 18 Jun 2005, 13:42
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
|
|||
|
18 Jun 2005, 13:42 |
|
|
tom tobias 18 Jun 2005, 16:00
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 |
|||
|
18 Jun 2005, 16:00 |
|
|
decard 18 Jun 2005, 18:53
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.
|
|||
|
18 Jun 2005, 18:53 |
|
|
Vasilev Vjacheslav 18 Jun 2005, 19:30
i always use own procedures with "_" prefix, imho, it's very useful
|
|||
|
18 Jun 2005, 19:30 |
|
|
tom tobias 18 Jun 2005, 22:03
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 |
|||
|
18 Jun 2005, 22:03 |
|
|
vid 18 Jun 2005, 22:04
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? |
|||
|
18 Jun 2005, 22:04 |
|
|
Madis731 20 Jun 2005, 08:48
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. |
|||
|
20 Jun 2005, 08:48 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|