return -1 using size_t???

[Ben Bacarisse]

I wouldn't call it "current" if it's only used by those with a pressing
need to run "old software". One term I've often heard used for such
systems is "legacy".

I own an old program called MaxThink that I'd love to be able to run
that requires (IIRC) MS-DOS 2.2 - it had some features that no more
modern software I've seen matches, and I have a lot of old files stored
in MaxThink format. If I still owned an MS-DOS 2.2 system I could run it
on, I wouldn't call it a "current" system, even if MS choose to still
provide support for such systems.

That's not how I use the word, but I won't claim it the only right way.
But I don't see a problem here because I don't think my meaning could
have been misunderstood. I stated that there were currently supported
releases, gave the date of the document, and added that you'd only use
it because you have old software that needs it. What you or I label
such a C implementation is not very important.

The point it, it's not dead. And, unless the documentation is
pointless, someone is writing (or at least maintaining) C code for it.

<snip>

 

[Ike Naar]

Do you know what happened when exponent bits got set (and indeed
if they could get set) by operations like ~?

Setting exponent bits was not a problem in itself.
The trouble came when the result was to be interpreted as an integer.
The compiler would then insert normalize-to-integer (NTGR) instructions
in strategic places.
This instruction trapped if normalization was not possible.

Of course, in some cases, even after setting exponent bits, the
resulting value could still be normalizable to a valid integer;
e.g. starting with integer value 77 (mantissa=77, exponent=0), setting
exponent bits so that the exponent becomes 3 yields the new value
77*8**3 = 39424, which is normalized to (mantissa=39424, exponent=0).

The system's main programming language was an extended dialect of Algol.
In that language, it was more convenient to use REAL or BOOLEAN
variables (both 48 bits wide) for bit operations, as these types were
not subject to integer normalization.

I'm not sure if there even was a C compiler available at the time.

 

[Ben Bacarisse]

Setting exponent bits was not a problem in itself.
The trouble came when the result was to be interpreted as an integer.

That's what I meant.

The compiler would then insert normalize-to-integer (NTGR) instructions
in strategic places.
This instruction trapped if normalization was not possible.

Of course, in some cases, even after setting exponent bits, the
resulting value could still be normalizable to a valid integer;
e.g. starting with integer value 77 (mantissa=77, exponent=0), setting
exponent bits so that the exponent becomes 3 yields the new value
77*8**3 = 39424, which is normalized to (mantissa=39424, exponent=0).

Ah, thanks. So this architecture does have trap representations. The
way the C standard is written, once you access a trap representation,
all bets are off. So even when there is no hardware trap (like a
signal) any value could result from the access.

 

[Phil Carmody]

For those who wonder about all the oddities in the standard, here is a
system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
not two's complement; (d) has padding bits in all integer types except
the char types; (e) has trap representations in these types; and (f) has
multiple pointer representations (so pointer casts often generate code).
What's more it's *current*: there was recently an MCP 13.0 release with
support into 2013.

Just out of curiosity, is there any change that this system can run
GNU/Linux?

It would surely be hard and it might be impossible, but why would you?
The only reason to use the clunky system is that you have old software
that requires this environment.

I don't need reasons per se. I run Linux on old clunky stuff because I
can.

As someone pointed out, the modern versions of this architecture are
built using Intel Xeon CPUs, so if you had one of these machines and
needed GNU/Linux you'd start by throwing all the MCP emulation away.

That would make it just Linux on Intel. Been there, done that.

Like I said, I was just curious. I've got Linux running on Intel, Sparc
and PowerPC, I'm always looking for a new challenge.

AlphaLinux needs some love and attention currently.

Phil
--

I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)

 

[Phil Carmody]

Thank heavens we sell software to France instead of buying it.

I suspected you'd eventually reach that level - wrong and obnoxious when
corrected. Where you go from there, I care not.

Phil
--

I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)