When POAsm comes out, is it recomended that I switch over from MASM?
Mike,
At the moment you can live with both as they are near identical in normal code. The macros will end up different but apart from that the object module format is the same, you can use either linker, either resource compiler and get good results. Pelle's assembler is shaping up already as a very good tool, the native unicode support is a big win, the amount of data you can use is far larger and unproblematic to use and it is a developing 64 bit assembler as well.
The one thing that looks good is the auto detection of externals.
I guess the point, here, is that since the object module format is the same, that from this point on, the only differences will be in the macro support via the preprocessor so to answer the question, 'should I make the switch' it will be only a matter of personal taste in macros so 'no one' can answer that question for you.
EDIT: auto detection of externals, you are correct on that one!
Paul
If this new product works out, perhaps hutch will dump ml.exe; and use POASM.
Perhaps, but first Hutch will do some serious testing of it, he is very dependable that way so you can be sure that if he makes the switch, you can trust his decision.
Paul
Ofcourse hes dependable, he was (perhaps still is) a well reguarded programming major. He and randyll hyde are like legends within the circle of people who do nothing but code assembly (as few as they are). The problem is Microsoft is trying to target people who want to code the high level stuff, eg C#, VB.net, etc. Lets just face it, Microsoft doesn't care about low level programmers. When 64 bit processors are main stream, ml.exe will serve nothing more than as a component in the visual c++ compiler. (Sort of like right now, but to a greater extent). In any event, it would be nice to be using an origonal product. With this in mind, I really do think hutch should use poasm in his package as apposed to ml.exe, but its still his choice. One things for sure, if he does use poasm, hes going to have to rename MASM32 to something else. Its his decision, but I would seriously hope that this logic would be obvious to him.
:bg
Mike,
I will let you in on a little secret, I have been at this stuff for a long time and I long ago learnt not to enter into the area of vapourware. I also don't try to predict the future and prefer to work in the present to effect the future where it can be meaningfully changed.
In the short term the action has been in helping Pelle get the new assembler up and going as it has been a massive amount of work to do this and he deserves the support of programmers for having done so. In case anyone has missd it, I have been plugging Pelle's tools for a couple of years now for the most obvious reason, they are technically very good and deliver superior results when used properly.
The next stage in the development is to produce the correct support for POASM, I have a later set of include files up and going and will have to shortly start editing the master software I use for the creation of the WINDOWS.INC file because POASM is more strict than MASM. The big interest in the pre-processor capacity is to be able to produce enough macros to make POASM easy enough to use at the entry level and so far this has shaped up very well.
About the only thing slowing me up at the moment is the script engine I am working on that I need for code generation, templates and similar. I already have a couple of weeks work done on it and it appears to developing in the direction I need.
Hi, is there an EULA for POASM? I've been wondering if POASM can use the full MASM syntax legally without stepping on a derivative copyright. Hutch and Pelle probably know the MASM EULA better than any of us so this is probably a moot question. Great work Guys! :)
Mark,
I serious doubt its an issue as the syntax is historical Intel syntax and it has been used by many over time so it is not unique to MASM or POASM. Intel have long ago stopped producing an assembler and they have never complained about anyone using their historical syntax format as it supports their hardware so I would not lose any sleep over it.
I agree with hutch--.
Words and expressions are not a trademark.
Manos.
If I wasn't tied up with school, Id love to help with the project myself. One thing that would be nice is if I don't have to configure pelles linker based on what dirrectory I install it in in order to use the assembler. Thankfully, this can be accomplished with a simple batch file. As for the macros. I would like it if there was an option view the asm code after the peprocessor has processed all the macros, if nothing else just to see how they work. For instance, it is sad but true that people don't realize the fastest way to do a memory to memory move opperation is to push the value on to the stack and then pop it to the destination. I have looked at plenty of code containing constructs like...
mov eax, srclbl
mov dstlbl, eax
Then ofcourse, there are people like me who can't sleep unless they know everything about everything thats done behind the scenes. Another thing that would be nice is the option for different syntaxes. For example, GAS allows you to switch between intel, and AT&T syntax. Though I hate the later option, Id still include it for good measure. Another thing I would really like to see is a linux implimentation of goasm. Right now, the only assemblers for linux are GAS, FASM, and NASM. (And a few others from obscure sources that are not supported). They are nice, but I am not used to them. I could go on for ever, but my lunch break will be over soon and I need to get back to class. Anyway, these are just ideas, and since I am not working on the project, those who it may concern may choose to use or disreguard it.
Quote from: MusicalMike on January 24, 2006, 05:42:15 PM
For instance, it is sad but true that people don't realize the fastest way to do a memory to memory move opperation is to push the value on to the stack and then pop it to the destination. I have looked at plenty of code containing constructs like...
mov eax, srclbl
mov dstlbl, eax
Had to check this myself as I prefer the 'mov eax, .../mov ..., eax' form (except with my super-move macro its 'move dest, eax, src' :U) so I did some simple tests.
.data
value1 DWORD 0BADF00Dh
value2 DWORD 0h
Algo1 MACRO
REPEAT 8
mov eax, value1
mov value2, eax
ENDM
ENDM
Algo2 MACRO
REPEAT 8
push value1
pop value2
ENDM
ENDMResults:
EAX (1) = 195948557 (0BADF00Dh)
Clock Cycles (1): 15
EAX (2) = 19 (00000013h)
Clock Cycles (2): 19So the first is faster, though it uses eax (I tried with all registers and the results are the same) but with suitable macros you can easily select which register to use. Note that EAX in the second is the same as the clock cycle count - ordinarily it would obviously not change :U
Many things affect the speed of code execution. What works fast on one processor might dog out on another. If you look in the Laboratory there is some code to measure time in high resolution, and a thousand or more posts about optimizing code. :)
Weren't we talking about switching to POASM? :8)