1. Re-visited: No OpenWatcom in 4.1.0

Forked from Re: Phix 1.0.2 uploaded

fizzpop said...

Similarly I tried ( a few times over the years) to upgrade from eu 4.05 to eu 4.10 but could never get around the problem where I cannot compile in Watcom, the compiler insists on assuming GCC even when I explicity say Watcom. So, I'm still on eu 4.05

This was a deliberate choice. OpenWatcom was dropped because, at the time, we had recently introduced 64bit support, OW did not have it (yet), and we thought we would release very soon. That was ... a decade ago?

Nowadays, OW has had 64bit support for a long time ( see https://www.japheth.de/JWasm.html ) so perhaps it makes sense to revisit this decision.

new topic     » topic index » view message » categorize

2. Re: Re-visited: No OpenWatcom in 4.1.0

jimcbrown said...

This was a deliberate choice. OpenWatcom was dropped because, at the time, we had recently introduced 64bit support, OW did not have it (yet), and we thought we would release very soon. That was ... a decade ago?

Nowadays, OW has had 64bit support for a long time ( see https://www.japheth.de/JWasm.html ) so perhaps it makes sense to revisit this decision.

Agreed. I think Shawn's suggestion of de-platforming the build system would be the path forward here: https://openeuphoria.org/forum/136852.wc. Most of the "E" macros used in the backend like EWINDOWS, ELINUX, etc. can be replaced by mostly-portable "standard" macros like _WIN32, __linux__, etc. and unique platform/architecture/compiler settings (like Watcom/GCC gotchas) should live in euphoria.h (which is used by the translator) and the translator itself should be stripped of any platform requirements and accommodations altogether. Historically I think a lot of this was in place because Rob was working what was available at the time, and modern C tooling has come a long way in the twenty years since the translator was released. I also think the translator could be greatly simplified in both its internal complexity and the complexity of its output, and we could/should rely more on compiler flags/optimizations instead, but that work is much further down the road. And as I mentioned in Shawn's thread from last year, I'd also like to bundle TCC with Euphoria to be the "default" compiler for translating code. This would be further assisted by cleaning up and generalizing the translator's compiler support.

-Greg

new topic     » goto parent     » topic index » view message » categorize

3. Re: Re-visited: No OpenWatcom in 4.1.0

Hi,
Could be I didn't read enough of the v4.1.0 docs to see that Watcom wasn't supported anymore.. I'll check!
But it seems very likely that this is a PEBKAC (Problem exists between (my) keyboard and chair) ;)
It makes sense to drop 32 bit support if all OS are 64 bit, even though I don't see
the vast majority of users writing any app needing 64 bit address space.
My Euphoria apps never consume more than 2Mb while running.. the biggest sizing issue I had was trying to write to over 200 files at the same time for a reindexing data operation.
My workaround was to open/close each file whenever doing a write.. That slowed down the app a LOT even though my drive is SSD.
Its a Windows file limit issue, not Euphoria.
Using a database with multiple tables would have been another solution.
My largest app is over 2000 lines of source code without includes, and 32 bit is still fine. Speaking for myself of course.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu