Missing operator in expression

[jj2007]

I think print shld preserve registers, don't need the byte count. ... "deb" doesn't return byte count in eax!

deb is a special debugging macro: it doesn't alter flags or registers, but it does indeed insert a lot of extra code (about 500 bytes at least, but you can switch it off with usedeb=0). Whether an ordinary print should trash eax is arguable; where do you stop? print str$(eax) would require preserving eax (and edx, ecx) in print and in str$(). Same for hex$ and bin$, of course; and numerous other commands. In MasmBasic, I decided to preserve ecx everywhere, and I never regretted that - it is a very useful register. But eax and edx??

This is the best/only way to do it: produce your own candidate "better" macros package and hope everyone uses it (roughly speaking). But as with Linux, probably no "standard package" can get more than, say, 20 or 30% of users.

I guess the Masm32 community is neatly split in three parts:
- too noob or too lazy to write own macros
- macro fans who write their own stuff (you, me, qWord, ...)
- macro haters who want to feel the bare metal.
And of course there is Hutch, who wrote most of the 400+ macros in macros.asm 8)

I have actually no idea how many people use MasmBasic, and I assume qWord also doesn't know how many use SmplMath. Download figures say nothing, it could even be robots. What is certain is that I do use my own macros quite a lot.

Talking about standardizing I'd say it's more important to standardize on an assembler, like H/JWasm, which is the most popular around here (and my fave). But there are other worthy candidates, all with happy users, so that's not gonna happen any big hurry either. MASM is stuck with "too many versions", so, look on bright side: diversity, freedom of choice, Open Source Software, etc.

I can't see a "too many versions" problem. Code that was written for ML 6.14 will work for ML 10.0 and for JWasm, including Habran's version. Sometimes JWasm is a bit tricky, but all my macros work with all versions of the MASM family. The same is probably true for all code in \Masm32\examples.

But they do have one advantage: under active development

Hutch made a huge and radical change to Masm32 about three years ago: Unicode builds. Since then, improvements have been more incremental, of course. Do I understand correctly that you volunteer to handle the switch to 64 bits?

(I won't, because there is that deep conviction in me that while the switch from 16 to 32 was a huge improvement, the switch to 64 is just a marketing thing with zero gain in terms of speed...)

[hutch--]

Back when the MASM32 project was first started, the existing situation was a never ending supply of incompatible prototypes, macros and code that no-one else could build along with the propaganda that assembler code was unwritable. I worked with a number of other people, Iczelion being probably the most consistent and creative, to put some reasonable order into the then emerging 32 bit assembler community. Iczelion was more up to date with 32 bit mnemonics than I was at the time, I wrote working 32 bit code but was still thinking in 16 bit mode but I had far more mileage in Windows API code than the other guys and deliberately bulldozed a modern architecture that could use a lot of the then current reference material.

As quick as possible the lack of a built in runtime library was addressed and a number of people contributed to the original MASM32 library and anything that looked useful was added to the macro file so that a person interested in trying to write assembler had something to start with instead of the cold turkey/high failure rate that plagued assembler programming before that. The general result allowed for a wider range of programming styles from low level mnemonic grinders to pseudo BASIC simplicity and this kept more people happy more often and produced a far higher number of competent assembler programmers than the nonsense that has been around for years before.

The idea was to produce a core system that worked but did not act as a straight jacket for new ideas. Wide ranging API prototypes, constants and structures that were reliable made this possible and also made people exchanging and sharing code viable. The idea of keeping the core architecture reliable and predictable meant that people who wrote something some years ago did not end up with broken code that would no longer build. Assembler as a discipline has never been about soft options, at its best it is a terse uncompromising endeavour that will jump up and bite you if you part your hair the wrong way yet if you learn the discipline, it allows you amazing architectural freedom and almost unlimited power and this is because essentially an assembler (MASM in this case) is an industrial tool for screwing mnemonics together, not a kiddie level (hold your hot little hand) pile of junk.

Most of the older fellas know how to write code like an assembler dump and being able to write this type of code if often virtuous for specific tasks but dumping a beginner with a pile of this stuff is a surefire way to scare them back to JAVA or DOT.WOT.

[rrr314159]

I think print shld preserve registers, don't need the byte count. ... "deb" doesn't return byte count in eax!

deb is a special debugging macro: it doesn't alter flags or registers, but it does indeed insert a lot of extra code (about 500 bytes at least, but you can switch it off with usedeb=0). Whether an ordinary print should trash eax is arguable; where do you stop? print str$(eax) would require preserving eax (and edx, ecx) in print and in str$().

- As I said, opinions differ, that's why would be fruitless to want to "improve" macros.asm. Rather, I'm glad we have flexible customizable platform lets everyone do as they wish. But, re. "drawing the line" I would say,

1) debug macros: preserve regs and flags, as u say
2) printing and anything involving human output/input: preserve all regs, except for useful return vals. My reasoning, if humans are involved (out to or in from) speed is completely negligible, and preserving only takes couple extra bytes
3) macros where speed (or bytes) important, preserve almost nothing. If I want to, on a particular use I can push/pop across it myself.

