Pelle's Assembler

[Vortex]

Since it's in the soapbox, does that mean we can rant and rave about poasm's deficiencies?

Jimg,

Not to offend you but your statement "poasm's deficiencies" sounds really ungratefull. Your attempt to critisize the tool is not an attitude to be welcomed. Did you test properly the tool? Did you speak with the author about your wishes?

Jimg, understand that Pelle has not a team like MS, probably he's working alone and many users are appreciating Pelle's efforts. Developing a Macro assembler is not an easy job and Pelle is trying to do his best. You should be more carefull with your statements.

[Jimg]

My apologies to everyone I offended.  Apparently the word deficiency has a different and much more negative context to others than it has to me.  It's not derogatory, just a categorization of unfulfilled expectations.  Not in the group of desired enhancements, but rather minimal requirements.

I would, however, like to know what minimal facets of macro assembler development others are finding unimplemented as of yet.  Perhaps we can get a consensus of opinion to share with Pelle.

[PBrennick]

So far, I have submitted two (2) bug reports.  In both cases, the bugs were gone before the sun went down.  He works very fast and has told me in an IM that "My plan is to release a new version of Pelles C before next summer, where POASM will be included, so I want to "finish" this as soon as I can..."  This is exciting news as it tells me that he is committed to the assembler portion of his tool set.

In his world view, this is actually the quickest and best way for him to ensure that his inline assembler is functioning correctly, so we are all being a big help to him.  I think he would like to see more feedback from others beyond Hutch, Greg and me.  Not just wishlist stuff, but bug reports...

Paul

[Jimg]

Would you consider the two things I mentioned as bugs?

[PellesC]

ok, testing poasm.

Any idea how to get the uselib macro to work?  I get "potest.asm(32): fatal error: Can't open file 'libname.inc'."

I have just posted version 0.91 in my forum. Look in sample "tokpaste.asm" - you need a slightly different syntax. There was also a bug with some EQU's not expanding correctly...

Pelle

[Jimg]

Ok, the new uselib macro-

uselib   MACRO   libname
   include      libname#.inc
   includelib   libname#.lib
ENDM


Next question-

Is it your intention that the output of posasm be compatible with the microsoft linker?  If no, then no problem.  If yes, then in a simple program with Start: for a label, and end Start at the end, I get the following:

Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/SUBSYSTEM:WINDOWS /RELEASE /VERSION:4.0 "/LIBPATH:F:\masm32\LIB" "F:\Progs\potest\potest.obj" "F:\WinAsm\Progs\potest\potest.res" "
/OUT:F:\Progs\potest\potest.exe"
LINK : error LNK2001: unresolved external symbol __Start
F:\Progs\potest\potest.exe : fatal error LNK1120: 1 unresolved externals

Your linker works fine however.


But now the BIG question.  Is it your intention to make invoke work better than it does in masm?  Specifically, I'm talking about forward references to variables, and to procs without some lame proto statement.  For me, this is the single biggest deficiency (yes, I said deficiency) in Masm.  Well worth an extra pass to sort these things out.

[PBrennick]

Jimg,
Actually, using POASM, PROTO statements are required for CALL statements if the CALL is referencing a PROC instead of a subroutine.  This one caught me by surprise but is easy to do and get used to.  Prototyping is required for both forward and backward referencing as far as I can tell.  I have been using my floating point calculator project as a testbed to see how POASM is working.  I think it is close to assembling correctly, just a few more bugs I need to report to Pellle, such as an indexing into a table problem.

[Jimg]

Ok  :'(  I'll crawl back in my corner now.

[PBrennick]

Jimg,
What I would do if I were you is get one of your favorite, medium sized projects and slowly work at converting it to POASM.  I suggest something other than a small project so there will be a diversity of usage in the instruction set.  This will increase the odds of you coming up with a bug that can be reported to Pelle and will help him create a better assembler.  If there is something you are unsure of, post it here and when you are ready, post it on Pelle's forum.

