19 Feb
2015
19 Feb
'15
6:24 a.m.
On Wed, Feb 18, 2015 at 11:21:10PM -0800, Chuck Guzis wrote:
On 02/18/2015 07:56 PM, William Donzelli wrote:
C will run on all sorts of bizarre machines, but somebody has to bother to
implement it, and if the architecture is weird enough that the language has to
be contorted in unexpected ways, it will break assumptions made in typical C
code. ISTR that current versions of the standard assume a binary machine that
provides particular word width, but earlier versions give much more
flexibility.
That modern compilers don't support obsolete machines isn't a surprise. I
can't
find a decent modern C compiler that targets m68k, for example, even though
that architecture is still just about clinging on to life.
I would not call the CHM 1401 a production
machine. There might be a
System/3 still in real service (at least there was about four or five years
ago).
The point is that COBOL, FORTRAN, Algol, etc. get a bad rap. Look what they
had to run on--you can't do that with C or several other more contemporary
languages. Which brings up the question "Do you design a
machine to run a language or
design a language to run on a machine?" That appears to have changed over the
last 30-40 years. Are we poorer for that?
Modern CPU architectures all appear to have been designed to run C or languages
with much the same memory model. This seems so ingrained that it doesn't appear
to occur to software developers that there are other potential schemes. This is
a great loss on both fronts.
The financial world didn't seem to mind decimal
machines. Are we going to
make a dollar (or Euro) equal to 128 cents to accommodate radix-2 machines?
You can do decimal and fixed-point arithmetic on contemporary binary machines
just fine, but there's just no hardware acceleration[0][1]. Or just go full
gonzo and use floats and hope that the rounding errors don't become
significant, which is sadly all too common.
[0] Although I note that divide-by-constant is most typically implemented by
modern compilers as a fixed-point multiply-by-reciprocal.
[1] x86-64 doesn't support BCD in long mode and repurposes the opcodes. This is
no great loss given how half-arsed x86's BCD support was.