Non-Forum Problems: Why not use a code repository

[zedd151]

Intel Wants to KILL 32-bit Mode in its CPUs - X86-S Explained

For me, 32 bit will last at least the rest of my life. I have zero intention of buying any new computer. I have two older models that run 32 bit Windows 7 Pro and they both run very well. One that I use every day, the other which is exactly the same - I keep as a backup 'just-in-case'. They also can both run 64 bit, but only up to Windows 10. Windows 11 needs a more up-to-date TPM 'Trusted Platform Module' so thankfully I don't run Windows 11. Windows 10 is bad enough and I only use it when necessary to look at 64 bit programs made by others.
Mikl__ seems a good choice for continuing development of the 64 bit SDK. I am sure there will be others who may want to pitch in and help with that effort.

[jj2007]

I don't have stakes in 64-bit Assembly, as I am so old that I will not see the end of 32-bit coding.

Are you sure about that JJ.

Yes, absolutely. What most people don't realise:
- Going from 16-bit to 32-bit was a fantastic improvement: 5 times faster, 2GB address space instead of 640kB, flat mode.
- Going from 32-bit to 64-bit was... what? Same speed (often slower), more bloat, and an address space that almost nobody needs.

64-bit was forced down our throats by hardware vendors. Users, however, will stick to their 32-bit applications as long as they can.

Intel Wants to KILL 32-bit Mode in its CPUs - X86-S Explained
https://www.youtube.com/watch?v=KSagW5gmPo4

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

Announcements are not action. They wouldn't be able to see such cpus.

[C3]

Yes, absolutely. What most people don't realise:
- Going from 16-bit to 32-bit was a fantastic improvement: 5 times faster, 2GB address space instead of 640kB, flat mode.
- Going from 32-bit to 64-bit was... what? Same speed (often slower), more bloat, and an address space that almost nobody needs.

64bit MASM uses fastcall calling convention instead of stdcall or c or other oldies. First 4 parameters use registers (rcx,rdx,r8,r9) instead of stack memory for parameters. Should be faster with not so much memory access overhead. I know they have done much for C++ coders to use newer instruction sets without using ASM. And 32bit platform allows only 4 GB of memory for a process, not like I'm going over it soon, but maybe someday I need that too.

We have to preserve what Hutch made, it's quite a big package, but there aint everything I needed, so it under developement I guess.

And last, many of you have contributed to both MASM32/64 packages. I have to say thank you for what you have done. I like your code postings very much too. As a ASM "beginner" 

[C3]

BAD POSTING 

[Mikl__]

I'll start, and the rest will catch up. I have only one question so far - where to write about SDK64 in the MASM64 SDK section or in Mikl__'s ml64 examples section? I don't know (and will never know) Hutch's plans for SDK64 so I'll start from scratch and gradually add examples that Steve has already written...

[jj2007]

Hi Mikl, I had hoped you would volunteer for the Masm64 SDK

You have this wonderful 64-bit examples thread, which unfortunately not many people (including myself) have commented on. That's an excellent start, and I am sure Hutch would be happy to see you in charge of Masm64

[Caché GB]

Hi zedd151

I hope you are doing well. Thank you so much for replying to my post. Not many members do.
It's probably my dry-wit humour. I shoud put a trigger warning before I post.

I get what you saying. That been said, obsolescence can bite when least expected as every
corporation builds it into there products.


Hi JJ

We've had this discussion before.

http://masm32.com/board/index.php?topic=7238

That time I lost. This time I'm going for a draw.
So I hope you live long, see the end of 32-bit, and prosper - Vulcan salute.


Hi C3

WARNING!!! - Dry humour to follow.

At the risk of you becoming C4, who's posting was bad?

[fearless]

So we cannot improve, develop, bugfix or typofix MASM64 SDK through a code repository right? Sooo, what can we do?

We can make an open source version of the masm32 library and/or the masm64 library. I started some of that with a 64 bit version port of the masm32 library a while ago: https://github.com/mrfearless/libraries/tree/master/Masm64 - but anyone can create similar named functions to help others use x86 or x64 assembler code. The include files for an open source version could easily start with the WinInc files and progress from there. Ideally an automated solution to convert existing win32 header files to asm include would be the end goal - some attempts have been looked at and tried a while ago by Biterider using the microsoft metadata for windows header files located at github.


Food for thought.

[HSE]

That is a violation of license terms. MASM32 is free source, not open source. Explicitly, you can not make "open" things.

Because you don't declare a license, what you makes is not free nor open, is just your thing, and anybody using that is subject of legal enforcement.

Obviously, if you are violating licences you are subject of that problems first.

[zedd151]

The Masm32 Project License can be found in the masm32 directory:
<drive letter:>\masm32\licence\licence.htm

[jj2007]

I doubt we will see the end of 32 bit any time soon.

@Caché GB

So we cannot improve, develop, bugfix or typofix MASM64 SDK through a code repository right? Sooo, what can we do?

