rdos wrote:
nexos wrote:
rdos wrote:
RISC architectures are too unstable
By whom may I ask
The protected mode interface in x86 processors has existed since the 80s, and still is functional. Give me an example of a RISC processor where the binary code written a decade ago still works on a modern variant. That's what I meant by unstable.
MIPS? 64-bit MIPS goes back at least 30 years, and I dare say user code written in 1992 would run unchanged on any recent 64-bit MIPS implementation (OS permitting, of course, no more Irix or RISC/os and their respective platforms these days.)
SPARC? I'd wager money on binaries I compiled in 1998 (my first job using Solaris) would run unchanged on Solaris 11. Any incompatibilities would be software rather than hardware, and the same would be true for x86 based software as well (outdated libraries no longer being supported, for example.)
But proprietary software aside, both of the above as well as x86 would have common software available in the form of NetBSD, and I suspect the latest NetBSD (9.2) could run NetBSD binaries from nearly 30 years ago on each of these platforms.
Binary compatibility is almost always software limited at user level.
rdos wrote:
nexos wrote:
rdos wrote:
I don't particularly enjoy portable C code scattered with ifdefs that I don't know the values of.
No different than assembly where you have no idea what values are in what registers.
The expected register content should be documented for each procedure. The values of ifdefs are never documented per source file, might not even be found in the projects include files, and sometimes are created by autoconf. Basically no project will document what the ifdefs are supposed to be set to or what their functions are.
Personally, I've adopted ifdef free programming. There are no ifdefs in the code I write, and I typically will remove ifdefs in code I port. Something that increase readability a lot.
Now I won't argue with you there. I think the only ifdefs I use are to turn on extra debug features. Different implementations will go in different files, with common code shared separated completely from non-shared code.