From: dpb on
glen herrmannsfeldt wrote:
> dpb <none(a)non.net> wrote:
>
>> why do the words "tempest" and "teapot" seem to come to my
>> mind I wonder??? ;)
>
> I wonder how different things would be if Intel had the idea
> of a system independent calling convention. ...

AFAIK Intel never wrote an OS and only implemented a few language
compilers on their hardware.

I really was wondering about the insistence on an argument of VAX vis a
vis VMS -- it seems to me moot as one didn't exist w/o the other and VMS
simply came at a time the various languages already existed in a place
where folks recognized there was a need/market/opportunity to support
them all and had a new product to incorporate that support into.

--
From: glen herrmannsfeldt on
nmm1(a)cam.ac.uk wrote:
> In article <hemokm$1a2$1(a)naig.caltech.edu>, I wrote:
(snip)

>>I wonder how different things would be if Intel had the idea
>>of a system independent calling convention. VAX and 8086 came
>>out at about the same time, though presumably they were in
>>development for some years before.

> Have you EVER been in a project to design such a thing? I have.

>>Mabye even no need for C interoperability in Fortran!
>>(Assume other processors also followed along.)

> %deity preserve me :-(

> The thing that kills you is semantic incompatibility, especially
> conceptual incompatibility. E.g. Cobol requires integer overflow
> to the trapped, and Java forbids it. Fortran finalisers are
> called in different places from C++ destructors. And so on.

VAX CALL instructions also push the trap enable bits onto
the stack, and RET restores them. If the COBOL routines
enable overflow at entry, that would fix that problem.

Though since neither C++ nor Java existed in 1978, you
can't blame VAX for that. COBOL did exist, and was considered.

Mixed language programming will always have some problems.

The IA32 stdcall vs. cdecl conventions didn't help at all.

Also, the S/360 BALR saves the mask bits along with the return
address, but BR doesn't restore them.

-- glen

From: robin on
"glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:henuds$7n6$1(a)naig.caltech.edu...

| Also, the S/360 BALR saves the mask bits along with the return
| address, but BR doesn't restore them.

The called program could - if it wanted - change them, and if it did,
it used SPM to restore them.


From: robin on
"Steve Lionel" <steve.lionel(a)intel.invalid> wrote in message news:7n7n1cF3l0qjhU1(a)mid.individual.net...
| Tim E. Sneddon wrote:
|
| > The %VAL, %DESC and %REF keywords were not used for all languages.
| > They are simply Fortran's way of supporting the argument passing
| > mechanisms supported by the OpenVMS Calling Standard.
|
| All VMS languages were pretty much required to have some syntax for
| specifying the passing mechanism. The spellings shown here were used
| for VAX FORTRAN, but as Tim says, other languages had their own syntax,
| which was not always something that looked like a function call
| (ignoring the percent). VAX PASCAL, for example, used attributes in
| square brackets, if I recall correctly.
|
| It was a wonderful thing - an operating system designed from the start
| to have a rich multi-language environment and a single set of calling
| conventions. I've never seen such a thing since.

CDC NOS VE.

Pr1me, etc, Burroughs had it before.

| I'll comment that other Fortran vendors adopted LOC(), without the %,
| and the DEC compilers eventually supported that too. Unlike %LOC, which
| could be used anywhere, %VAL, %REF and %DESC were usable only in actual
| argument lists.



From: robin on
"dpb" <none(a)non.net> wrote in message news:hemslc$hkk$1(a)news.eternal-september.org...

| I really was wondering about the insistence on an argument of VAX vis a
| vis VMS -- it seems to me moot as one didn't exist w/o the other and VMS
| simply came at a time the various languages already existed in a place
| where folks recognized there was a need/market/opportunity to support
| them all and had a new product to incorporate that support into.

"Various languages" existed from the 1950s, and continued
to exist though the 1960s -- including the time when the IBM S/360 was designed
and built.