Please support cross‑compiling for old ᴡɪɴᴀᴘɪ architectures.

[ytrezq]

Windows® and visual studio supported Alpha; PowerPC; Mips and IA64 in the past. Despite it restricts to outdated windows versions, getting those is the best way to run desktop ᴡindows® apps if you have the source code.

So I'm asking this feature request to the compiler which will supports C11 and C++99 for eComStation modern 80286 compatible SoC (I’m especially thinking to the ᴄᴀꜱɪᴏ one which I got last year).
If you do it, I’ll be able to distribute binaries for those platforms by using a single compiler with the same version.

Update : I found a Qemu way to run ᴡindows‑ɴᴛ for ᴍɪᴘꜱ on x86.

[jmalak]

What exactly you mean? It is hard because nobody is testing these platforms.
If you want to contribute by testing on these platforms you are welcome.
I don't plan to remove DOS support, but Windows 3.x support is a question.

[ytrezq]

@jmalak : That windows up to NT 3.51 supported PowerPC and up NT 4.0 Dec Alpha; MIPS (and some others). Windows 2008R2 and XP were available for IA-64. Today no compiler support those platforms (ᴍꜱ Visual droped support).
But if you only have those kind of machines, then using one of those Windows® version is the best way to run Software written for the ᴡɪɴᴀᴘɪ (include win32 win16 win64 and others). (please also note PowerPC PC machines are still being produced by some manufacturer. I own a recently MIPS manufactured box). I also use Open Watcom for creating ᴡɪɴ16 graphic software for my 4MB high‑end laptop (it use a 486 but even the linux kernel require more ram, so use windows 3.11 which have limited 32 bits support, ᴏpenwatcom is the last to support it).

[jmalak]

These platforms are probably broken, because they are untested anyway after uplift OW code to 64-bit host. It can be supported if anybody will test it. I dont have any suitable hardware and OS for testing these platforms.

[ArmstrongJ]

I was under the impression that the non-x86/x64 code generators were not in a "working" state at the moment. The Open Watcom site specifically stated that MIPS did not work any longer. I'd be surprised if the AXP generator worked still. Given that Windows MIPS and PowerPC hardware was almost non-existent even in its heyday (except for, technically, the Xbox 360), supporting those platforms would be a ton of work for little to no payoff.

I'm aware that PowerPC hardware is still being produced. However, I don't know of any currently produced PowerPC hardware that can boot Windows. A specific firmware was necessary to start Windows. It couldn't just start on any arbitrary PowerPC system.

Alpha Windows hardware was significantly more popular. Again, though, like @jmalak stated, we'd need hardware or a qemu instance (already configured...) to test on. However, since @jmalak is focusing on x64 (and rightfully so), Alpha support might and probably should be deferred for now.

I don't think IA-64 support is a good idea at all. The Itanium is an extremely complicated chip (VLIW), and we should definitely stay away from it. If we want to look at supporting a completely new architecture, ARM makes far more sense than Itanium.

[davidrg]

I tried Alpha support a few years back and did get it working in v1.7.1 but getting it built involved a few manual steps to build the libraries. I attempted it in v1.9 more recently but hit some problem (probably just some minor build issue).

The AXP generator does/did actually produce programs that will run on a real Alpha making it the only generally available Alpha Windows NT compiler. I managed to build some simple Win32 apps with it and run them on one of my Alphas no problem. It can't build itself though - something missing in the code generator apparently. Might not be a huge amount of work to fix given it does work for simpler programs.

