Instruction Set Detection including AVX-512 sub-sets

[Gunther]

Jochen,

No need for strong declarations here: UAsm is in practice 99% compatible with MASM, and 100% for the things that beginners use (there are only a few exotic cases in macros etc where UAsm differs from Masm). And while some beginners are apparently forced into that course, they are not a relevant target group IMHO. However, even these poor students can use UAsm as if it was Masm.

But one problem with the forks (UAsm + AsmC) is indeed that they have new fancy features that can cause trouble, either because the experts who are supposed to use them don't read the FM, or because the experts developing them got lost in too much detail ;)

I'm all in your opinion. But you know yourself (do not feed the troll), some people should not even be ignored. The reason is simple: these people are coming before the good Lord. God knows everything, but these people know everything better.

I firmly believe that it would be wiser to discuss these issues in a separate thread in the Soap Box or in the Colosseum. There, of course, you have to expect that is discussed again in a circle. But everyone can then decide for themselves whether he wants to post or not.

Gunther

[johnsa]

"or because the experts developing them got lost in too much detail" ...

That's why we have JJ around :) If we break it, he'll find it!  :t

I think the important point is that although we're maintaining and building uasm.. it's for everyone.. so if you have ideas/suggestions I'm always listening, so possibly unlike other tools like masm or even nasm where really the community has very little say.. we can always accommodate or debate and find solutions that work, and I like to think that we're the easiest going most approachable people ever, who respond to emails and  hopefully give a real quick turnaround in making fixes or updates :)

[jj2007]

That's why we have JJ around :) If we break it, he'll find it!  :t

I will find it automagically because somewhere in my fat sources a particularly weird little macro will say "oops, that was unexpected" - and then our dream team johnsa & habran have sleepless nights :P

To be fair, others (and in particular José) have put more work into identifying the little bugs. There are not many left anyway, it's fine tuning time :t

UAsm is a great achievement. It beats the original hands down in terms of speed, and that counts a lot when the asm sources grow a little bit bigger. Plus, it is almost bug free, in contrast to the latest ML64 versions. But still, my recommendation would be to concentrate on making UAsm perfect rather than adding new features. Most of them can be implemented with macros anyway.

In 64-bit land, the biggest problem IMHO is not the assembler but the missing equivalent to the Masm32 SDK. Hutch is working hard on a 64-bit SDK, and he is brilliant at that, of course, but he decided to serve only ML64. I couldn't care less because I am not at all interested in 64-bit code, but I believe the success of the Masm32 SDK can't be repeated if coders are forced to use exotic stuff like .if eax}=ecx 8)

[hutch--]

I commend your rate of persistence but the ugly facts keep raising their ugly head.

1. It is already development/application capable.
2. MASM in various forms has been around for 30 years.
3. It is designed for assembler programmers, not script kiddies.
4. If you can't manage 64 bit MASM, get a visual garbage generator.  :P
5. If ".if rax {} 1234" is too difficult for you to handle, do it with mnemonics like REAL MEN[tm].
6. If you want a compiler, try CL.EXE, its the industry standard.
7. 64 bit MASM is a standard component of Microsoft VS, it has a massive level of distribution.

After waiting for years for Japheth to actually finish JWASM for 64 bit and still not seeing HJWASM/UASM finished after years of work, I use MASM because its here, now, up and running and it produces what code you can write correctly, no hot little hand holding, easily able to create libraries, does not have a pile of specification clutter that you have to negotiate at the front to get it to build 64 bit code and it has the normal manners of most decent assemblers, truly intolerant, terse notation, bites the hand that feeds it and pelts garbage at you if you get it wrong. 

PS : The MASM32 SDK will never be repeated, it came from a world that no longer exists, many clever people worked on it, Iczelion and a number of others on NDAs who will never be identified who contributed code, ideas and testing. What is missing is the collaborative effort as those people no longer exist, I am a dinosaur from that era where people contributed rather than just suck the life out of what was available.

[jj2007]

I commend your rate of persistence

My apologies - I didn't intend to step on your toes :icon14:

[johnsa]

I commend your rate of persistence but the ugly facts keep raising their ugly head.

1. It is already development/application capable.
2. MASM in various forms has been around for 30 years.
3. It is designed for assembler programmers, not script kiddies.
4. If you can't manage 64 bit MASM, get a visual garbage generator.  :P
5. If ".if rax {} 1234" is too difficult for you to handle, do it with mnemonics like REAL MEN[tm].
6. If you want a compiler, try CL.EXE, its the industry standard.
7. 64 bit MASM is a standard component of Microsoft VS, it has a massive level of distribution.