You and I both like the uselib macro so I was happy to see that report.  As I recall, you are better at writing macros than I am so look closely at that area, also.  Most of us like to use macros but hate to write them.

Paul

[Vortex]

But now the BIG question.  Is it your intention to make invoke work better than it does in masm?  Specifically, I'm talking about forward references to variables, and to procs without some lame proto statement.  For me, this is the single biggest deficiency (yes, I said deficiency) in Masm.  Well worth an extra pass to sort these things out.

Jimg,

You can do it with some macro tricks :

Code Select Expand

.386
.model flat, stdcall
option casemap:none
include \masm32\include\windows.inc
include invoke.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib

EXTERN ExitProcess@4:PROC
ExitProcess EQU <ExitProcess@4>
EXTERN MessageBoxA@16:PROC
MessageBox EQU <MessageBoxA@16>

.code
start:
_invoke MessageBox, NULL,addr MsgBoxText, addr MsgCaption, MB_OK
_invoke ExitProcess,NULL
.data
MsgCaption      db "Iczelion's tutorial no.2",0
MsgBoxText      db "Win32 Assembly is Great!",0

END start
[attachment deleted by admin]

[Vortex]

This one eliminates all the function declaration procedure :

Code Select Expand

.386
.model flat, stdcall
option casemap:none
include \masm32\include\windows.inc
include invoke2.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib

.code
start:
_invoke MessageBoxA, NULL,addr MsgBoxText, addr MsgCaption, MB_OK
_invoke ExitProcess,NULL
.data
MsgCaption      db "Iczelion's tutorial no.2",0
MsgBoxText      db "Win32 Assembly is Great!",0

END start
[attachment deleted by admin]

[PellesC]

Next question-

Is it your intention that the output of posasm be compatible with the microsoft linker?  If no, then no problem.  If yes, then in a simple program with Start: for a label, and end Start at the end, I get the following:

Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/SUBSYSTEM:WINDOWS /RELEASE /VERSION:4.0 "/LIBPATH:F:\masm32\LIB" "F:\Progs\potest\potest.obj" "F:\WinAsm\Progs\potest\potest.res" "
/OUT:F:\Progs\potest\potest.exe"
LINK : error LNK2001: unresolved external symbol __Start
F:\Progs\potest\potest.exe : fatal error LNK1120: 1 unresolved externals

Yes, I have seen this already. For reasons unknown, the Microsoft linker can't accept the full symbol name for then /ENTRY option, it wants to add the first underscore itself (as it seems). Strange. Since I can handle it either way in my linker, it should be easy to fix - it's just a little "low priority" at the moment...

But now the BIG question.  Is it your intention to make invoke work better than it does in masm?  Specifically, I'm talking about forward references to variables, and to procs without some lame proto statement.  For me, this is the single biggest deficiency (yes, I said deficiency) in Masm.  Well worth an extra pass to sort these things out.

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

Pelle

[hutch--]

I have never seen PROTO as being a problem, it provides a reliable way of testing argument size and count in an invoke statement and makes sure the PROC matches both.

Its easy enough to code manual replacements where a label is followed by manual stack code and its no big deal to fully automate macros that do this type of code,

Code Select Expand


MessageBox MACRO arg1,arg2,arg3,arg4
  push arg4
  push arg3
  push arg2
  push arg1
  call _MessageBoxA@16
ENDM


I have tended to see invoke copies as having similar form but without the reliability of type checking.

[Jimg]

On the other hand, this is a computer, and it should be able to figure out something that simple as looking at a proc to see what the items actually are and save the coder the hassle of creating an otherwise useless prototype.  In fact, it complains if this worthless prototype doesn't match the proc, so why bother!

[zooba]

My current project (ASM Runtime) doesn't have any prototypes in it. I've set up some (complicated) batch files that automatically generate prototypes (by doing another pass) before attempting to assemble. I have a relatively fast machine, so there doesn't appear to be much overhead (I saved more time by not using the entire WINDOWS.INC file  :cheekygreen:)