Operand types with AVX instructions

[jj2007]

MASM has been around since 1982 and is still current

"Current" but suffering from Alzheimer's disease: It has forgotten invoke, .if, .Repeat, .While, ...

[hutch--]

 

These are the joys of the archetypal MACRO assembler, write your own. There was a time once long ago when MEN[tm] wrote in a real assembler when an assembler was a bad mannered, terse buggy pig that screwed mnemonics together if you got it right. Truly ML64 continues in that tradition but then it was written for assembler programmers who did not need anyone to hold their hot little hand and help them through their many indiscretions.  :P

[jj2007]

a bad mannered, terse buggy pig that screws mnemonics together

So true :t

Here, a famous assembly programmer expresses it in different, more modern words:

The old brigade with crude mnemonic crunching as some notion of purity left assembler in a shambles, near abandoned and ridiculed in the programming community. The pseudo high level stuff in MASM resurrected it from the dead and made it a living language again. Most would not write C like they did in the middle 80s yet they expect you to write assembler in the way that people cobbled together a few DOS interrupts 25 years ago.

I fully agree with that view 8)

[hutch--]

 

I think you would have needed to have seen the crap that was being cobbled together by the majority in the late 80s, early 90s. There were a few exceptions with very good code but most was trash cobbled together with a few DOS interrupts to patch up defects in the compilers of the time. The last Microsoft COMMAND.COM was well done as was Keith P. Graham's BAT2EXEC but they were exceptions.

[rrr314159]

There was a time once long ago when MEN[tm] wrote in a real assembler

In the modern era, MEN[tm] use FASM. The BOY[tm]'s spend half their time using ML64 or HJWasm, the other half is spent debating which is best.

[hutch--]

 

I am sure you would be fluent in all of these to make the comparison.

[rrr314159]

Wrong again! As a beginner I tried FASM and could see it's an excellent tool. However the community just didn't seem interested in supporting an ignorant novice. Then I found masm32.com, where support for beginners (and, in fact, experts also) is far superior, and never looked back. Like you, I've always wanted to check out FASM more seriously someday but there's only so much time one can spend on this sort of thing. I have the vague impression FASM might be the best assembler, but don't actually know that. ML / HJWasm family is good enough for the likes of me, anyway.

[hutch--]

I am inclined to recognise difference rather than notions of better or worse when it comes to various assemblers. I know for certain that FASM is a very good tool, well written, reliable and powerful, the only problem I have with it is that I come from an Intel notation MASM background where FASM uses closer to a TASM style of notation so its a matter of familiarity rather than better or worse.

There are a number of assemblers I like, the GNU AS (GAS) with Intel notation is a good tool close to the running boards, Pelle's POASM works fine but I don't have the time to relearn all of the differences with its macro engine, JWASM could have been a good tool if Japheth had not abandoned it and John and Habran's HJWASM looks like it will be a decent assembler when its finished and supported properly. Much the same comment on Nidud's fork of JWASM.

Some wonder why I have chosen to work with a pig like ML64.EXE and the answer is simple, its a familiar pig with the same 1990 quirky buggy macro engine and while it comes unconfigured like the assemblers of old, with enough work it has an invoke macro that works correctly, a prologue that is reliable and with Vasily's many macros, it has the .IF notation so it can do whatever you need with x64.

Some assume that ML.EXE was easy to work with but in 1997 when Iczelion and I started working on it, it was a ridiculed, badly documented, bad mannered pig that few bothered with. It took a lot of work to get it up and going but it wiped TASM out because it was fundamentally a better tool and was properly supported. What I would like to see with both John and Habran's assembler AND Nidud's fork is a user base that actually got off its arse and contributed the necessary support to get them up and going for a wider community to use. MASM will always have licence limitations as it is owned by Microsoft where the Watcom forks can be used by a wider audience including the "open sauce" gang.

They need documentation like help files, macros, a dedicated library, import libraries and code examples. and here a community could help, its just that most don't want to get off their arse and do any work.

[rrr314159]

Some wonder why I have chosen to work with a pig like ML64.EXE and the answer is simple, its a familiar pig ...

You can't teach an old dog new tricks.

