A month ago, the author of JWasm (on which UASM was based) released a new version of his assembler – 2.19:
https://github.com/Baron-von-Riedesel/JWasm/releases (https://github.com/Baron-von-Riedesel/JWasm/releases)
So helpful - why couldn't we just contribute the same fixes to the same project, now I'd have to trawl through these changes and diff and see what is applicable in UASM - pain in my arse..
Just let uasm be its own. Many folks like it. There are still a lot of jwasm fans, too.
No need to get your knickers in a twist. :tongue:
I guess you could put any differences aside and collaborate.
Lol - there aren't any differences - I'm just a grumpy old fart with limited time, so it would be nice if things were just "easy" haha :)
Quote from: johnsa on March 13, 2025, 02:15:37 AMLol - there aren't any differences - I'm just a grumpy old fart with limited time, so it would be nice if things were just "easy" haha :)
:biggrin: Okay.
Quote from: johnsa on March 13, 2025, 02:15:37 AMLol - there aren't any differences - I'm just a grumpy old fart with limited time, so it would be nice if things were just "easy" haha :)
Well if you ever get bored, you could start on LIDATA support for OMF ;-)
I've been looking into it for a while to learn, but I don't know where to start as I don't have experience with open source development. The relevant code (which is still based on WASM) is rather intimidating for me, TBH.
Quote from: 16bitPM on May 20, 2025, 12:39:54 AMWell if you ever get bored, you could start on LIDATA support for OMF ;-)
That's a strange suggestion. OMF is mainly used for DOS - 32-/64-bit Windows uses COFF format. Also, the virtually only benefit from supporting LIDATA is that the object module may become smaller - not really THAT important in times where HDs may usually store TBs.
A true progress would be to support COMDATs ...
Quote from: _japheth on May 20, 2025, 01:43:14 AMA true progress would be to support COMDATs ...
I share a that opinion, as it helps building static libraries :thumbsup:
Quote from: _japheth on May 20, 2025, 01:43:14 AMQuote from: 16bitPM on May 20, 2025, 12:39:54 AMWell if you ever get bored, you could start on LIDATA support for OMF ;-)
That's a strange suggestion. OMF is mainly used for DOS - 32-/64-bit Windows uses COFF format. Also, the virtually only benefit from supporting LIDATA is that the object module may become smaller - not really THAT important in times where HDs may usually store TBs.
A true progress would be to support COMDATs ...
It's an interesting problem.
Also OMF could be used everywhere; it's specifically developed for iNTEL x86 line of CPU's and we're talking about assembly here; there are still low-level and retrocomputing coders out there.
But I know it's a niche :P
Embarcadero/Borland still use OMF ?
For UAsm a ml feature -Gy would be useful with pe-coff
/Gy[-] separate functions for linker
Quote from: 16bitPM on May 20, 2025, 10:28:19 PMAlso OMF could be used everywhere; it's specifically developed for iNTEL x86 line of CPU's...
I also thought so, but it turns out that it has actually been developed for the 8-bit 8080/85 (https://www.os2museum.com/wp/how-old-is-omf/) as early as in the 1970s!
Albeit JWASM stems from the WASM used in Microsoft's operating systems, adding ELF support to it allowed its use in the Unix-like operating systems too. The next logical step in this direction could be adding DWARF (https://dwarfstd.org) support in JWASM and UASM (easier said than done).
Hi 16bitPM,
QuoteAlso OMF could be used everywhere
The OMF object module format is outdated. It does not support 64-bit coding.