Pelle's Assembler

[hutch--]

Its usually the case that JAVA and basic compilers perform the extra pass to catch on the fly locals and globals but it has rarely ever been the case with either C compilers or assemblers. Its part of the trade off for having low level control but then there has always been an alternative with an assembler, manually code the stack frame if its needed and use push/call syntax to call it.

Mechanisms like MASMs invoke and TASMs call syntax were designed to bring some of the reliability of compilers to assemblers but this reliability does mean prototyping, procedures as a pseudo high level construct and a calling syntax that depends on both. Without the reliability of this type of construction, manual coding has too many advantages where pseudo INVOKE style macros manages to get the worst of both worlds, unreliable without the type checking and not as flexible as manually coding the procedure call.

[Jimg]

That's precisely my point.  A prototype is NOT required if the assembler would just use the information it gets from looking at the proc statement.  It need only to collect this information on the first pass, and double check the calls on the second.  With the speed of today's systems, I can't think of any good reason not too, except lazyness on the part of the assembler writer.  I'm certainly not in favor of trying to use a pseudo INVOKE style macro to get the job done!

[PBrennick]

Jimg,
As far as I am concerned, I am certain that you have hit this one bang on.  If the assembler knows there is an error in type checking, it has to know what the correct settings should be so having to code is redundant and should be unnecessary.

Paul

[P1]

A prototype is NOT required if the assembler would just use the information it gets from looking at the proc statement. 

Code order helps in eliminating extra lines as well.  You do not need the prototype, when the proc comes before the the main body of code.

That's is why most support code is 'included' in the preamble of your main asm file. 

So it comes to knowing your tools well enough not to be annoyed by them.

Regards,  P1  :8)

[Vortex]

Without the reliability of this type of construction, manual coding has too many advantages where pseudo INVOKE style macros manages to get the worst of both worlds, unreliable without the type checking and not as flexible as manually coding the procedure call.

Hi Hutch,

You can survive without type checking. Just have a look at Fasm, it uses a kind of pseudo INVOKE style macro.

[PBrennick]

P1,
As I stated somewhere else in the thread, Pelles Assemble requires prototyping no matter where the procedure is located unless he has made a very recent change.  Also, and this was a surprise, all calls to procedures are required to be prototyped no matter whether they are invoked or called.  Perhaps you were thinking about MASM?

Paul

[Vortex]

Undefined symbols are treated as local symbols (in a proc), so referencing forward proc's will not work. Handling this would be very nice, but I'm not sure how to solve it at the moment (in a clean way). "Adding another pass" is not really an option, so I have to find another way...

I don't know if it's the best method but you can consider coding a new macro like invoke called invoke2 or funccall. This new macro would function just like Goasm's invoke. Goasm doesn't require function declarations or prototypes.

[GregL]

I really don't see any problem at all with requiring prototypes. It sounds like it would be a lot of work for Pelle with little gain.

[P1]

Perhaps you were thinking about MASM?

Yeap!  Spoke out of turn, without all the facts.

Regards,  P1  :8)

[PBrennick]

Greg,
That's how I feel also.  It is actually less confusing to me.  It surprised me at first and then I just built a bridge and got over it.

Paul

[Jimg]

My bridge keeps crumbling with every program I try to convert.  I absolutely can't see why a "call abc" where abc has to be an address to be determined later should require a prototype.  I mean, what good does the prototype do when there are no parameters??  Tells the assembler it's an address.  It has to be an address for a call.  What am I missing here?????

[PBrennick]

Jimg,
You are not missing anything.  What this does for him in the asembler is he is then able to make assumption and act upon them.  CALLs can be interesting because you can call a subroutine and/or a procedure.  If there is no PROTOTYPE then the assembler assumes it is a LOCAL call to a subroutine.  If the subroutine is not found then an error is reprted.  This is just a case where, I think, this is the method he is most comfortable with.

Try not to fight the process when you are dealing with differences in styles.  It may happen that you can never get used to these 'differences' and as a result, you will continue to use MASM instead.  There is certainly no harm in that!  Some of us wiill use POASM, some MASM and some will use both.  We will still be a family that can help each other.

Remember that some of the assumptions that I made in the first paragraph are just that, assumptions.  I have no hotline into Pelle's thinking, it is just that what I said makes a lot of sense to me.  Others may have different opinions.

Paul

[Jimg]

Sorry Paul, this doesn't make any sense to me.  If you throw away all capabilities of an assembler and keep only the barest minimum ability to understand intel syntax commands, call should work.  I'm not familiar with other assemblers (HLA, FASM, NASM, GOASM, etc.).  How many can't make a call to an address that occurs later without a prototype?

[PBrennick]

Jimg,
I understand your words and you make a fair point but I think I have burned your ear as far as I can on this one.  If you wish to go any further with this, you probably should approach Pelle,himself, unless you are just looking for a good gripe session.  Seriously, I hope this does not become a stumbling block for you.  It is a good assembler and it is getting better.  Try not to look at it from the access perspective (CALL or INVOKE).  Try looking at it from the definition perspective (a Procedure is a Procedure whether it is called or invoked).  Maybe it will make more sense to you that way

Paul

[Jimg]

Ok, this is my last post on this subject.  I've gone from curious to hopeful to delighted to dumbfounded to disappointed to depressed.