Privalov, I am very happy with the macro system in FASM - seems very powerful, yet simple. Thank you, it is a very effective design. The lack of limitations in FASM further extend this power.
Posted on 2002-07-23 10:11:27 by bitRAKE
Parameter checking -- I have not found that feature to be overly useful in MASM, and I would not consider its implementation first priority for FASM. With the usual prototyping "myfunc PROTO :DWORD, :DWORD, :DWORD" parameter checking equates to parameter counting. Forgetting a function parameter or using one too much will normally crash the application, and will be easily detected. It takes much more time to detect programming errors where you get the order of parameters wrong, or where you pass a DWORD value immediately when in fact a DWORD pointer to the value is required (and vice versa). Parameter counting will not help at all to find these errors.

Frank
Posted on 2002-07-23 10:22:26 by Frank
If you want to learn more about the system of macroinstructions in fasm, you can read what I have written so far for the new documentation. It's an early version and may contain errors, but I hope it can help you understading how my macroinstructions work. ;)

You can also get the first beta pre-release of fasm 1.40 here.

This is all very unofficial, that's why I don't even put it in a new thread. ;)
Posted on 2002-07-23 10:54:41 by Tomasz Grysztar
Originally posted by pelaillo
I easy could do GPFs in Masm if I want (I have had a lot unwanted also). Assembly is the best, HLL does not allow you to do interesting damages.


sure you can always do GPFs but it is your mistake then, the assembler/compiler did his best to catch all the error he could at compilation-time...

forgetting a comma is a bit less unconscious... and sometimes far harder to find...

Originally posted by Privalov
I don't want to put any HLL stuff into fasm, and I won't do that. You can customize the syntax using the macroinstructions (will be a bit enchanced in 1.40, and well documented in the new docs I'm working on currently), but if you need something more, you should use external tools. Like the C compilers generating assembly sources you can have some kind of HLL assembly compiler generating sources for fasm, why not?
I one write something of that kind and it's good I can promote it on my website.


The problem is not HLL or not... I don't think I'm a HLL enthusiast when it comes to assembly (I don't use all these .IF .WHILE thingies), I'm talking about a feature that let you know when you are making a mistake that IS detectable...

Originally posted by Frank
Parameter checking -- I have not found that feature to be overly useful in MASM, and I would not consider its implementation first priority for FASM.


Because you always had it in MASM...

With the usual prototyping "myfunc PROTO :DWORD, :DWORD, :DWORD" parameter checking equates to parameter counting


Well, that is what I'm talking about... I don't want a strict type checking, but parameter checking or parameter counting if you want to be pedantic...

Forgetting a function parameter or using one too much will normally crash the application, and will be easily detected.


Did you ever worked on a great project?
Will you bother to test your program in ALL cases everytime? Imagine an api call crashing during a sheduled task of an automated program... :eek:
You can be sure that your program is "algorithmely" and "structuraly" fiable, but a undetected typo in the code may lead to a program crash if it is undetected... a loop can sometimes take many paths depending of some variable values... will you test them all? The assembler/compiler is here to tell you about typos, illegal constructions, and such...

To me, in the programming world, using an assembler/compiler with no parameter checking is just as dangerous as having s*x with someone that may have STD without condom in the real-life... you're relying on trusting your code as you trust a partner (that may be not so trustworthy, like a "malicious" code where, for some reason, you don't see any error)... that's just unsafe.
I'm sort of worried to see the reactions about this... are you guys so self-confident just because you code in assembly and you don't need any feature of this "HLL crap"? That's just plain l33t... and your own code will learn you the hard way when customers will yell, and the boss will fire *you* because *you* wrote a buggy software and that one consequence for a customer was the loss of huge sums of money... all just because of a little forgotten comma the assembler didn't catch... admit it would be sad...

I would like to heard comments on this from people like Hutch, Maverick (especially you who designed your own langage and compiler) f0dder... and anyone who wants to add his two cents... of course.
Posted on 2002-07-23 12:04:33 by JCP
so... you release software without testing? :grin:


but your point is correct, however you heard Thomas so it won't be added. (it's his program so his decision)
IMO The best solution to this would be a pre-parser that just checks and returns errors on your script.
Posted on 2002-07-23 12:33:28 by Hiroshimator