- In your example print str$(eax) ... I don't use str$, rather do it the C way with format string, like, 'prnt "eax = %i", eax'. But if doing it the Basic way wouldn't hesitate to preserve reg's twice: it's only printing! And if u examine the algos involved u'll probably find only one or two (eax, edx) need push / pop. OTOH using sprnt (print to a buffer) it's optimized more for speed, in such I don't preserve even ecx always. It's only for my own use, so I can remember the idiosyncracies of particular macros.

- Hey, u pays yer money u takes yer choice

I guess the Masm32 community is neatly split in three parts:
- too noob or too lazy to write own macros
- macro fans who write their own stuff (you, me, qWord, ...)
- macro haters who want to feel the bare metal.

- from my perspective leaving out the most important category (which includes myself): "macro lovers who want to feel the bare metal". By writing my own, I still feel I'm riding right on the silicon. But that's what u are calling a "macro fan" .. matter of opinion how u look at it

And of course there is Hutch, who wrote most of the 400+ macros in macros.asm

- I'd say he's another "macro fan" like u, me, and qWord. Although let me say I feel a bit out of my league, with u guys, who are still ahead of me in sheer output also knowledge. But I'm getting closer ... !

I have actually no idea how many people use MasmBasic

- interesting to know, bet u could come up with decent guess if u put your mind to it

Talking about standardizing I'd say it's more important to standardize on an assembler like H/JWasm, ... But there are other worthy candidates ... MASM is stuck with "too many versions"

I can't see a "too many versions" problem. Code that was written for ML 6.14 will work for ML 10.0 and for JWasm, including Habran's version.

- Hmmm, think I'm using the acronym "MASM" incorrectly. I meant to include Fasm, Yasm, GoAsm and other dialects of Intel assembler. With those, I'm sure u'll agree there are "too many versions"

Do I understand correctly that you volunteer to handle the switch to 64 bits?

- I have come to a momentous decision (!) - forget about "switching" to 64 bit! For one thing 32 is hanging around for at least another decade. The advantage of 64 bit (xtra registers) is just not enough for most people (tho it is for me), plus there's the disadvantage of larger builds. And even for me I can't afford to become incompatible with all u 32-bitters, even tho I work mostly by myself. But the good news is it's extremely easy to write macros / code compatible with both, so that's what I do. I would volunteer to "handle the switch" to 32 / 64 bit "hybrid" u might call it ... depending on just what's involved! Hate to have to "guarantee" some macro works - what's the punishment if it screws up? And how do i know it works on your computer, or dedndave's, or the fellow behind the tree's? Put it this way, if anyone wants to see how I do 32 / 64 happy to explain it and post more macros than u can shake a stick at. And I'd like to learn about, and fix, problems that might arise with other computers / operator systems. Would require cooperation (testing) from community

I won't, because there is that deep conviction in me that while the switch from 16 to 32 was a huge improvement, the switch to 64 is just a marketing thing with zero gain in terms of speed...

- As said I no longer recommend "Switching" (forget if I ever did, actually). But 32 / 64 is like "less filling and tastes great": u can have both!

@hutch: "Most of the older fellas ..."

- what other type of fellas are on this board?

[hutch--]

>  what other type of fellas are there on this board?

When you could read a CodeView debug as fast as your own code, you know you got it right.  :P

[rrr314159]

CodeView my butt ... in my heyday I read octal as fast as my own code; in fact that was my own code! That was later 1970's. I looked exactly as I do today but less distinguished

[hutch--]

Yes, I confess this was after punch cards.  :shock:

[rrr314159]

Hollerith was a great man, but I preferred paper tape - had plenty of uses, e.g. you could tie packages with it. I may have told u this story b4 ...?

Showed up at math class w/o a tie, was sent back to the dorm to get one (strict high school). So tied some paper tape printout around my neck (it actually encoded a printout of very primitive character-graphics Playboy centerfold) and went back to class. The professor went berserk - I got 3 demerits and the admiration of my fellow students. those were the days. I looked exactly like I do today, but less distinguished