What I would like to see with both John and Habran's assembler AND Nidud's fork is a user base that actually got off its arse and contributed the necessary support to get them up and going for a wider community to use.

Good luck with that! It's got to be the laziest user base on the planet.

[hutch--]

 

I have this irksome habit of writing my own luck, old dogs can write new tricks.  :P

Shame about that lack of support for HJWASM and Nidud's assembler, with the right support they are both good tools.

[jj2007]

HJWasm and AsmC are both excellent tools, and 99.99% compatible with ML32. There is no reason to write anything specifically for them, just a bit of testing whether the macros work identically. MasmBasic has over 200 macros, they all work in the three assemblers.

With ML64, it's different, simply because HJWasm and AsmC are still excellent tools but their counterpart is a crippled child. It needs macros for elementary language elements like .if

Now, I am willing to concede that one could use a switch for that:

Code Select Expand

ifidni @Environ(oAssembler), <ML>
  .if MACRO args
  ENDM
endif

What I am not willing to accept is an invoke macro that can't control the number of parameters. This is essential for Windows.

[johnsa]

I've done quite a bit of work with FASM (mainly OS level dev stuff) and it is a good tool. For system level coding it's great, but as an assembler to use under Windows etc I find it to be a complete pain.

As much as I am a purist about assembler I also realise that for it be of much value in the broader sense it has to be as simple and practical as possible (especially when writing bigger projects), MASM32 + ML32 gave us that.. HJWASM for 64bit gives that same simplicity and convenience out of the box (plus a bunch of new things we're adding like vectorcall, improved unions, switch, namespaces etc).

Right now for me.. it is the only option, and I don't just say that because I happen to be supporting it :)

I think the work around a solid set of core libraries and includes is a fantastic idea, and I for one am happy to support such an effort in whatever flavour is best decided through democratic process (is there such a thing?)
:)

[rrr314159]

HJWasm and AsmC are both excellent tools, and 99.99% compatible with ML32. There is no reason to write anything specifically for them, just a bit of testing whether the macros work identically.

right

With ML64, it's different, simply because HJWasm and AsmC are still excellent tools but their counterpart is a crippled child.

It can be "uncrippled" via creative use of Macros but hard to see why bother. Lack of support is even bigger problem, from my pov. With HJWasm even if the team goes away someday, I have the code and can (at least) read it to answer questions. MS, OTOH, is entirely capable of "updating" Windows someday to make it impossible to use ML without a fee of $10,000 / year and giving first-born child to Bill.

What I am not willing to accept is an invoke macro that can't control the number of parameters. This is essential for Windows.

By "control number of parameters" you mean PROTO-checking? Why is that essential?

I've done quite a bit of work with FASM (mainly OS level dev stuff) and it is a good tool. For system level coding it's great, but as an assembler to use under Windows etc I find it to be a complete pain.

Don't doubt you're right; I have almost no experience with FASM. But can you give a couple examples why it's a pain?

HJWASM for 64bit gives that same simplicity and convenience out of the box (plus a bunch of new things we're adding like vectorcall, improved unions, switch, namespaces etc). I think the work around a solid set of core libraries and includes is a fantastic idea, and I for one am happy to support such an effort ...

Personally I don't care about namespaces and such. But I know many people love C++; to each his own. I think libraries, includes, boring stuff like that, is more important.

... in whatever flavour is best decided through democratic process (is there such a thing?)

Unfortunately democracy simply doesn't work, except in special circumstances like small Swiss villages hundreds of years ago (or whatever). It would be great if everyone were on the same page and worked together, but getting a bunch of independent programmers on the net to cooperate is like herding cats. What's needed is a dictator with a lot of money who tells everyone what to do, and pays them for it. Ain't gonna happen.

[jj2007]

By "control number of parameters" you mean PROTO-checking? Why is that essential?

Would you accept an assembler that from mow eox, someundefined var creates something for you without throwing error messages? Of course, RealMen^TM would never commit such typos 8)

Why was invoke invented, if not for parameter checking?

[hutch--]

 

> Why was invoke invented, if not for parameter checking?

Call automation, the type checking came as a bonus.