(I don't know many people that type code like Ritsuko from
Evangelion that compiles the first time without any error! :D )

Come on, how hard can it be to code something like The Magi? ;)


Interactive way is less time consuming that a parameter checking
error lists and could be more flexible

Hrm, you'd rather have the IDE spend time looking for these bugs?
I don't know how you work, but I spend most of my time in the IDE,
writing "some amount" of code, and only then do I hit the build
keystroke. Furthermore, because of my wonderful modular design :),
I usually only work with one source module at a time... so even
with big and rather slow optimizing compilers, build speed isn't
much of an issue. FASM is superfast, how much would it be slowed
down by a (properly done) invoke/proto implementation?

Running a pre-parser before running fasm would be annoying, and
would probably be a whole lot slower than adapting fasm internals.

I'm starting to like fasm, it was the only way I could (easily)
build a PE in a "rather special" form... but before it can replace
masm (for me, anyway) it will need COFF output (which I hear is
coming - great work!), some prototype+checking facility... and a
bit less painful way to handle imports (for "standalone" PE output -
this will not be much of an issue when building coff's and linking
externally).

I guess one of fasm's great strengths is that it's very "raw"
and most everything is done through macros, and the macro system
seems to be very powerful... this certainly makes sense for platform
dependant stuff like PE imports/resources and whatnot, but a
feature like parameter checking (counting) is so generic that
you might as well implement it in the core - at least if there's
a noticeable speed difference between macroized checking and
"core" checking.

What about using a more C-like syntax for structure declaration,
and #ifdef/#else/#endif ? I know a lot of people will dislike this
because it's too "highlevel" or whatever, but the struct declarations
if fasm already look a lot like C, and it would be *very* nice
being able to use C header files both for asm and C, without a
"h2inc" middle step... especially when dealing with OS development.
Posted on 2002-07-23 12:42:14 by f0dder
You are exaggerating. When you are programming assembly you can do many mistakes that cannot be checked by compiler just because it gives you freedom. With assembler the programmer is responsible for what he is doing, the compiler has to quitely do what programmer asks for. It can be dangerous (I have even cleared my flash BIOS one day by putting wrong number of POP instructions before returning from procedure, so program
went out of control), but you are choosing it when you choose (low-level) assembly.

In one of my programs I'm setting up the parameters on stack for VirtualFree just after VirtualAlloc, so they are waiting for the right moment just in place. Then I invoke the VirtualFree with not enough number of parameters, because they are already prepared on the stack. This is a kind of optimization, which you can do only in assembly language. Parameters count checking would make that impossible to do.



All right, but you can still do it using the macros, why not:



macro invoke proc,[arg]
{ common count = 0
forward count = count + 1
common
if count <> proc#.count
display "*****************************************",0Dh,0Ah
display "Invalid count of parameters for API call!",0Dh,0Ah
display "*****************************************",0Dh,0Ah
halt ; illegal instruction
end if
invoked equ invoked,proc
if ~ arg eq
stdcall [proc],arg
else
call [proc]
end if }


Now you only have to define constants for each API calls, eg:



MessageBox.count = 4
ExitProcess.count = 1


Posted on 2002-07-23 13:00:24 by Tomasz Grysztar

so... you release software without testing? :grin:


but your point is correct, however you heard Thomas so it won't be added. (it's his program so his decision)
IMO The best solution to this would be a pre-parser that just checks and returns errors on your script.


No, but during your testing, you can hardly test all the possibilities (with good tools or with good quality insurance, maybe...)

Tomasz do what he wants with his assembler, I'm not forcing him to add a feature I want, because it would be selfish... but an interesting discussion is started, I would even say a debate! That is not so frequent here. So even if we quit the field of fasm a bit, it is interesting imho... and perhaps Tomasz will change his decision after the debate. ;)