I've read the MIPS and PowerPC generators were in a much earlier stage of development when the project was canceled and so aren't finished enough to do anything useful. MIPS support would be easy enough to test in an emulator though if you can find an NT4 CD (http://virtuallyfun.superglobalmegacorp.com/2009/08/02/mips-blast-from-the-past/), PowerPC I guess might need real hardware. I've considered trying to get it going on my RS/6000 7248 but never bothered due to the PowerPC generators supposedly broken state.

[ytrezq]

@davidrg : Winworlpc distributes ɪꜱᴏ for all versions and platforms.
There is even a ᴡindows 2000 ᴄᴅ for ᴅᴇᴄ Alpha.
Please also send me your working Alpha build.

@ArmstrongJ : I have doubt about if supporting the new ᴀʀᴍ and ᴀʀᴍ64 is worthwhile as unless the system is hacked with a debugger, the executables (.dll .sys nls .exe) need to be signed by Microsoft.

[davidrg]

@ytrezq I can't find my AXP cross-compiler (it was quite a while ago I was playing with it) but my notes on how to build it are here: http://www.ext.zx.net.nz/software/notes/watcom-axp/. I've only tried running the binaries it generates on NT 4 SP6 - no idea what support for NT 3.x or Win2k RC2 is like.

[ytrezq]

@davidrg : Your page is suggesting that Microsoft Visual C++ RISC edition can work as cross‑compiler. I may be wrong but it seems RISC editions never existed as cross compilers.

[davidrg]

@ytrezq You're correct - as far as I know the RISC edition only runs on the real hardware. I've got several Alphas and at the time I was looking for a compiler to actually run on the real hardware so I wouldn't have to bother copying the generated binaries between machines whenever I wanted to test them. So Visual C++ RISC edition was the ideal choice - but its not on MSDN anymore (apparently contained the MS JVM) and too expensive second-hand. The OpenWatcom cross-compiler was my Plan B.

[ytrezq]

@davidrg : Remember there are this and this for testing.

Are you sure the 386 ɴᴛ ɪᴅᴇ support alpha compile switches ? I started a project and went to the ᴄᴘᴜ flags (10. Memory Model and Process Switches) and there are only x86 options.

[davidrg]

@ytrezq RE: compile switches - the v1.7 source release certainly includes them. It actually produced the Alpha, MIPS and PowerPC cross-compilers and included IDE support for at least the Alpha cross-compiler by default. All I had to do to make it usable was manually build all the libraries in the right order (I assume they're only excluded from the normal build to speed things up as they built fine).

As the released v1.7 binaries don't include IDE support or the cross-compilers I assume the OpenWatcom team has just been stripping them out by hand as part of the release process or there is some other build option to disable Alpha support. I wouldn't be too surprised if this has been automated in v1.8 or 1.9.

[ytrezq]

@davidrg  : Sorry I forgot to say ɪᴅᴇ not the wall compiler itself. And yes I used 1.7.0 to build 1.7.0 and still find nothing in the ɪᴅᴇ even for Alpha. Maybe are you talking about the native one under the axpnt directory ?

[davidrg]

@ytrezq I managed to find my Alpha cross compiler from back in 2012. The IDE reports itself as 1.7 and was produced with the instructions I posted earlier. The IDE has "Alpha Win32 (NT/Win95/Win32s)" as an available target (the list of supported OSes is obviously wrong). Building a quick console hello world program using that target shows wmake invokes wccaxp as the compiler and wlink including the axp libs. My x86 work PC correctly reports the resulting executable as not being a valid Win32 application so it looks like its all working.

You should be able to download the full build here: http://ftp2.zx.net.nz/pub/misc/watcom/watcom-1.7-dec-alpha-crosscompiler.tar.xz

edit: looks like the source isn't in that archive after all. But it was just the official 1.7.1 source archive from ftp.openwatcom.org - no patches or anything.

[jmalak]

Any platform except Intel x86 was not officially released in any version of OW.
Standard installers doesn't contains anything for Alpha, PPC, etc.
But during OW full build all these parts are created that if you download (ow-snapshot.7z archive) that it should contains all what is build during OW full build (by example symbol files for debugging executables or DLLs, some support tools for Alpa, PPC ... architecture and IDE configuration file for Alpha.
But this part is untested and probably broken in OW 2.0.

[jmalak]

Anyway OW still support Win32s, NT3.x, NT4.0 targets in run-time libraries. We fixed some stuff for these versions related to getting environment.

[jmalak]

I added new Windows NT functions specific for Alpha into Alpha kernel32 import library and added prototypes for all Alpha specific function into winnt.h header file.
I did appropriate changes to use new prototypes in C and C++ run-time libraries.

[galazwoj]

Today I went up to the point where

• pmake os_nt cpu_386 .and target_ppc .not javavm .not
• pmake os_nt cpu_axp .and target_ppc .not javavm .not trap .not

started in bld directory run without errors
Unfortumately PPC target is incomplete, javavm requires some sort of Java SDK and trap on AXP requires some time to understand.
I will incorporate your changes and then perform more testing to make sure all this works and do not breaks other stuff and then can send some diff -u3 patches. I use diff from mingw/msys

[jmalak]

What is interesting that if I build Alpha compiler on 32-bit Windows then it works without problem with 64-bit integers without any correction.
It looks like portability issue for 32/64-bit hosts.

[galazwoj]

When I try to compile the original bld\cc\c\cfold.c using wccaxp built with the same original cfold.c on Windows XP 32 then the compiler crashes. Other people reported the same problem in the past,, for example here are some comments.
https://virtuallyfun.superglobalmegacorp.com/2010/05/27/openwatcom-for-the-dec-alpha/

The directory is bld\cc\axp\nt386.dll
After patching the file the compiler generates no errors.

[jmalak]

I did a little investigation and a problem is deeper then it looks like.
Code generator doesn't support double <-> 64-bit unsigned integer conversion.
Original Watcom code supported only 32-bit integer therefore no problem in the past.
We need some general solution, because Alpha processor hasn't CPU instruction for this conversion.
Your solution fix only C compiler and partialy.
Simple solution could be to use Alpha double <-> 64-bit signed integer conversion and support conversion for positive numbers only.
Next possibility is to use C run-time library support function for this conversion and change code generator to generate appropriate call.

[jmalak]

I did last commit 3063a01 with temporary fix to be able compile Alpha Compiler for Alpha platform.
But it still requires fix code generator for missing unsigned integer <-> float conversions

[galazwoj]

I wanted to check what code was generated by Microsoft C++ for AXP. Unfortunately
it is not yet possible to run Windows AXP in qemu emulator or any other DEC Alpha emulator
so I'm going to run my alpha workstation but not sooner than in July in order to find the results.
Out of curiosity I tried gcc in emulated Debian Alpha but the code is overly complex.

Interestingly Watcom C++ compiler can be compiled and it works without any specific patches.
Both wccaxp and wppaxp generate exactly the same code for small test cases tried.
To convert form long long to double a pair of instructions is used (registers may vary)
ldt $f18,($sp) ;load quadword integer into floating point register
cvtqt $f18,$f18 ;convert quadword to T_floating (that is to IEEE double)

[jmalak]

Only C compiler uses unsigned integer <-> float conversion. After fixing it uses only signed integer <-> float conversion.
C++ compiler can be compiled without problem because it doesn't use any unsigned long long <-> float conversion.

[galazwoj]

You're right, Just a quick test trying to compile a simple case
void print1u(unsigned long long x)
{
double xx = x;
printf("value is %lld, %lf", x, xx);
}
results in Error! E1119: Internal compiler error 92
both for wppaxp and wccaxp
I will dig more into the possible solution.

[galazwoj]

gcc does the conversion in a way than can be recoded in C as follows
double U8FD(unsigned long long i)
{
if (i <= LONG_LONG_MAX) {
return (double)((signed long long)i);
} else {
signed long long ll = (signed long long)(i >> 1);
signed long long r = (signed long long)(i & 1);
double d = ll;
d = d + d + r;
return d;
}
}
Code generated by Watcom seems to be good enough that no assembly coding seems necessary

Example usage
void display(unsigned long long x)
{
double xx = U8FD(x);
printf("value is %llu, %f\n", x, xx);
}

Perhaps the easiest way is to use this as C run-time library support function and change code generator to generate appropriate call to make the conversion..

[jmalak]

Thanks for analysis.
I will look if it is possible to generate this code in-line or if it needs to use C run-time library support function.

[jmalak]

One question.
Do you know how gcc implement double to unsigned long long conversion on Alpha?

[galazwoj]

I can check this and will post the results.

[galazwoj]

gcc implements double to unsigned long long conversion exactly in the same way as conversion from double to signed long long,, the assembly code generated is 100 % the same..
I see no reason why OW could not do this as well.
I did little tests with wccaxp and enclose the results for those who do not have wccaxp working.

all2x.axp.txt
all2x.c.txt

[galazwoj]

There is a subtle bug somewhere in cg which is axp related. It manifests in infinite loop when optimization is tuned on but does not show up when -oaxp is not specified. I am not sure where to ask how to track down the error. So far I managed to create a sample source file that activates the bug.. This bug is related to register allocation,, there seems to be not enough registers and the optimizer creates larger and larger number of temporary variables in each optimization step