1. Re-visited: No OpenWatcom in 4.1.0
- Posted by jimcbrown (admin) Apr 01, 2023
- 744 views
Forked from Re: Phix 1.0.2 uploaded
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.
2. Re: Re-visited: No OpenWatcom in 4.1.0
- Posted by ghaberek (admin) Apr 03, 2023
- 691 views
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
3. Re: Re-visited: No OpenWatcom in 4.1.0
- Posted by fizzpop Apr 03, 2023
- 667 views
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.
