yikes, this is not the first time I heard someone say this about MASM. It's a good assembler makes coding a lot easier.

For some easier is just not 1337 enough :rolleyes: , oustside of the local variable problem and the BSS array of structures bug there is little to complain about in MASM so people complain about it being too good :)
Posted on 2003-12-10 21:28:42 by donkey
why not use C

I agree with x86asm that assembly on the Z80 was relatively easy. I started by hand coding small programs. Eventually, I hand coded my own assembler to work with my hand coded "word processor".

That's where I got sold on assembly when I realized all its possibilities. I even coded a program to extract square roots with 10000 decimal places on that Z80. Try that in C or any other HLL!!!!!

When I switched to a regular PC, I was lucky to start with MASM in 16-bit DOS. Again, I believed that assembly was considerably more adaptable to any chore than HLLs, specially when speed was important.

And when I switched to 32-bit Windows assembly, my choice was obviously MASM32 which was the most familiar from the point of view of syntax. Although some HLL features are available, they don't have to be used. But, some of them certainly make life a lot easier and reduce the risk of error (such as the invoke macro).

Again, assembly gives the choice of doing things in very different ways as compared to using HLLs such as C, C++, etc. A good example is the app which I've just about completed, my current avatar having been partly designed with it (it's a computer simulation of the old Spirograph game). With assembly, I did not have to use an HLL's function imposed on me to display pixels on the screen. I could even bypass the slow Windows' SetPixelV function!!!

Assembly is fun even with some HLL features

Raymond
Posted on 2003-12-10 21:56:12 by Raymond

Obviously masm isnt a C compiler, obviously it can be used to write asm code perfectly fine.
But after going through icezilions tutorial... alot of "macros" and whatever else masm implements,
seem to make its syntax alot like C. Im not saying this is good or bad, but when i code in asm i like to code in asm. Things like LOCAL (define a local variable), .IF .BREAK .WHILE, invoke - seem to make masm source code look alot like C source code. so wuts the point? why not just use C?


You'll *really* like HLA :-)

As many others have said, as long as the assembler lets you code the way *you* want to, why should you care about the extra features it supports?

The truth is, all those "macros" found in Iczelion's tutorials are largely responsible for the resurgence in interest in assembly language. Maybe *you* like to see all those pushes before each call, but most people don't. The Iczelion tutorials were among the first pieces of decent example code that demonstrated the fact that you didn't have to use "1960's software engineering" when writing assembly code. This has forever changed the way people view assembly language.
Cheers,
Randy Hyde
Posted on 2003-12-11 00:48:05 by rhyde
Hy, bnice2137

I agree with you, I don't like all those macros or structures that make MASM similar to an HLL language. They hide the effective use of registers and you lose control over what you are doing. I "translated" one of the wonderful Iczelion's tutorial in a way that left me only with PROCs and variables and then went further eliminating these too! WndProc was reduced to just a label and I accessed the parameters in a direct way... :)

I did that for educational purposes, I normally use PROCs and variables in MASM but I don't use LOCAL, ASSUME...etc...

I use NASM for 16 bit applications.

Althought I don't like it, I admit that MACRO-assembly is a great thing. It gives you the flexibility of a language like C with the power of a traditional assembler. You can easily translate standard C programs into ASM maintaining the elegance of C. It seems that a lot of people prefer the Macro approach, I don't. What makes me happy is that the choice is free. :)

Regards,
fooCoder
Posted on 2003-12-11 04:17:35 by fooCoder
well i would rather code it this way rather than using
cmp al,9h jae shit
and then breaking my head where it would jump and
how do i code the .elseif looking every change in debugger
and i know no c or no asm its just common thinking

convertproc:
mov esi,offset realans
mov edi,offset convans
mov ecx,8
tillend:
mov al,byte ptr
shr al,4
.if(al>9h)
call shit
.elseif
add al,30h
.endif
mov byte ptr ds:,al
add edi,1
mov al,byte ptr
and al,0fh
.if(al>9h)
call shit
.elseif
add al,30h
.endif
mov byte ptr ds:,al
add edi,1
dec ecx
inc esi
loopd tillend
retn

shit:
add al,7h
add al,30h
mov byte ptr ds:,al
retn

retn
Posted on 2003-12-11 06:39:12 by bluffer


I agree with x86asm that assembly on the Z80 was relatively easy. I started by hand coding small programs. Eventually, I hand coded my own assembler to work with my hand coded "word processor".

That's where I got sold on assembly when I realized all its possibilities. I even coded a program to extract square roots with 10000 decimal places on that Z80. Try that in C or any other HLL!!!!!

When I switched to a regular PC, I was lucky to start with MASM in 16-bit DOS. Again, I believed that assembly was considerably more adaptable to any chore than HLLs, specially when speed was important.

And when I switched to 32-bit Windows assembly, my choice was obviously MASM32 which was the most familiar from the point of view of syntax. Although some HLL features are available, they don't have to be used. But, some of them certainly make life a lot easier and reduce the risk of error (such as the invoke macro).

Again, assembly gives the choice of doing things in very different ways as compared to using HLLs such as C, C++, etc. A good example is the app which I've just about completed, my current avatar having been partly designed with it (it's a computer simulation of the old Spirograph game). With assembly, I did not have to use an HLL's function imposed on me to display pixels on the screen. I could even bypass the slow Windows' SetPixelV function!!!

Assembly is fun even with some HLL features

Raymond


When the winter break comes I plan on building a simple Z80 system, I'm gonna have some fun ;)
Posted on 2003-12-11 07:04:50 by x86asm
Sinclair ZX Spectrum and Amstrad CPC series used all the Z80 CPU. I remember,in early 90's,the only assembler for Amstrad was developed by a company named Hisoft.
Posted on 2003-12-11 12:07:05 by Vortex
Id like to change the thread title. :grin: "MASM is great. Use macros at own disgression." But shouldnt it be looked down on if people dont learn asm, only to use the macros? (not saying that icezilions tutorial was intended to teach asm..)
But does that happen? macro is to masm as visual basic is to programming. well, maybe not as extreme. (applying only to newbies, everyone else go about your business.)
Posted on 2003-12-11 12:50:49 by bnice2137
I think what has been missed with the original topic is that operating systems like Windows are primarily writen in C syntax so to write Windows code in assembler, you need to be able to handle C style syntax in a flexible and transparent way.

MASM long ago made the point that it can emulate C style programming and that has been its great strength that has resurrected assembler from the terrible code styles that used to be around to modern 21st century style code.

I have the next service pack for MASM32 in beta at the moment and it has substantially extended the library macro combination to improve code throughput so that assembler programmers can shift from hacking through crap like Windows API code and concentrate on algorithm design and useful productive code.


Case WM_NOTIFY
; ---------------------------------------------------
; The toolbar has the TBSTYLE_TOOLTIPS style enabled
; so that a WM_NOTIFY message is sent when the mouse
; is over the toolbar buttons.
; ---------------------------------------------------
mov eax, lParam
mov ecx, [eax+4] ; get the idFrom member
mov eax, [eax] ; get the hwndFrom member

Switch eax
Case hToolTips
Switch ecx
Case 50
fn SendMessage,hStatus,SB_SETTEXT,0,"Clear Editor"
Case 51
fn SendMessage,hStatus,SB_SETTEXT,0,"Open Binary File"
Case 52
fn SendMessage,hStatus,SB_SETTEXT,0,"Save Assembler DB file"
Case 53
fn SendMessage,hStatus,SB_SETTEXT,0,"Copy To Clipboard"
Case 54
fn SendMessage,hStatus,SB_SETTEXT,0,"Exit program"
Endsw
Endsw

This capacity is NOW, a switch case emulation macro by Greg Falen and a new macro in MASM32 that extends quoted text support to all API and other function calls. There are of course a lot more.

If this was "black box" style coding using DLLs, there would be good reason to be suspicious of it but it has the full source code available and the macros that make it faster and easier to use so it is pure assembler written in MASM that is fully accessible to the programmer who uses it.

The difference is a modern assembler is powerful enough to do this form of emulation and it is clear enough for programmers to extend and write their own libraries and macros so they can construct a pseudo high level language of their own in pure assembler.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2003-12-11 21:09:03 by hutch--
I fully agree with this point, however, I want to caution that you can get carried away with macros. At some point you have to remind yourself your still writing for assembler. Im personally not sure why your need a 'fn' macro to replace 'invoke'. Its a difference of 4 extra letters, however it will slow down the assembler more than it has to each time it encounters it. IMO, this is the hardest part of macro use and design (knowing when enough is enough).

Regards,
:NaN:
Posted on 2003-12-11 23:45:26 by NaN
NaN,

The fn macro loops through the parameters in any invoke call and when it find quoted text, it replaces it with an address in the initialised data section that contains the text.

It is actually calling a macro called "reparg" that does this on any parameter. There is also a choice of "testarg" to ensure that a quoted text is not put in the wrong place but this is not implimented in the "fn" macro.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2003-12-12 01:54:57 by hutch--
So with all this high level syntax, i should just say, "C might as well be MASM". Who needs C!? Though i do love C... and linux...
Posted on 2003-12-12 14:33:18 by bnice2137
The thing is that there are very few high level constructs in MASM. Macros like the one Hutch displayed are not part of the language. It is analogous with creating a procedure in C that saves a bitmap called _SaveBitmap and then saying that C includes that function. It does not, but it is possible to do it in C and you can put it into a library and use it as if it were. For myself I do not use macros at all, I find that they tend to blur the language and for the most part you can usually do better when dealing with things on a per case basis. The nice thing about MASM is that it allows for both eventualities.
Posted on 2003-12-12 16:08:05 by donkey
bnice2137,

I gather you are using NASM and also work in linux and together this is usually seen as a good combination. I know a number of guys who code NASM for linux who get very good results, usually in conjunction with a C compiler.

The approach I take with MASM which is usually Windows specific is to use its facilities rather than avoid them as it raises code throughput once you are familiar with how it works. I also have to address people with skills in other languages like C, basic or pascal who need to get up to pace in assembler quickly.

Leveraging their existing skills helps to make more people more proficient in assembler more quickly and it is why assembler is in its ascendency again. Fortunately with an assembler as powerful as MASM, you really do have the choice of very low to moderately high level programming styles and you can easily mix them.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2003-12-12 19:50:22 by hutch--