I just stumbled upon this. POASM (http://smorgasbordet.com/phpBB2/viewtopic.php?t=952)
YES :U
So far its building most of the masm code I can point at it. It uses the masm32 include file fine but the current version of windows.inc has some duplicates in it that poasm squarks on. I have posted in Pelle's forum, a quick fixed version that seems to be working well.
This one is really worth the effort, the chance of a fully up to date Intel compatible assembler does not come along all that often so if you can find the time to do some testing, help out where you can.
Very nice :U
I will try it.
This is very exciting and worth having fun with.
Paul
I didn't see where you get it from.
drhowarddrfine,
You need to be a registered member of the board to download the file :
http://smorgasbordet.com/phpBB2/viewtopic.php?t=952
Many thanks to Pelle, now Poasm supports the INCBIN statement :
.data
Resource:
INCBIN Rsrc.bin
Hutch posted the master include file windows.inc with the error lines removed , this one must be used to build properly the example project. ( Before putting it to your include files folder, rename windows.inc to windows2.inc )
http://smorgasbordet.com/phpBB2/download.php?id=340&sid=c0accdc81d2d026f3a3e782c466181eb
[attachment deleted by admin]
So is this supposed to be a general replacement for windows.inc? If so, why was wsprintf commented out?
Jim,
Its for beta testing Pelle's new assembler. The current version works fine in masm.
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'."
uselib MACRO libname
include libname.inc
includelib libname.lib
ENDM
uselib user32
uselib kernel32
uselib comctl32
also, something like a simple equate? this doesn't work-
inv equ invoke
inv InitCommonControls
Jim,
You would do well to go to Pelle's forum to see where the development is at currently. Most of the capacity you are assuming is still being developed at the moment and Pelle has already made some good gains in capacity.
Ok, I am properly chastised. Are these questions premature to bring up in his forum? I see the uselib was already asked by anon but there was no answer that I could find.
To the administrator,
Why is this thread in the "soap box"? Shouldn't it be moved to one of the MASM forums? Ratch
Since it's in the soapbox, does that mean we can rant and rave about poasm's deficiencies?
Since it is declared as a 'work in process' the word 'deficiencies' should probably be replaced by 'wishlist' and, remember, he is not making a masm clone so he will be willing to look at any ideas, such as INCBIN, for example.
He is moving very fast on the bug reports. He fixed the problems of the FPU instruction set not assembling correctly in under 24 hours and that could not have been simple.
I have no idea where he will eventually wind up with this assembler and I bet he doesn't, either. All I know is that I want to be there!
Paul
Quote from: Jimg on December 29, 2005, 04:55:29 PM
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.
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.
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
Would you consider the two things I mentioned as bugs?
Quote from: Jimg on December 29, 2005, 06:07:03 AM
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
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.
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.
Ok :'( I'll crawl back in my corner now.
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
QuoteBut 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 :
.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]
This one eliminates all the function declaration procedure :
.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]
Quote from: Jimg on December 30, 2005, 07:24:40 PM
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...
Quote from: Jimg on December 30, 2005, 07:24:40 PM
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
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,
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.
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!
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:)
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.
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!
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
Quote from: Jimg on December 31, 2005, 02:37:49 AMA 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)
QuoteWithout 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.
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
QuoteUndefined 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.
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.
Quote from: PBrennick on December 31, 2005, 11:30:30 AMPerhaps you were thinking about MASM?
Yeap! Spoke out of turn, without all the facts.
Regards, P1 :8)
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
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?????
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
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?
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
Ok, this is my last post on this subject. I've gone from curious to hopeful to delighted to dumbfounded to disappointed to depressed.
Jimg,
My apologies, something what I don't understand is that why don't you try to code your own call or invoke macros declaring internally external functions? I posted some simple examples for you, just have a look at them. I believe you can do it. Macros are existing to extend the capabilities of an assembler.
callx macro RoutineName:req
ifndef RoutineName
RoutineName Proto
endif
call RoutineName
endm
Yes, this works, but seems pretty (insert own adjective here) to me.
Hi Jimg,
Nice work. Keep going on, you will see that macros are doing the job :U
Jimg,
One nice thing about PROTO is that it catches an incorrect number of parameters submitted to a function/subroutine using INVOKE. I often PUSH parameters and code other instructions before calling the function/subroutine, so INVOKE is useless to me for that method. Therefore, I wrote a macro called INVOKIT, which does not count parameters, but still pushes them in a right to left sequence before calling the function/subroutine. And because I am a PROCless programmer, I do not have to contend with that can of worms. I call it that because there is a lot of mass storage and bandwidth expended by discussions addressing problems caused by that directive. Ratch
Hi Ratch-
I swore I wasn't going to comment on this anymore, but a two pass assembler should be able figure out everything it needs from the proc statement without need for a proto. And in your case, unless all your routines preceed the call, you can't call them in poasm unless you use a proc and a proto.
Jimg,
Quote
And in your case, unless all your routines preceed the call, you can't call them in poasm unless you use a proc and a proto.
Not a problem. I inclose my subroutines in files that can be INCLUDE'd, so I can arrange them easily in any way I want. Otherwise, the EXTERN directive can be used to notify a the calling statement that the address is located at a higher address or a library. That has never failed me. Ratch