We can make an open source version of the masm32 library and/or the masm64 library. I started some of that with a 64 bit version port of the masm32 library a while ago: https://github.com/mrfearless/libraries/tree/master/Masm64 - but anyone can create similar named functions to help others use x86 or x64 assembler code. The include files for an open source version could easily start with the WinInc files and progress from there. Ideally an automated solution to convert existing win32 header files to asm include would be the end goal - some attempts have been looked at and tried a while ago by Biterider using the microsoft metadata for windows header files located at github.

Food for thought.

Indeed, but let's tread carefully with Hutch' legacy. He would rotate in his grave if we came up with an open source version of the Masm* library...

Anyway, more updated versions can be downloaded from Microsoft, exactly what we make with 64 bits tools.

That would be prohibitive for a n00b who wants to "have a quick look". So we better clarify whether the old license is valid.
There is UAsm, of course, but Hutch had his reservations, as we all know...

A similar problem. Plus, if "anyone can create similar named functions to help others use x86 or x64 assembler code" (fearless), there is a risk to end up with a dozen competing Masm64 versions (I have my own one, of course, but don't use it - see Dynamic vs static linking, or search for JBasic).

This is a delicate discussion. It is relatively easy for the Masm32 library: we can just keep the original archive, and optionally offer an improved version with a more straightforward installer, UAsm instead of the March 1999 ml.exe, and a few bug fixes in the Windows.inc file.

For Masm64, it gets tricky precisely because Hutch...
a) liked Microsoft MASM and therefore chose Vasily's .if eax { ecx macros;
b) wrote a nice library

...while others...
a) preferred the .if eax < ecx syntax and therefore used UAsm (or AsmC);
b) but didn't write an equivalent library.

Now the last point might be unfair to fearless, but that points to another problem: I had never heard about it. GitHub is full of projects that have no community such as this forum. Maybe fearless' library is a mature project, and a serious alternative to Hutch' Masm64?

You see why it's a delicate question? We need to discuss that patiently - there is no hurry. The extreme options are 1. an eternally frozen version of Masm* ("we cannot improve"), 2. an awful mess of competing versions that makes everything fall apart.

[daydreamer]

I want to port/ improve simd with help of 16 simd registers in 64 bit
It's the right way to keep cool and continue coding
Register starved 32 bit or lots of push/ pops in code, 64 bit has 16 gp regs
SIMT easier to have lots of memory hungry threads/cores in 64bit

[bluedevil]

So we cannot improve, develop, bugfix or typofix MASM64 SDK through a code repository right? Sooo, what can we do?

We can make an open source version of the masm32 library and/or the masm64 library. I started some of that with a 64 bit version port of the masm32 library a while ago: https://github.com/mrfearless/libraries/tree/master/Masm64 - but anyone can create similar named functions to help others use x86 or x64 assembler code. The include files for an open source version could easily start with the WinInc files and progress from there. Ideally an automated solution to convert existing win32 header files to asm include would be the end goal - some attempts have been looked at and tried a while ago by Biterider using the microsoft metadata for windows header files located at github.


Food for thought.

Even though this might not be accepted by the community but I share the same thoughts with fearless  . This is the more logical, more sustainable and more "community-way" for developing an assembly SDK. Both MASM32 SDK and MASM64 SDK are hutch--'s personal projects. He even created a special license for his project. He is not with us bu we "the community" is here. Some of us are more active some of us are less active.

That is a violation of license terms. MASM32 is free source, not open source. Explicitly, you can not make "open" things.

Because you don't declare a license, what you makes is not free nor open, is just your thing, and anybody using that is subject of legal enforcement.

Obviously, if you are violating licences you are subject of that problems first.

I thinks fearless wants to say creating a very new open source project, not to open source MASM64 SDK.

Still, I am all OK community's decision!

[jj2007]

This is the more logical, more sustainable and more "community-way" for developing an assembly SDK

MASM is competing with FASM, NASM and TASM (UASM is 100% MASM-compatible, so doesn't count here)
There are already at least 3 competing Masm64 packages.
How many users do (in alphabetical order) GoAsm, EasyCode, HLA, ObjAsm, PoAsm, RosAsm, SmplMath, SolAsm have?
How many users does MasmBasic have? (one)
How many distros are calling themselves "Linux"? (over 600...)

There is exactly one Masm32 package, and all its examples work fine on Win98...Win11.

How do you define "sustainable"?

You see why it's a delicate question? We need to discuss that patiently - there is no hurry. The extreme options are 1. an eternally frozen version of Masm* ("we cannot improve"), 2. an awful mess of competing versions that makes everything fall apart.

[fearless]

I thinks fearless wants to say creating a very new open source project, not to open source MASM64 SDK.

Yes, exactly. As the license states "None of its components or source code are redistributable", which means any "MASM" library functions would have to be coded differently and written from scratch, and doesn't have to include the name "Masm", "Masm32" or "Masm64" - could just be called asm.lib or asm86.lib/asm64.lib or whatever.

A compatible recreation of the masm library is all I am suggesting as a possible option.

A new sdk is a different thing, although as I mentioned before using WinInc for the includes could be used as a starting point. Creation of libs can be done with batch files or collated from other sources or using other tools to create them. But a compatible and full sdk is beyond what I was suggesting.