After waiting for years for Japheth to actually finish JWASM for 64 bit and still not seeing HJWASM/UASM finished after years of work, I use MASM because its here, now, up and running and it produces what code you can write correctly, no hot little hand holding, easily able to create libraries, does not have a pile of specification clutter that you have to negotiate at the front to get it to build 64 bit code and it has the normal manners of most decent assemblers, truly intolerant, terse notation, bites the hand that feeds it and pelts garbage at you if you get it wrong. 

PS : The MASM32 SDK will never be repeated, it came from a world that no longer exists, many clever people worked on it, Iczelion and a number of others on NDAs who will never be identified who contributed code, ideas and testing. What is missing is the collaborative effort as those people no longer exist, I am a dinosaur from that era where people contributed rather than just suck the life out of what was available.

As far as I'm aware there shouldn't much left to complete in UASM especially for Windows based development? If I'm missing something let me know ? :)
My next chunk of work is adding Dwarf debug output for OSX and Linux which should bring those platforms in line with what is possible on Windows tooling wise (apart from the lack of a decent debugger.. I detest GDB). We're also working on a revised Codegen system which will automatically generated opcode maps and instruction tables from the intel/amd documentation, and with a much more flexible extensive instruction table format we're aiming to reduce the codegen size by about 70%, parser by about 15% and would expect 2X performance increase of the codegen portion of the assembler. I've spent a lot of time putting the automated regression testing in place, so that bringing in the new codegen should be flawless in terms of opcode generation.

Once this is in place I will be working on a set of 64bit run-time libraries ( my idea is to create both procedural and OO forms ), including the built-in macro library and converting/updating wininc to include dx, opengl, vulkan, asio etc..

[hutch--]

You are not the target here John, I just get tired of hearing the same crap over and over again. I don't personally care what anyone uses and I have used some shockers over time myself but I don't foulmouth the GNU as assembler (GAS), Tomas's FASM, Bogdan's assembler or anyone elses tools but I will not be subject to abuse for not kissing the arse of open "sauce" or using Microsoft software.

[Gunther]

You are not the target here John, I just get tired of hearing the same crap over and over again.

I feel the same way.

I don't personally care what anyone uses and I have used some shockers over time myself but I don't foulmouth the GNU as assembler (GAS), Tomas's FASM, Bogdan's assembler or anyone elses tools but I will not be subject to abuse for not kissing the arse of open "sauce" or using Microsoft software.

That's true. GAS does a good job. And Bogdan's Sol ASM is also a solid tool that you can work with very well. For me, there is no reason at all to look arrogantly at the tools of other programmers.

Gunther

[johnsa]

I had some great times with FASM, it was the only tool that worked for me doing OS development in ASM without a lot of pain, it's where I "borrowed" the idea of flat mode for UASM, which makes writing mixed mode code much easier.. I've got a pretty complete legacy+pxe+uefi bootloader + 64bit smp kernel running now (one of my other little projects) :)

[hutch--]

Something I needed to add, long ago when I first worked on the MASM32 project, I worked with a number of very talented people to get enough code, ideas and testing done. What I would like to see with UASM is a collection of its users get off their arse and contribute to the endless work that John and Habran have done to get UASM up and running.

Header file are incredibly tedious things to get up and going, I note with some humour that the windows.inc developed over time for the 32 bit MASM32 SDK have contributed to many other projects with different assemblers. Vasily's include file had vast amounts of the masm32 windows.inc in it and over time I have seen many others use bits of it.

The next item on the agenda is writing library modules. This is at least PHUN if you like writing algorithms but it can be just as tedious as writing header files as without an extensive library of among other things, API components for Windows, the assembler is crippled down to the level of console apps. The UNIX guy will also have to do something similar.

Lastly the only thing I hate more than fixing header files is writing CHM help files. It is a soul destroying grindingly irritating task but without it the potential user base has no real way of understanding what the assembler can do.

For those who want to see UASM become a widely accepted programming tool, the time to step up and actually do some work is now, people hanging around sucking the life out of the project and not contributing are not making it any more successful.

[rsala]

The 64-bit version of Easy Code v2 is always compiled with UASM64. I always test the UASM new versions and report any issue to John. Also, all ".inc" and ".lib" files included with EC v2 are always tested with UASM64 and they are fully compatible. All included example projects for UASM, both 32-bit and 64-bit are always tested and work fine.