JWasm development has been resumed

[lucho]

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

[johnsa]

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..

[zedd]

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. 

I guess you could put any differences aside and collaborate.

[johnsa]

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 :)

[zedd]

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 :)

  Okay.

[16bitPM]

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 :)

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.

[_japheth]

Well 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 ...

[TimoVJL]

A true progress would be to support COMDATs ...

I share a that opinion, as it helps building static libraries 

[16bitPM]

Well 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

[TimoVJL]

Embarcadero/Borland still use OMF ?

For UAsm a ml feature -Gy would be useful with pe-coff

Code Select Expand

/Gy[-] separate functions for linker

[lucho]

Also 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 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 support in JWASM and UASM (easier said than done).

[Vortex]

Hi 16bitPM,

Also OMF could be used everywhere

The OMF object module format is outdated. It does not support 64-bit coding.