You are exaggerating. When you are programming assembly you can do many mistakes that cannot be checked by compiler just because it gives you freedom. With assembler the programmer is responsible for what he is doing, the compiler has to quitely do what programmer asks for. It can be dangerous (I have even cleared my flash BIOS one day by putting wrong number of POP instructions before returning from procedure, so program
went out of control), but you are choosing it when you choose (low-level) assembly.

In one of my programs I'm setting up the parameters on stack for VirtualFree just after VirtualAlloc, so they are waiting for the right moment just in place. Then I invoke the VirtualFree with not enough number of parameters, because they are already prepared on the stack. This is a kind of optimization, which you can do only in assembly language. Parameters count checking would make that impossible to do.


I agree with you about the freedom that assembly provides (but it shouldn't be like a gun without safety lock... you can shoot yourself in the foot), but about your VirtualAlloc example, I already did this plenty times in my programs... I must admit I sometimes wished MASM to have such a feature to invoke the API... but the after-thought was that I should continue as I did... when using this "optimization", continue to push arguments and calling the function explicitely... this way, I remember what I wanted to do some months after and I don't think it is a mistake if it is not...

This is also why I suggested it to be optional... if someone don't like it, the user can disable it (by not incluing the prototype), but imho, there is more classical api calls than "optimized" one like your example...
I assume that when you use invoke, you want to do a relatively classical, "standard" thing, and this is the perfect place to add some security... Invoke is very widely used in all masm sources... and I assume many programmers forgot a comma between two arguments... just like programmers sometimes forget the ; delimited in C... it is frequent mistake and the compiler tells it...

Even if there is better/more experienced programmers than me here, I don't think I'm a programming baby who needs the assembler to catch all the mistake he does, but when it can be easily catched and saves me times, why not? Free coding, yes. Unsecure coding, no.

Originally posted by f0dder
"Come on, how hard can it be to code something like The Magi?"


Some years ago, I coded a Magi-GUI like in VB, but I stopped there (and it didn't looked exactly like the original one) ;)

I'm starting to like fasm, it was the only way I could (easily)
build a PE in a "rather special" form... but before it can replace
masm (for me, anyway) it will need COFF output (which I hear is
coming - great work!), some prototype+checking facility... and a
bit less painful way to handle imports (for "standalone" PE output -
this will not be much of an issue when building coff's and linking
externally).


It is not only coming, it is done. ;)

you have to put MS COFF as format or something like that at the top of your source (there is an example in the latest version (coffee), I think).

*EDIT* : thanks for the macro, Privalov... but why not add parameter size checking (byte, word, dword)... okay, okay, I'm a pest! ;)
Posted on 2002-07-23 13:32:04 by JCP
Real assembly coders doesn't use invoke :tongue: Doesn't need type parameter checking :tongue: . Real assembly coders usually do a sub-mov-call or push-call. ;)

Am I an elitist? :grin:
Posted on 2002-07-23 13:41:42 by stryker
No, just an amateur :grin: : REAL MEN CODE IN HEX ! :grin:
Posted on 2002-07-23 13:47:15 by JCP
stryker: why not use a feature when it saves time (in many ways), and
don't really give any performance penalties?
Posted on 2002-07-23 13:48:38 by f0dder
because the code will look a little more assembly than HLL. :grin:

Seriously, I'm just joking around since the topic is getting serious.

I wish I could master the FASM macro styles, so I can port my xcall from MASM.
Posted on 2002-07-23 13:51:42 by stryker

Real assembly coders doesn't use invoke :tongue:


I use "stdcall" :rolleyes:
Posted on 2002-07-24 01:23:57 by bazik

I don't want to put any HLL stuff into fasm, and I won't do that.


Love to hear that!
Assembly is the programming lanugage with the most freedom for the programmer, so why should a
Assembler restrict your freedom? 1 comma less, is one char less typing ;)

stdcall , 0 cap msg 0

:)
Posted on 2002-07-24 03:29:20 by bazik