fortran compiler roadmap?

Anton Shterenlikht

unread,

Apr 17, 2013, 4:52:28 AM4/17/13

to

Does anybody have any information regarding the
future of HP VMS fortran compiler? In particular,
do any HP VMS fortran roadmaps include plans to
support 2003 or 2008 fortran standards?
Or is it staying at 1995 standard for now?

Thanks

Anton

Stephen Hoffman

unread,

Apr 17, 2013, 9:34:19 AM4/17/13

to

On 2013-04-17 08:52:28 +0000, Anton Shterenlikht said:

> Does anybody have any information regarding the future of HP VMS
> fortran compiler?

HP certainly has information regarding their plans for the compiler.
For anything beyond the published stuff, you'll want to ask them.

> In particular, do any HP VMS fortran roadmaps include plans to support
> 2003 or 2008 fortran standards?

Nope. HP versions of Fortran, COBOL, C and C++ all lack support for
current language standards.

> Or is it staying at 1995 standard for now?

Likely, yes. I've encountered no indications of plans for support for
newer standards among any of the classic language compilers.

For the "current" plans, see <http://www.hp.com/go/openvms/roadmap>.
Which hasn't been updated in a while. Or ask HP directly.

Requisite mentions of options and alternatives: you could decide to
port current gcc and gfortran. Alternatively, llvm is more modular,
and might be easier to port to your preferred target platform. Or you
could port the Fortran code to a platform that has the compiler support
you're seeking. None of these options will likely be a small project.

--
Pure Personal Opinion | HoffmanLabs LLC

Anton Shterenlikht

unread,

Apr 17, 2013, 10:23:12 AM4/17/13

to

Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:

>On 2013-04-17 08:52:28 +0000, Anton Shterenlikht said:

>> Does anybody have any information regarding the future of HP VMS
>> fortran compiler?
>

>For the "current" plans, see <http://www.hp.com/go/openvms/roadmap>.
>Which hasn't been updated in a while. Or ask HP directly.

Thank you for the link.

I've been using the VMS educational licence.
I've no support contract, so it's hard to
get any useful information from HP directly.
Who would you suggest I contact and how
(phone, email)?

Thanks

Anton

Stephen Hoffman

unread,

Apr 17, 2013, 11:17:48 AM4/17/13

to

On 2013-04-17 14:23:12 +0000, Anton Shterenlikht said:

> Who would you suggest I contact and how (phone, email)?

Your most available "contact" would be who you received your license PAKs from.

With the OpenVMS hobbyist program, it'd be the folks that mailed you your PAKs.

I'd guess that there won't be any plans available for discussion by HP.

> I've been using the VMS educational licence. I've no support contract,
> so it's hard to get any useful information from HP directly.

You may want to evaluate your plans and strategy for your software with
this platform in your present environment, given you have no support
contract, no commercial licenses with year-to-year renewals as HP
permits, apparently no formal contacts, probably little or no funding
for purchasing same, and some compilers that aren't providing you with
what you want. This situation isn't without some appreciable
operational risks.

Whether this evaluation leads to funding and to commercial licenses and
formal support from HP, or leads to a port, or to some other
resolution, or to a decision to maintain the status quo, is an entirely
local decision of course.

In any case, if there are folks with dependencies here, you'll want to
consider communicating these risks and your plans to your department
chair, and to any supervisors and/or users of your software that might
be involved here, too.

John Wallace

unread,

Apr 17, 2013, 11:43:29 AM4/17/13

to

On Apr 17, 9:52 am, Anton Shterenlikht <me...@mech-

Would it be safe to assume you didn't much like the answers you got
when you asked a very similar question in comp.lang.fortran last
month? Including the answer from Steve Lionel at Intel, who might well
be regarded as definitive even if he's no longer a DEC/CPQ/HP
employee?

e.g. http://coding.derkeiler.com/Archive/Fortran/comp.lang.fortran/2013-03/msg00044.html

Anton Shterenlikht

unread,

Apr 17, 2013, 12:08:19 PM4/17/13

to

John Wallace <johnwa...@gmail.com> writes:

>On Apr 17, 9:52=A0am, Anton Shterenlikht <me...@mech-

>e.g. http://coding.derkeiler.com/Archive/Fortran/comp.lang.fortran/2013-03/=
>msg00044.html

I cannot say I didn't like the answers,
rather I wasn't sure they were definitive.
I didn't know Steve Lionel's opinion
with regards to fortran on VMS is definitive.
Will take this into account from now on.

Also, I wasn't aware there's much crossover
between the two groups.

Thanks

Anton

Keith Parris

unread,

Apr 17, 2013, 12:42:01 PM4/17/13

to

On 4/17/2013 8:23 AM, Anton Shterenlikht wrote:
> I've been using the VMS educational licence.
> I've no support contract, so it's hard to
> get any useful information from HP directly.

Are you obtaining software updates through the Educational License
program, so that you at least have the latest available version of the
compiler?

Are you running on Alpha or on Integrity?

The Software Product Description for HP Fortran is at
http://h71000.www7.hp.com/doc/spdfortran.pdf and describes what
standards the Fortran compiler supports.

> Who would you suggest I contact and how
> (phone, email)?

If all else fails, the Office of OpenVMS Programs could provide an
answer: e-mail OpenVMS.Programs <at> hp.com

Anton Shterenlikht

unread,

Apr 17, 2013, 12:57:20 PM4/17/13

to

Keith Parris <keithparris...@yahoo.com> writes:

>On 4/17/2013 8:23 AM, Anton Shterenlikht wrote:
> > I've been using the VMS educational licence.
> > I've no support contract, so it's hard to
> > get any useful information from HP directly.
>
>Are you obtaining software updates through the Educational License
>program, so that you at least have the latest available version of the
>compiler?

yes

>Are you running on Alpha or on Integrity?

integrity

>The Software Product Description for HP Fortran is at
>http://h71000.www7.hp.com/doc/spdfortran.pdf and describes what
>standards the Fortran compiler supports.

yes, I know. It hasn't been updated since 2006.
At present it supports fortran up to the 1995 standard.
Many useful (to me) features were included in 2003 and 2008 standard.

>> Who would you suggest I contact and how
>> (phone, email)?

>If all else fails, the Office of OpenVMS Programs could provide an
>answer: e-mail OpenVMS.Programs <at> hp.com

Thanks

Anton

Ken Fairfield

unread,

Apr 17, 2013, 1:06:26 PM4/17/13

to

On Wednesday, April 17, 2013 9:08:19 AM UTC-7, Anton Shterenlikht wrote:
> John Wallace <jqqqq...@xxx.yyy> writes:

[...]

> >Would it be safe to assume you didn't much like the answers you got
> >when you asked a very similar question in comp.lang.fortran last
> >month? Including the answer from Steve Lionel at Intel, who might well
> >be regarded as definitive even if he's no longer a DEC/CPQ/HP
> >employee?

[...]

> Also, I wasn't aware there's much crossover
> between the two groups.

There are a handful of us who are in both groups pretty
regularly. Phillip Helbig and Glen Herrmannsfeldt come to
mind. Steve Lionel was a Digital/VMS employee until Digital
(or was it Compaq?) "sold" the Fortran compiler team to
Compaq, and thence Intel (I'm sure I have that wrong, but
it approximates what happened). Meaning he has expertise in
both VMS and Fortran. I'm sure there are a few other lurkers
around. I read both groups daily, but only post occasionally
these days...

-Ken

glen herrmannsfeldt

unread,

Apr 17, 2013, 1:30:43 PM4/17/13

to

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2013-04-17 08:52:28 +0000, Anton Shterenlikht said:

>> Does anybody have any information regarding the future of HP VMS
>> fortran compiler?

> HP certainly has information regarding their plans for the compiler.
> For anything beyond the published stuff, you'll want to ask them.

>> In particular, do any HP VMS fortran roadmaps include plans to support
>> 2003 or 2008 fortran standards?

> Nope. HP versions of Fortran, COBOL, C and C++ all lack support for
> current language standards.

>> Or is it staying at 1995 standard for now?

Rumors are that there is gcc, including gfortran, for VMS.

gcc isn't quite at Fortran 2003, but has many of the features.

-- glen

Stephen Hoffman

unread,

Apr 17, 2013, 2:08:25 PM4/17/13

to

On 2013-04-17 17:30:43 +0000, glen herrmannsfeldt said:

> Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> Rumors are that there is gcc, including gfortran, for VMS.

Please see my first post in this thread.

I've previously ported Fortran code from OpenVMS to gfortran on OS X,
so that's certainly feasible for at least some Fortran code. Whether
the gcc source code port might or would be feasible with the Fortran
code the OP is working with here, I do not know. Whether the existing
gfortran port is sufficient for the OP's particular needs — or if the
OP or somebody else around is in a position to port and test and
package and support the latest gfortran pieces — is also not known.

The last version of gcc I met for VMS was very old. Specifically went
looking for gcc for inclusion on the last Freeware, too.

gnv does not use the gcc tools; it uses wrappers around the HP compilers.

I don't know of an llvm port for OpenVMS.

Haven't seen a gcc or llvm discussion on the GNV lists, either.

I don't expect to see HP provide significant standards-level updates to
the compilers or a project or plans to port open-source compilers on
the OP's likely schedule, as that's the sort of detail that a marketeer
would want to have discussed in the roadmaps and marketing, if the
project is on target for a release in the near future.

OP has the reached the usual questions and discussions and the
uncomfortable and potentially expensive decisions that various
customers I've worked with have also encountered in recent years. This
is usually a porting project, sometimes of newer or different tools to
the target platform, and variously of porting the application code to a
different target platform. Not fun. (Well, not fun if you're in
management and thus paying for all this port-age. Can be fun if you're
working on porting the code.) Not cheap.

Simon Clubley

unread,

Apr 17, 2013, 2:48:42 PM4/17/13

to

On 2013-04-17, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> The last version of gcc I met for VMS was very old. Specifically went
> looking for gcc for inclusion on the last Freeware, too.
>

Ada Core Technologies (ACT) maintains a port of gcc for it's VMS Ada
customers. The source code was not freely available however the last
time I looked (several years ago) because at that time they were
exercising the option in the GPL which allows them to distribute it
to their customers only and none of those customers had redistributed
it when I last checked.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Phillip Helbig---undress to reply

unread,

Apr 17, 2013, 3:53:30 PM4/17/13

to

In article <kklnsc$b2a$1...@speranza.aioe.org>, Anton Shterenlikht

I've asked this in various places at various times over the last few
years. I think the answer is that we will probably never see a Fortran
compiler from the owner of VMS which supports any standard later than
F95. Sic transit gloria mundi. There was a time when VMS Fortran (in
particular VAX Fortran) was the gold standard. (The Alpha compiler is
good as well, it's just that by the time it supported F90, VMS wasn't as
popular as it was back in the VAX days.)

When the alphacide occurred, most of the Fortran folks ended up at
Intel. In some cases working on Fortran compilers which later showed up
on VMS. However, I think the process was rather complicated (I think
John Regan once alluded to this here), there was more distance between
VMS and the compiler and it received a much lower priority.

Phillip Helbig---undress to reply

unread,

Apr 17, 2013, 3:56:24 PM4/17/13

to

> On 2013-04-17 14:23:12 +0000, Anton Shterenlikht said:

Interesting name, probably a transliteration of the Dutch "sterrelicht"
(akin to German "Sternenlicht"), meaning "starlight".

Phillip Helbig---undress to reply

unread,

Apr 17, 2013, 3:58:11 PM4/17/13

to

In article <kkmhdj$ndm$1...@speranza.aioe.org>, Anton Shterenlikht

<me...@mech-cluster241.men.bris.ac.uk> writes:

> I cannot say I didn't like the answers,
> rather I wasn't sure they were definitive.
> I didn't know Steve Lionel's opinion
> with regards to fortran on VMS is definitive.
> Will take this into account from now on.

You might not know that Steve Lionel was once the main VMS Fortran guru.
On the other hand, he doesn't work for HP, so it is hard to say how
definitive his assessment is. I would suspect, though, that he would
know about any plans for support of later versions, but that is perhaps
not something one would expect you to know.

> Also, I wasn't aware there's much crossover
> between the two groups.

It isn't that large.

Phillip Helbig---undress to reply

unread,

Apr 17, 2013, 4:08:51 PM4/17/13

to

In article <8043dfce-3712-4b9c...@googlegroups.com>, Ken

Fairfield <ken.fa...@gmail.com> writes:

> There are a handful of us who are in both groups pretty
> regularly. Phillip Helbig and Glen Herrmannsfeldt come to
> mind. Steve Lionel was a Digital/VMS employee until Digital
> (or was it Compaq?) "sold" the Fortran compiler team to
> Compaq, and thence Intel (I'm sure I have that wrong, but
> it approximates what happened).

In 1999, I was in Boston for a conference. Since it wasn't far away, I
made a pilgrimage to Nashua. Steve was kind enough to show me around.
I brought back a Compaq mug as one of my souvenirs (admittedly the least
prized one), so it was definitely Compaq then. (I also got to meet Hoff
and Andy Goldstein. Fred Kleinsorge wasn't in that day.) It was
towards the end of 2000 that HP bought Compaq, and the alphacide was
shortly before that (honi soit qui mal y pense).

By a bizarre coincidence, the woman who organized the conference in
Boston was involved with a charity for whom Steve was the webmaster.
Also, there happened to be a store nearby---they seemed to deal mostly
in video games and probably didn't even know what VMS is---which was one
of the few places in the world which had |d|i|g|i|t|a|l| InfoServers in
stock. A fellow VMS enthusiast had asked me to bring him back a couple.
I agreed, not realizing how huge the boxes were (InfoServer, pedestal,
packaging etc). Somehow, I managed to bring them back to England, which
is one of the places I was working at the time, on the plane without
having to pay for extra baggage. People who thought I was strange had
their impression confirmed when, at the conference, I carried them up to
my hotel room one by one.

Steve was always a big help with regard to VMS Fortran and an all-around
nice guy.

Jan-Erik Soderholm

unread,

Apr 17, 2013, 4:50:33 PM4/17/13

to

I had some personal contact with Lionel in a prorting project where
I ported an application in Fortran (wrapped in some DCL as user
interface) to a PC environment using a Visual Basic screen as
user interface and the Fortran code built as an DLL (called from
VB) using Visual Fortran. VF come quite close after Intel bought
the Fortran group.

The port was easy since Visual Fortran had very good compatibilty
with DEC/CPQ Fortran. If I'm not wrong, Lionel was the manager
for the Visual Fortran product (?).

Jan-Erik.

Bill Gunshannon

unread,

Apr 17, 2013, 4:53:44 PM4/17/13

to

In article <kkmqqa$rr3$1...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> On 2013-04-17, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>>
>> The last version of gcc I met for VMS was very old. Specifically went
>> looking for gcc for inclusion on the last Freeware, too.
>>
>
> Ada Core Technologies (ACT) maintains a port of gcc for it's VMS Ada
> customers. The source code was not freely available however the last
> time I looked (several years ago) because at that time they were
> exercising the option in the GPL which allows them to distribute it
> to their customers only

And wasn't that specifically what the Gnu Public Virus was supposed to
prevent?

> and none of those customers had redistributed
> it when I last checked.
>

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

Howard S Shubs

unread,

Apr 17, 2013, 6:38:52 PM4/17/13

to

In article <kkm87e$cbn$1...@dont-email.me>,

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:

> Requisite mentions of options and alternatives: you could decide to
> port current gcc and gfortran. Alternatively, llvm is more modular,
> and might be easier to port to your preferred target platform. Or you
> could port the Fortran code to a platform that has the compiler support
> you're seeking. None of these options will likely be a small project.

I'd be open to working on such a project, and I'm available.

Arne Vajhøj

unread,

Apr 17, 2013, 9:18:08 PM4/17/13

to

On 4/17/2013 4:53 PM, Bill Gunshannon wrote:
> In article <kkmqqa$rr3$1...@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2013-04-17, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>>>
>>> The last version of gcc I met for VMS was very old. Specifically went
>>> looking for gcc for inclusion on the last Freeware, too.
>>>
>>
>> Ada Core Technologies (ACT) maintains a port of gcc for it's VMS Ada
>> customers. The source code was not freely available however the last
>> time I looked (several years ago) because at that time they were
>> exercising the option in the GPL which allows them to distribute it
>> to their customers only
>
> And wasn't that specifically what the Gnu Public Virus was supposed to
> prevent?

No.

GPL is supposed to prevent anyone having a binary of the code (general
open source) or something "linked" with it (GPL specific) without being
able to get the source and modify it or redistribute it.

But nothing in OSI definition or GPL force them to distribute
binaries to anyone besides those they want to.

It is generally not a big problem as OSI definition/GPL allows
those that receive the binary to redistribute binary and source
if they want to.

Typical there will always be someone that want to redistribute.

But Ada on OpenVMS may be a relative small club with limited
interest in open source principles.

Arne

Arne Vajhøj

unread,

Apr 17, 2013, 9:20:56 PM4/17/13

to

But if someone was really interested, then they could try getting
the binary for another platform and then request the source.

I doubt that they maintain a separate source tree for OpenVMS,
so one may get the OpenVMS source together with the rest.

Arne

Craig A. Berry

unread,

Apr 17, 2013, 11:03:09 PM4/17/13

to

In article <kkmqqa$rr3$1...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> On 2013-04-17, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> >
> > The last version of gcc I met for VMS was very old. Specifically went
> > looking for gcc for inclusion on the last Freeware, too.
> >
>
> Ada Core Technologies (ACT) maintains a port of gcc for it's VMS Ada
> customers. The source code was not freely available however the last
> time I looked (several years ago) because at that time they were
> exercising the option in the GPL which allows them to distribute it
> to their customers only and none of those customers had redistributed
> it when I last checked.

I was recently told by someone from Ada Core that GCC for VMS can be
built more or less straightforwardly by doing something called a
"Canadian cross compile." This is how they build their Ada compiler,
and he was pretty sure they'd contributed back upstream anything needed
to build GCC targeting VMS.

I asked specifically whether the code generators in GCC were up to
snuff for Alpha and Itanium, and he said yes; their Ada compiler
depends on this. (The last version of gcc for VMS I'd heard of
existing in the wild [2.9 or so] purportedly never had an Alpha code
generator that actually worked.)

I also asked specifically whether the resulting C compiler could be
used with the CRTL and he said yes, but you'd have to point the
compiler build at the headers you already have, which means you'd have
to already have rights to use the HP C compiler. I remain skeptical
whether GNU C could even compile those headers given all of the
pragmas, specific alignment requirements, etc., but I suppose it's
possible.

While VAX Fortran was my first computer language, I haven't done any
Fortran in twenty years and I don't have a very good sense of what role
the library plays in the language. Given that SYS$SHARE:DEC$FORRTL.EXE
is about one tenth the size of SYS$SHARE:DECC$SHR.EXE, I'm guessing
it's not quite as big a deal as the C run-time. But still, getting a
"foreign" Fortran compiler fully functional on VMS would likely require
various kinds of glue for exit handlers, threads, and such, and, if you
want to use native libraries, rights to use SYS$LIBRARY:FORSYSDEF.TLB
or an independently-developed equivalent.

And then you have a compiler with no debugger, so you either spend lots
of time in the entrails of the compiler making it produce what the
OpenVMS debugger expects, or you port gdb, or write you're own
debugger.

John E. Malmberg

unread,

Apr 18, 2013, 12:35:43 AM4/18/13

to

On 4/17/2013 10:03 PM, Craig A. Berry wrote:
>
> I also asked specifically whether the resulting C compiler could be
> used with the CRTL and he said yes, but you'd have to point the
> compiler build at the headers you already have, which means you'd have
> to already have rights to use the HP C compiler. I remain skeptical
> whether GNU C could even compile those headers given all of the
> pragmas, specific alignment requirements, etc., but I suppose it's
> possible.

OpenVMS 8.x and probably earlier versions contain the CRTL header file
text libraries. The ones supplied by the compiler are updates that are
only supplied if needed.

And as far as I know, a compiler license is not needed to read or use
the definitions in the text libraries supplied by the operating system.

If GNU C can use those headers as-is is a totally different question. I
do not know.

Regards,
-John
wb8...@qsl.network
Personal Opinion Only

Phillip Helbig---undress to reply

unread,

Apr 18, 2013, 2:29:54 AM4/18/13

to

In article
<craigberry-0E8D5...@news.eternal-september.org>, "Craig A.

Berry" <craig...@mac.com.invalid> writes:

> While VAX Fortran was my first computer language, I haven't done any
> Fortran in twenty years and I don't have a very good sense of what role
> the library plays in the language. Given that SYS$SHARE:DEC$FORRTL.EXE
> is about one tenth the size of SYS$SHARE:DECC$SHR.EXE, I'm guessing
> it's not quite as big a deal as the C run-time. But still, getting a
> "foreign" Fortran compiler fully functional on VMS would likely require
> various kinds of glue for exit handlers, threads, and such, and, if you
> want to use native libraries, rights to use SYS$LIBRARY:FORSYSDEF.TLB
> or an independently-developed equivalent.
>
> And then you have a compiler with no debugger, so you either spend lots
> of time in the entrails of the compiler making it produce what the
> OpenVMS debugger expects, or you port gdb, or write you're own
> debugger.

Right. Due to a similar question, someone suggested to me to get gcc,
gnufortran or whatever (not sure of the differences; there was a fork
somewhere) running on VMS. While a compiler is surely possible, i.e.
something which will turn source code into an executable which will work
as intended, one really wants it integrated into VMS with the debugger,
exit handling etc.

$ WRITE SYS$OUTPUT "Program too complex for processor"
$ EXIT

The above is a standard-conforming Fortran compiler, but the quality of
implementation is low.

Anton Shterenlikht

unread,

Apr 18, 2013, 4:11:36 AM4/18/13

to

I belive it's Yiddish. It's been translated a few times,
and some random letters crept in.
The current spelling originates from my russian passport.
I've heard that my granddad had Sternlicht
in his birth certificate.

Thanks

Anton

Phillip Helbig---undress to reply

unread,

Apr 18, 2013, 4:19:58 AM4/18/13

to

In article <kko9ro$amm$1...@speranza.aioe.org>, Anton Shterenlikht

<me...@mech-cluster241.men.bris.ac.uk> writes:

> >Interesting name, probably a transliteration of the Dutch "sterrelicht"
> >(akin to German "Sternenlicht"), meaning "starlight".
>
> I belive it's Yiddish. It's been translated a few times,
> and some random letters crept in.

Right. Come to think of it, the "sh" gives it away as coming from
German or Yiddish, rather than Dutch. So probably Yiddish (in which
case this word is essentially German) then some letters got dropped.

In most dialects of German, and in "standard German", s before p or t at
the beginning of a syllable is pronounced sh. Thus, names like
Sternberg get translated into Russian with the Cyrillic letter with the
sh sound, then this gets transliterated into English as sh.

(In much of northern Germany, s is never pronounced sh; in parts of
southern Germany, it always is before p or t, even when not at the
beginning of a syllable.)

John Wallace

unread,

Apr 18, 2013, 5:53:01 AM4/18/13

to

On Apr 18, 4:03 am, "Craig A. Berry" <craigbe...@mac.com.invalid>
wrote:
> In article <kkmqqa$rr...@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

I'm not sure a Canadian cross would be considered "straightforward" by
most folk.

An 'ordinary' cross compiler will be familiar to many round here. E.g.
XD Ada, you run the compiler on a VMS host but it generates code to
run on a 68K target with a particular set of runtime libraries. Note
the use of host and target.

A 'Canadian cross' compiler isn't a commonly used concept, but
basically you have a 'build the compiler' environment, and a host
environment, and a target environment. All are different. E.g. you
build the compiler on Linux (eg x86 Linux), so that it can be used to
compile (link, etc) on a VMS host, and the generated code can run on
68k.

There's more to this than may at first be obvious; I knew someone
whose job it was to do this, though not with the particular examples
mentioned above.

And then, as noted by Craig, there are the other parts of the
toolchain besides the compiler. Some of the simple ones are part of
the compiler build (binutils?). The gdb debugger isn't part of that
package (or at least wasn't, when I checked a year or two ago, gcc
4.something/gdb 7.something). In principle OpenVMS on IA64 has been a
supported gdb target since August 2012 (gdb 7.5) but I don't know how
well that fits in this picture.

IA64 is not a widely used target. Compiler optimisations for IA64 with
lots of registers and little support for parallelisation at runtime
may be counter-intuitive to compiler code which often expects
relatively few registers and decent support for parallelism in the
hardware, such as x86. Ideally this kind of stuff would be layered and
modularised and configurable in target-specific ways. But is it, in
reality?

If Anton's interest is existing Fortran applications for HPC, I'd
suggest he might want to be looking to see if any other departments in
the University might be able to make a contribution to getting the
applications updated to more applicable language standards, which may
imply more widely supported hardware. And the simplest end point
probably wouldn't be Fortran on VMS on IA64, unless the existing code
has lots of VMS-specific dependencies.

My 2p.

Simon Clubley

unread,

Apr 18, 2013, 8:04:16 AM4/18/13

to

On 2013-04-18, John Wallace <johnwa...@gmail.com> wrote:
> On Apr 18, 4:03�am, "Craig A. Berry" <craigbe...@mac.com.invalid>
> wrote:
>>
>> I was recently told by someone from Ada Core that GCC for VMS can be
>> built more or less straightforwardly by doing something called a
>> "Canadian cross compile." �This is how they build their Ada compiler,
>> and he was pretty sure they'd contributed back upstream anything needed
>> to build GCC targeting VMS.
>>

Typical. :-)

A compiler for VMS which cannot actually be built on VMS. :-)

[snip]

>
> I'm not sure a Canadian cross would be considered "straightforward" by
> most folk.
>

I'm wondering if it's a full blown Canadian cross (which does not make
much sense in this context), or if it's more that --build= is, say, Linux
and --host= and --target= are both VMS.

>
> A 'Canadian cross' compiler isn't a commonly used concept, but
> basically you have a 'build the compiler' environment, and a host
> environment, and a target environment. All are different. E.g. you
> build the compiler on Linux (eg x86 Linux), so that it can be used to
> compile (link, etc) on a VMS host, and the generated code can run on
> 68k.
>
> There's more to this than may at first be obvious; I knew someone
> whose job it was to do this, though not with the particular examples
> mentioned above.
>

I've never done a Canadian before so I don't know for sure what bits,
apart from the obvious ones, are different.

However, I've done plenty of normal cross compiler builds over the years
so I do have a initial feeling of what they _might_ be, but as always
with these things, it's not until you try the actual build do you come
across the issues you never even thought about. :-)

> And then, as noted by Craig, there are the other parts of the
> toolchain besides the compiler. Some of the simple ones are part of
> the compiler build (binutils?). The gdb debugger isn't part of that
> package (or at least wasn't, when I checked a year or two ago, gcc
> 4.something/gdb 7.something). In principle OpenVMS on IA64 has been a
> supported gdb target since August 2012 (gdb 7.5) but I don't know how
> well that fits in this picture.
>

binutils is the correct name and it is indeed a seperate package; binutils
can be used seperately from gcc for other projects.

Craig A. Berry

unread,

Apr 18, 2013, 8:49:00 AM4/18/13

to

In article <kkong0$4qa$1...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> On 2013-04-18, John Wallace <johnwa...@gmail.com> wrote:
> > On Apr 18, 4:03�am, "Craig A. Berry" <craigbe...@mac.com.invalid>
> > wrote:
> >>
> >> I was recently told by someone from Ada Core that GCC for VMS can be
> >> built more or less straightforwardly by doing something called a
> >> "Canadian cross compile." �This is how they build their Ada compiler,
> >> and he was pretty sure they'd contributed back upstream anything needed
> >> to build GCC targeting VMS.
> >>
>
> Typical. :-)
>
> A compiler for VMS which cannot actually be built on VMS. :-)

He said they used to build it on VMS but it was so slow they stopped
doing that and now build on Linux because it's many times faster.

Stephen Hoffman

unread,

Apr 18, 2013, 9:45:27 AM4/18/13

to

On 2013-04-18 03:03:09 +0000, Craig A. Berry said:

> I asked specifically whether the code generators in GCC were up to
> snuff for Alpha and Itanium, and he said yes; their Ada compiler

> depends on this. ...

There were some few updates to the standard ELF and DWARF structures
specifically for OpenVMS; the whole stack (debugger, analysis tools,
linker, compiler back-ends) is different between Alpha and Itanium.
The porting work involved a detailed engineering spec for just the ELF
and DWARF changes, and the Linker was a large project in its own right,
not to mention the other changes to all the other tools that touched
the object code and executable code. Can a compiler get away without
these updates? Probably. Depending on what other parts of VMS you're
using, sure.

Start with the calling standard here
<http://h71000.www7.hp.com/openvms/whitepapers/index.html>, and
probably also read the floating point information.

> And then you have a compiler with no debugger, so you either spend lots
> of time in the entrails of the compiler making it produce what the
> OpenVMS debugger expects, or you port gdb, or write you're own
> debugger.

lldb is also doing pretty well, if you head down the llvm path and not
the gcc path. But with either compiler tool chain, you're not going to
play well in the mixed-language environment unless the compiler
generates the appropriate debugger symbol table records, etc.

Stephen Hoffman

unread,

Apr 18, 2013, 10:09:32 AM4/18/13

to

On 2013-04-18 09:53:01 +0000, John Wallace said:

> A 'Canadian cross' compiler isn't a commonly used concept, but
> basically you have a 'build the compiler' environment, and a host
> environment, and a target environment. All are different. E.g. you
> build the compiler on Linux (eg x86 Linux), so that it can be used to
> compile (link, etc) on a VMS host, and the generated code can run on
> 68k.

That's not far off what was done during the earliest stages of the
port. The compilers were invoked on Alpha and generated Itanium code
that was then processed through a cross-linker. What a pain in the
rump that was. The builds became very complex, both for the DCL as
well as for references to the architectures within the source code —
the usual sorts of conditional code architectural references made for
gnarly code when you were cross-compiling. Yes this compile is
occuring on Alpha, but this source code has to build with the Itanium
code-path, etc.

> IA64 is not a widely used target. Compiler optimisations for IA64 with
> lots of registers and little support for parallelisation at runtime
> may be counter-intuitive to compiler code which often expects
> relatively few registers and decent support for parallelism in the
> hardware, such as x86. Ideally this kind of stuff would be layered and
> modularised and configurable in target-specific ways. But is it, in
> reality?

Many of the optimizations used on and useful on the non-VLIW
instruction sets are different from those for Itanium. That's been a
long-standing problem for Itanium, (There's a posting around with
somewhere with a discussion of the differences in optimization
algorithms and strategies between VLIW and "everybody else", written by
Chris Lattner, IIRC.)

> If Anton's interest is existing Fortran applications for HPC, I'd
> suggest he might want to be looking to see if any other departments in
> the University might be able to make a contribution to getting the
> applications updated to more applicable language standards, which may
> imply more widely supported hardware. And the simplest end point
> probably wouldn't be Fortran on VMS on IA64, unless the existing code
> has lots of VMS-specific dependencies.

Yep. The usual path is to port the easier code, to incrementally
migrate some stuff, and to incrementally "sunset" the rest of the
harder-to-port code.

Paul Sture

unread,

Apr 18, 2013, 10:18:22 AM4/18/13

to

In article <kkoabe$9og$3...@online.de>,

hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply)

wrote:

Interesting thanks. I wasn't aware of the rule. If I wasn't taught it,
I must have picked it up subconsciously, probably during my school
exchange with a Bavarian family (close to Kaufbeuren, which at one time
had a DEC factory).

Since my school German teacher was Austrian, which flavour was he likely
to have taught us?

Anton, how many mis-spellings of your name do you get in the UK?

My father used to have a collection of miss-spellings of "Sture". :-)

The French have a rather good system when taking your name; they always
ask how it is written and this saves a lot of confusion.

--
Paul Sture

Paul Sture

unread,

Apr 18, 2013, 10:31:58 AM4/18/13

to

In article
<craigberry-0E8D5...@news.eternal-september.org>,

"Craig A. Berry" <craig...@mac.com.invalid> wrote:

> While VAX Fortran was my first computer language, I haven't done any
> Fortran in twenty years and I don't have a very good sense of what role
> the library plays in the language. Given that SYS$SHARE:DEC$FORRTL.EXE
> is about one tenth the size of SYS$SHARE:DECC$SHR.EXE, I'm guessing
> it's not quite as big a deal as the C run-time. But still, getting a
> "foreign" Fortran compiler fully functional on VMS would likely require
> various kinds of glue for exit handlers, threads, and such, and, if you
> want to use native libraries, rights to use SYS$LIBRARY:FORSYSDEF.TLB
> or an independently-developed equivalent.

Going back to the last time I used VAX Fortran we made extensive use of
third party libraries and runtime processes. I believe those did make
it to Alpha, but don't know whether they made it to Itanium. Without
those a complete rewrite of the applications would be the only way
forwards.

--
Paul Sture

Paul Sture

unread,

Apr 18, 2013, 10:48:16 AM4/18/13

to

In article <8043dfce-3712-4b9c...@googlegroups.com>,

Ken Fairfield <ken.fa...@gmail.com> wrote:

> There are a handful of us who are in both groups pretty
> regularly. Phillip Helbig and Glen Herrmannsfeldt come to
> mind. Steve Lionel was a Digital/VMS employee until Digital
> (or was it Compaq?) "sold" the Fortran compiler team to
> Compaq, and thence Intel (I'm sure I have that wrong, but
> it approximates what happened). Meaning he has expertise in
> both VMS and Fortran. I'm sure there are a few other lurkers
> around. I read both groups daily, but only post occasionally
> these days...

I managed to dig up this post by Steve Lionel in 2006:

http://lists.apple.com/archives/fortran-dev/2006/Apr/msg00026.html

"Yes, the Intel Fortran compiler as of version 8.0 is a blend of the
DEC/Compaq Fortran 90/95 "front end" (language semantics) and the Intel
"back end" (optimizer/code generator). All of the Compaq Fortran
front-end team moved to Intel in 2001, along with a number of the Compaq
code generator/optimizer people, though the "GEM" back end we used at
DEC/Compaq is not being used at Intel. ("Moved" in a virtual sense - we
didn't change physical location. Intel leased our office space in what
is now HP's Nashua, NH facility. I like to joke that I've been in the
same office for 18 years working for three different companies.)"

To sum up, they moved in 2001 but stayed in the same offices.

--
Paul Sture

Bill Gunshannon

unread,

Apr 18, 2013, 11:41:44 AM4/18/13

to

In article <nospam-051FFB....@news.chingola.ch>,

Austrian!! :-)

>
> Anton, how many mis-spellings of your name do you get in the UK?
>
> My father used to have a collection of miss-spellings of "Sture". :-)
>
> The French have a rather good system when taking your name; they always
> ask how it is written and this saves a lot of confusion.
>

Names are always fun. Especially whne you try to do an anglo/european
(or howevert hey class them) name in languages thatuse different
alphabets. I used to have my name on my office door at the University
in Arabic, Chinese, Korean and Amharic. Was good for a few raised
eyebrows.

On a side note, when I was in Qatar I was always amazed at the store
names at the mall. Some were actual translations of the name (like
Footlocker) but others were just transliterations of the letters which
meant that in Arabic they were just nonsense sounds with no relation
to the products being sold.

Bill Gunshannon

unread,

Apr 18, 2013, 11:44:17 AM4/18/13

to

In article <nospam-AC92AF....@news.chingola.ch>,

Paul Sture <nos...@sture.ch> writes:
> In article
> <craigberry-0E8D5...@news.eternal-september.org>,
> "Craig A. Berry" <craig...@mac.com.invalid> wrote:
>
>> While VAX Fortran was my first computer language, I haven't done any
>> Fortran in twenty years and I don't have a very good sense of what role
>> the library plays in the language. Given that SYS$SHARE:DEC$FORRTL.EXE
>> is about one tenth the size of SYS$SHARE:DECC$SHR.EXE, I'm guessing
>> it's not quite as big a deal as the C run-time. But still, getting a
>> "foreign" Fortran compiler fully functional on VMS would likely require
>> various kinds of glue for exit handlers, threads, and such, and, if you
>> want to use native libraries, rights to use SYS$LIBRARY:FORSYSDEF.TLB
>> or an independently-developed equivalent.
>
> Going back to the last time I used VAX Fortran we made extensive use of
> third party libraries and runtime processes.

NAGLIB, by any chance?

> I believe those did make
> it to Alpha, but don't know whether they made it to Itanium. Without
> those a complete rewrite of the applications would be the only way
> forwards.

Is NAGLIB still around? We always got it in source (Fortran) so I
guess it could be used on any system with a functional Fortran Compiler.

Paul Sture

unread,

Apr 18, 2013, 11:49:06 AM4/18/13

to

In article <kkmujq$eqi$3...@online.de>,

hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply)
wrote:

> In article <kklnsc$b2a$1...@speranza.aioe.org>, Anton Shterenlikht
> <me...@mech-cluster241.men.bris.ac.uk> writes:
>
> > Does anybody have any information regarding the
> > future of HP VMS fortran compiler? In particular,
> > do any HP VMS fortran roadmaps include plans to
> > support 2003 or 2008 fortran standards?
> > Or is it staying at 1995 standard for now?
>
> I've asked this in various places at various times over the last few
> years. I think the answer is that we will probably never see a Fortran
> compiler from the owner of VMS which supports any standard later than
> F95. Sic transit gloria mundi. There was a time when VMS Fortran (in
> particular VAX Fortran) was the gold standard. (The Alpha compiler is
> good as well, it's just that by the time it supported F90, VMS wasn't as
> popular as it was back in the VAX days.)

I came across a comment some time ago to the effect that when discussing
details of Fortran compiler implementations for other platforms, it was
common to say "Let's see what DEC Fortran does here".

IIRC that was Richard Maine, but Google Groups is so incredibly slow at
the moment that I gave up my quest to find it :-(

--
Paul Sture

Howard S Shubs

unread,

Apr 18, 2013, 2:34:40 PM4/18/13

to

In article <nospam-F3F39B....@news.chingola.ch>,

Paul Sture <nos...@sture.ch> wrote:

> To sum up, they moved in 2001 but stayed in the same offices.

So ZKO is still there?

John Wallace

unread,

Apr 18, 2013, 2:52:59 PM4/18/13

to

On Apr 18, 4:49 pm, Paul Sture <nos...@sture.ch> wrote:
> In article <kkmujq$eq...@online.de>,

> hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply)
>
>
>
>
>
>
>
>
>
> wrote:

> > In article <kklnsc$b2...@speranza.aioe.org>, Anton Shterenlikht

> > <me...@mech-cluster241.men.bris.ac.uk> writes:
>
> > > Does anybody have any information regarding the
> > > future of HP VMS fortran compiler? In particular,
> > > do any HP VMS fortran roadmaps include plans to
> > > support 2003 or 2008 fortran standards?
> > > Or is it staying at 1995 standard for now?
>
> > I've asked this in various places at various times over the last few
> > years. I think the answer is that we will probably never see a Fortran
> > compiler from the owner of VMS which supports any standard later than
> > F95. Sic transit gloria mundi. There was a time when VMS Fortran (in
> > particular VAX Fortran) was the gold standard. (The Alpha compiler is
> > good as well, it's just that by the time it supported F90, VMS wasn't as
> > popular as it was back in the VAX days.)
>
> I came across a comment some time ago to the effect that when discussing
> details of Fortran compiler implementations for other platforms, it was
> common to say "Let's see what DEC Fortran does here".
>
> IIRC that was Richard Maine, but Google Groups is so incredibly slow at
> the moment that I gave up my quest to find it :-(
>
> --
> Paul Sture

Wrt Google Groups being slow: the behaviour I'm seeing, still using
the old Google Groups not the new unimproved one, is that if I don't
get a response quickly, there probably won't be a response in a
sensible timeframe, but if I repeat the same request (having waited a
second or two) it'll usually respond within a sensible timeframe. I
wasn't sure whether this was possibly packet loss at my ISP (but I
don't see any similar problem anywhere else) or bad load balancing at
Google Groups. I now vote for bad load balancing.

Stephen Hoffman

unread,

Apr 18, 2013, 3:05:33 PM4/18/13

to

The buildings are, yes. HP closed the site
<http://www.decconnection.org/HPclosesNashuaSite-12-12-07.pdf>. The
site is now a tech (office) park, called the Nashua Technology Park at
Gateway Hills or some such.
<http://nashuatechnologypark.com/index.htm> Some of the folks that
once worked at DEC ZKO are still working at the NTP site, too; Dell
Equalogic has various ex-Digits on staff, for instance, and Dell is
hiring <http://jobs.dell.com/nashua>.

The Maynard Mill is still around, too, and it too is a tech (office)
park. <http://www.clocktowerplace.com> Yes, the Mill was office space
when DEC got going back in '57, and it's office space again.

Howard S Shubs

unread,

Apr 18, 2013, 3:09:04 PM4/18/13

to

In article <kkpg0e$13u$1...@dont-email.me>,

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:

> The Maynard Mill is still around, too, and it too is a tech (office)
> park. <http://www.clocktowerplace.com> Yes, the Mill was office space
> when DEC got going back in '57, and it's office space again.

Well, you know how it is with startups. Here one day, gone the next.

glen herrmannsfeldt

unread,

Apr 18, 2013, 3:41:37 PM4/18/13

to

Paul Sture <nos...@sture.ch> wrote:

(snip)

> I came across a comment some time ago to the effect that when discussing
> details of Fortran compiler implementations for other platforms, it was
> common to say "Let's see what DEC Fortran does here".

For some years, IBM and DEC were the big players in the game.

DEC Fortran had, relative to IBM, many more extensions to the standard.

By the time of VAX and VMS, DEC wanted people to be able to easily
switch from IBM, and so would have had to support all the extensions
that IBM had. They also tended to keep any extensions that previous
DEC compilers had added.

> IIRC that was Richard Maine, but Google Groups is so incredibly slow at
> the moment that I gave up my quest to find it :-(

-- glen

Paul Sture

unread,

Apr 18, 2013, 4:16:23 PM4/18/13

to

In article
<be093b2a-366b-4706...@cd3g2000vbb.googlegroups.com>,

John Wallace <johnwa...@gmail.com> wrote:

> Wrt Google Groups being slow: the behaviour I'm seeing, still using
> the old Google Groups not the new unimproved one, is that if I don't
> get a response quickly, there probably won't be a response in a
> sensible timeframe, but if I repeat the same request (having waited a
> second or two) it'll usually respond within a sensible timeframe. I
> wasn't sure whether this was possibly packet loss at my ISP (but I
> don't see any similar problem anywhere else) or bad load balancing at
> Google Groups. I now vote for bad load balancing.

Yes, I was using the old Google Groups. I did get a response by trying
again a minute or so later but it was still very tardy.

There was a pile of messages saying "loading" or similar (Google insists
on giving me the German equivalent unless I leave cookies switched on).

It was also coming up with disturbing number of "post was deleted" (my
translation) items.

--
Paul Sture

Paul Sture

unread,

Apr 18, 2013, 4:21:58 PM4/18/13

to

In article <ataimh...@mid.individual.net>,

bi...@server1.cs.uofs.edu (Bill Gunshannon) wrote:

> In article <nospam-AC92AF....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> writes:
> > In article
> > <craigberry-0E8D5...@news.eternal-september.org>,
> > "Craig A. Berry" <craig...@mac.com.invalid> wrote:
> >
> >> While VAX Fortran was my first computer language, I haven't done any
> >> Fortran in twenty years and I don't have a very good sense of what role
> >> the library plays in the language. Given that SYS$SHARE:DEC$FORRTL.EXE
> >> is about one tenth the size of SYS$SHARE:DECC$SHR.EXE, I'm guessing
> >> it's not quite as big a deal as the C run-time. But still, getting a
> >> "foreign" Fortran compiler fully functional on VMS would likely require
> >> various kinds of glue for exit handlers, threads, and such, and, if you
> >> want to use native libraries, rights to use SYS$LIBRARY:FORSYSDEF.TLB
> >> or an independently-developed equivalent.
> >
> > Going back to the last time I used VAX Fortran we made extensive use of
> > third party libraries and runtime processes.
>
> NAGLIB, by any chance?

No. This stuff came from the heritage of the first compiler available
for the VAX 11/780 being Fortran IV. Among a heap of other stuff there
was a bunch of string handling routines which weren't necessary once
Fortran 77 arrived (and for new programs I used that).

> > I believe those did make
> > it to Alpha, but don't know whether they made it to Itanium. Without
> > those a complete rewrite of the applications would be the only way
> > forwards.
>
> Is NAGLIB still around? We always got it in source (Fortran) so I
> guess it could be used on any system with a functional Fortran Compiler.

Is this it?

http://www.nag.com/intro/mkt77.asp

--
Paul Sture

Phillip Helbig---undress to reply

unread,

Apr 18, 2013, 7:27:52 PM4/18/13

to

In article <nospam-051FFB....@news.chingola.ch>, Paul Sture

<nos...@sture.ch> writes:

> > In most dialects of German, and in "standard German", s before p or t at
> > the beginning of a syllable is pronounced sh. Thus, names like
> > Sternberg get translated into Russian with the Cyrillic letter with the
> > sh sound, then this gets transliterated into English as sh.
> >
> > (In much of northern Germany, s is never pronounced sh; in parts of
> > southern Germany, it always is before p or t, even when not at the
> > beginning of a syllable.)
>
> Interesting thanks. I wasn't aware of the rule. If I wasn't taught it,
> I must have picked it up subconsciously, probably during my school
> exchange with a Bavarian family (close to Kaufbeuren, which at one time
> had a DEC factory).
>
> Since my school German teacher was Austrian, which flavour was he likely
> to have taught us?

In this respect, standard German, i.e. sh before p and t at the
beginning of a syllable. Many Austrians pronounce s as s at the
beginning of a syllable when followed by a vowel, but in "standard
German" it is pronounced as z. Also, ei, ai, ey, ay are more like a
long English a whereas in standard German more like a long English i.

Anton Shterenlikht

unread,

Apr 19, 2013, 3:49:55 AM4/19/13

to

Paul Sture <nos...@sture.ch> writes:

>Anton, how many mis-spellings of your name do you get in the UK?

too many to keep track of.
But it wasn't better back in russia.
And anyway, no matter how you spell it,
living with such surname in ussr/russia is
not recommended...

Anton

Anton Shterenlikht

unread,

Apr 19, 2013, 3:52:44 AM4/19/13

to

Paul Sture <nos...@sture.ch> writes:

>In article
><be093b2a-366b-4706...@cd3g2000vbb.googlegroups.com>,
> John Wallace <johnwa...@gmail.com> wrote:

>> Wrt Google Groups being slow: the behaviour I'm seeing, still using
>> the old Google Groups not the new unimproved one, is that if I don't
>> get a response quickly, there probably won't be a response in a
>> sensible timeframe, but if I repeat the same request (having waited a
>> second or two) it'll usually respond within a sensible timeframe. I
>> wasn't sure whether this was possibly packet loss at my ISP (but I
>> don't see any similar problem anywhere else) or bad load balancing at
>> Google Groups. I now vote for bad load balancing.

>Yes, I was using the old Google Groups. I did get a response by trying

I'm happy with http://aioe.org/ + http://www.nndev.org/

Anton

Anton Shterenlikht

unread,

Apr 19, 2013, 4:01:44 AM4/19/13

to

glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:

>Paul Sture <nos...@sture.ch> wrote:

>(snip)
>> I came across a comment some time ago to the effect that when discussing
>> details of Fortran compiler implementations for other platforms, it was
>> common to say "Let's see what DEC Fortran does here".

>For some years, IBM and DEC were the big players in the game.

>DEC Fortran had, relative to IBM, many more extensions to the standard.

I was under the impression that, at least wrt
scientific/engineering uses, Cray compiler
has been ahead of the standard for at least
the last 20 years. Right now Cray have many
features which are likely to appear in the
next standard (coarray reductions).

Anyway, back to my original post: I'm happily
running my fortran 2008 codes on linux/x86-64
with GCC, Intel and Cray compilers and on
FreeBSD/ia64 with GCC. I try to test the
portability as much as possible, so having access
to a 2008 compliant (at least as far as coarrays)
compiler on VMS would be great.
From all the replies I got, I gather it's not
going to happen any time soon.

Many thanks

Anton

Paul Sture

unread,

Apr 19, 2013, 6:50:54 AM4/19/13

to

In article <kkqsv3$ino$1...@speranza.aioe.org>,

Anton Shterenlikht <me...@mech-cluster241.men.bris.ac.uk> wrote:

> Paul Sture <nos...@sture.ch> writes:
>
> >Anton, how many mis-spellings of your name do you get in the UK?
>
> too many to keep track of.

:-)

> But it wasn't better back in russia.
> And anyway, no matter how you spell it,
> living with such surname in ussr/russia is
> not recommended...

Doesn't sound good...

--
Paul Sture

Paul Sture

unread,

Apr 19, 2013, 7:18:17 AM4/19/13

to

In article <kkqt4c$ino$2...@speranza.aioe.org>,

Thanks but I was trying to use Google Groups for searching old messages,
not for reading and posting.

FWIW I am using the http://eternal-september.org news server and
MT-NewsWatcher for reading and posting. The latter doesn't cope very
well with UTF but it's a nice multi-windowed news reader that I am
comfortable with.

I also use leafnode, a lightweight news server which serves only the
groups you are interested in. This means that I don't need to worry
about slow news services (my previous provider throttled news groups at
64Kb/s) and if I am somewhere where port 119 is blocked, I can ssh into
it and use a command line news reader.

--
Paul Sture

Michael Kraemer

unread,

Apr 19, 2013, 7:32:01 AM4/19/13

to

In article <nospam-EECE63....@news.chingola.ch>, Paul Sture

<nos...@sture.ch> writes:
>
> Thanks but I was trying to use Google Groups for searching old messages,
> not for reading and posting.

Still no alternative for accessing 1990's usenet?

Bill Gunshannon

unread,

Apr 19, 2013, 8:17:42 AM4/19/13

to

In article <nospam-627B0E....@news.chingola.ch>,

unread,

Apr 20, 2013, 7:10:35 AM4/20/13

to

In article <kkr9vh$teb$1...@lnx107.hrz.tu-darmstadt.de>,

Not any that I know of. I have more than once toyed with the idea of
keeping copies of the newsgroups I am interested in, but the last time I
looked at terms and conditions for news providers they seemed to
prohibit republishing.

--
Paul Sture

Bill Gunshannon

unread,

Apr 20, 2013, 9:30:57 AM4/20/13

to

In article <nospam-40E4F5....@news.chingola.ch>,

Paul Sture <nos...@sture.ch> writes:
> In article <kkr9vh$teb$1...@lnx107.hrz.tu-darmstadt.de>,
> m.kr...@gsi.de (Michael Kraemer) wrote:
>
>> In article <nospam-EECE63....@news.chingola.ch>, Paul Sture
>> <nos...@sture.ch> writes:
>> >
>> > Thanks but I was trying to use Google Groups for searching old messages,
>> > not for reading and posting.
>>
>> Still no alternative for accessing 1990's usenet?
>
> Not any that I know of. I have more than once toyed with the idea of
> keeping copies of the newsgroups I am interested in, but the last time I
> looked at terms and conditions for news providers they seemed to
> prohibit republishing.

Considering the very nature of USENET News I find that rather hard to
believe. NewsServerA sends articles to NewServerB who further floods
them to NewsServerC, NewsServerD, NewsServerE and NewsServerF. Repeat
ad infinitum at each server.

Paul Sture

unread,

Apr 21, 2013, 10:20:23 AM4/21/13

to

In article <atfjkh...@mid.individual.net>,

bi...@server1.cs.uofs.edu (Bill Gunshannon) wrote:

> In article <nospam-40E4F5....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> writes:
> > In article <kkr9vh$teb$1...@lnx107.hrz.tu-darmstadt.de>,
> > m.kr...@gsi.de (Michael Kraemer) wrote:
> >
> >> In article <nospam-EECE63....@news.chingola.ch>, Paul Sture
> >> <nos...@sture.ch> writes:
> >> >
> >> > Thanks but I was trying to use Google Groups for searching old messages,
> >> > not for reading and posting.
> >>
> >> Still no alternative for accessing 1990's usenet?
> >
> > Not any that I know of. I have more than once toyed with the idea of
> > keeping copies of the newsgroups I am interested in, but the last time I
> > looked at terms and conditions for news providers they seemed to
> > prohibit republishing.
>
> Considering the very nature of USENET News I find that rather hard to
> believe. NewsServerA sends articles to NewServerB who further floods
> them to NewsServerC, NewsServerD, NewsServerE and NewsServerF. Repeat
> ad infinitum at each server.

Here's what news.individual has to say

http://www.individual.net/rules.php

"Redistribution of News Articles
Messages downloaded from this server may not be redistributed to third
parties (i.e. you may not set up things like a news server, proxy or
gateway using your account). Both the distribution to family members and
passing on single articles are excluded from this restriction. Any other
exceptions need explicit and prior approval by us."

Though I don't see any restriction in the Eternal September Terms of Use:

http://www.eternal-september.org/index.php?showpage=terms

--
Paul Sture

unread,

Apr 22, 2013, 11:21:13 AM4/22/13

to

On 4/18/2013 10:48 AM, Paul Sture wrote:
>
> To sum up, they moved in 2001 but stayed in the same offices.
>

They are no longer in the old ZKO site. They moved last year
to a place in Merrimack NH.

Buz Powers
(an ex-digital employee who worked in the languages group in ZKO)
--
M.I.T. Lincoln Laboratory
Advanced SatCom Systems and Operations

Johnny Billquist

unread,

Apr 22, 2013, 11:33:09 AM4/22/13

to

On 2013-04-22 16:44, Bob Koehler wrote:
> In article <nospam-627B0E....@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>>
>> No. This stuff came from the heritage of the first compiler available
>> for the VAX 11/780 being Fortran IV. Among a heap of other stuff there
>> was a bunch of string handling routines which weren't necessary once
>> Fortran 77 arrived (and for new programs I used that).
>
> Athough I'm not sure it met the ANSI Fortran-77 standard, the very
> first Fortran compiler we had on our 11/780 under VMS 1.x did have
> CHARACTER, block IF, ..., and all the other things we were looking
> for in the -77 standard. I think DEC was calling it Fortran-IV-Plus.

Indeed. Fortran-IV-Plus had a lot of things that ended up in the F77
standard. F4P was pretty nice, but once F77 came out, DEC stopped the
F4P compiler.

> IIRC, Fortran-IV-Plus on RSX was pretty much the same, except with
> built-in funtions instead of %LOC and %VAL, and even the Fortran-77
> for RSX compiler didn't meet the standard with respect to using
> LEN on passed CHARACTER arguments.

I thought the F4P on VMS was just the RSX compiler straight off. I
thought it ran in compatibility mode.

Not sure what the standard says, but I've been bitten when moving code
from VMS to RSX with regards to the LEN function. In RSX, LEN will give
the size of the variable. Strings don't have dynamic length. And I'm not
sure I understand how that was meant to work. If you say CHARACTER*80
FOO, and the do a LEN(FOO), returning 80 seems pretty reasonable (no
matter what stuff you have assigned to FOO).

(Was it called LEN, or ILEN, by the way?)

Johnny

gin...@adacore.com

unread,

Apr 22, 2013, 2:50:51 PM4/22/13

to

Yes, we have added support for many VMS pragma, so that the VMS headers can be parsed by gcc.

We were able to cross-compile some non-trivial programs such as unzip, for VMS.

Tristan.

glen herrmannsfeldt

unread,

Apr 22, 2013, 5:36:03 PM4/22/13

to

Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:
> In article <nospam-627B0E....@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:

>> No. This stuff came from the heritage of the first compiler available
>> for the VAX 11/780 being Fortran IV. Among a heap of other stuff there
>> was a bunch of string handling routines which weren't necessary once
>> Fortran 77 arrived (and for new programs I used that).

> Athough I'm not sure it met the ANSI Fortran-77 standard, the very
> first Fortran compiler we had on our 11/780 under VMS 1.x did have
> CHARACTER, block IF, ..., and all the other things we were looking
> for in the -77 standard. I think DEC was calling it Fortran-IV-Plus.

WATFIV had CHARACTER and block IF in about 1973. People working on
the standard knew what things would look like, and might have wanted
to test them out.

As I remember it, the early VAX/VMS compilers ran in compatibility
mode, so maybe not so different from the RSX compilers.

> IIRC, Fortran-IV-Plus on RSX was pretty much the same, except with
> built-in funtions instead of %LOC and %VAL, and even the Fortran-77
> for RSX compiler didn't meet the standard with respect to using
> LEN on passed CHARACTER arguments.

It seems to have taken a special fixup in the VMS linker to make it work.

-- glen

glen herrmannsfeldt

unread,

Apr 22, 2013, 5:40:56 PM4/22/13

to

Johnny Billquist <b...@softjar.se> wrote:

(snip, someone wrote)

>> IIRC, Fortran-IV-Plus on RSX was pretty much the same, except with
>> built-in funtions instead of %LOC and %VAL, and even the Fortran-77
>> for RSX compiler didn't meet the standard with respect to using
>> LEN on passed CHARACTER arguments.

> I thought the F4P on VMS was just the RSX compiler straight off. I
> thought it ran in compatibility mode.

But generating VAX code, or not?

> Not sure what the standard says, but I've been bitten when moving code
> from VMS to RSX with regards to the LEN function. In RSX, LEN will give
> the size of the variable. Strings don't have dynamic length. And I'm not
> sure I understand how that was meant to work. If you say CHARACTER*80
> FOO, and the do a LEN(FOO), returning 80 seems pretty reasonable (no
> matter what stuff you have assigned to FOO).

Fortran 77 still doesn't to any dynamic allocation. But a function
argument, passed by reference, can have a length.

The complication is that Fortran 66 stores character data in numeric
(usually INTEGER) variables, and those can also be passed to functions.

CHARACTER are passed by descriptor (for VAX), and INTEGER by reference.
The linker fixed up the case where a CHARACTER (at least constant
if not variable) is passed to an INTEGER (or array of) argument.

-- glen

Johnny Billquist

unread,

Apr 22, 2013, 5:45:47 PM4/22/13

to

On 2013-04-22 23:40, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip, someone wrote)
>>> IIRC, Fortran-IV-Plus on RSX was pretty much the same, except with
>>> built-in funtions instead of %LOC and %VAL, and even the Fortran-77
>>> for RSX compiler didn't meet the standard with respect to using
>>> LEN on passed CHARACTER arguments.
>
>> I thought the F4P on VMS was just the RSX compiler straight off. I
>> thought it ran in compatibility mode.
>
> But generating VAX code, or not?

I thought not. But I might be wrong... I never used F4P on VMS. Only on
RSX...

>> Not sure what the standard says, but I've been bitten when moving code
>> from VMS to RSX with regards to the LEN function. In RSX, LEN will give
>> the size of the variable. Strings don't have dynamic length. And I'm not
>> sure I understand how that was meant to work. If you say CHARACTER*80
>> FOO, and the do a LEN(FOO), returning 80 seems pretty reasonable (no
>> matter what stuff you have assigned to FOO).
>
> Fortran 77 still doesn't to any dynamic allocation. But a function
> argument, passed by reference, can have a length.

Right. And F77 under RSX handles that, if I remember right.

> The complication is that Fortran 66 stores character data in numeric
> (usually INTEGER) variables, and those can also be passed to functions.

Same with Fortran IV... I was pretty used to storing strings in integer
arrays...

> CHARACTER are passed by descriptor (for VAX), and INTEGER by reference.
> The linker fixed up the case where a CHARACTER (at least constant
> if not variable) is passed to an INTEGER (or array of) argument.

I also seem to remember that strings in Fortran 77 under VMS could
actually be dynamic in length, but I might be remembering wrong. Too
long since I worked on that.

Johnny

Ken Fairfield

unread,

Apr 22, 2013, 7:41:39 PM4/22/13

to

On Monday, April 22, 2013 2:45:47 PM UTC-7, Johnny Billquist wrote:
[...]

> I also seem to remember that strings in Fortran 77 under VMS could
> actually be dynamic in length, but I might be remembering wrong. Too
> long since I worked on that.

Well, VMS supports dynamic strings, especially for those
languages that require them (Basic?). But the Fortran
compiler does not *directly* support them. It's sort of
about standard compliance. (Dynamic allocation of arrays,
etc., came in F90, dynamically allocatable character
variables has only just been standardized in F2008).

But there are library (LIB$) routines available that allow
the user to use dynamic strings within a Fortran
program. It's usually in conjunction with calling some
procedure (written in another language) which requires a
dynamic string as an argument. The particular case I recall
involved calls to Callable TPU...

-Ken

Simon Clubley

unread,

Apr 22, 2013, 8:43:31 PM4/22/13

to

Interesting, thanks.

Given the last sentence above, is the cross-compiler build method still
a work in progress or is it regarded as a finished product ?

Now I know you have added cross compiler support instead of building
everything native on VMS, I've spent a bit of time over the last couple
of days trying to build at least the first part of the tool chain.

Of course, I have several questions which have cropped up as a result. :-)

Which exception model are you using ? I had _many_ attempts at trying to
get unwind-dw2.c to build, before I gave up and switched to sjlj exceptions
to bypass this issue.

Are you using a sysroot during building and are you replacing the gcc
headers with the VMS versions or just adding missing headers as required ?

After trying various options, I'm currently using the gcc supplied
headers instead of the VMS versions to build gcc and adding to the set
of headers (ie: stdlib.h) from the VMS headers as required. I also have
a full copy of the extracted starlet headers in include/vms/ and I've
tweaked the various VMS headers (__int64/resource.h/etc) as required.

In the final built and installed compiler, is it intended to have a
mixture of gcc supplied and VMS headers on the include search path,
or are you removing all the gcc supplied headers and replacing them
with the VMS headers ?

BTW, in case you are not aware, binutils 2.23.2 is broken while
assembling crtbegin; you get the following errors:

../../gcc-4.6.2/gcc/crtstuff.c: In function 'frame_dummy':
../../gcc-4.6.2/gcc/crtstuff.c:381:19: warning: array subscript is above array bounds [-Warray-bounds]
/tmp/ccexkclj.s: Assembler messages:
/tmp/ccexkclj.s:106: Error: previous .ent not closed by a .end
/tmp/ccexkclj.s:149: Error: previous .ent not closed by a .end

Reverting to binutils 2.21.1 fixed this specific problem.

Thanks,

Craig A. Berry

unread,

Apr 22, 2013, 10:21:00 PM4/22/13

to

In article <afd7d497-6598-48f9...@googlegroups.com>,

That's good news. Thank you for your work and your information.

gin...@adacore.com

unread,

Apr 23, 2013, 1:58:44 AM4/23/13

to

On Tuesday, April 23, 2013 2:43:31 AM UTC+2, Simon Clubley wrote:
> On 2013-04-22, gin...@adacore.com <gin...@adacore.com> wrote:
>
> > Yes, we have added support for many VMS pragma, so that the VMS headers can be parsed by gcc.
>
> >
>
> > We were able to cross-compile some non-trivial programs such as unzip, for VMS.
>
> >
>
> > Tristan.
>
>
>
> Interesting, thanks.
>
>
>
> Given the last sentence above, is the cross-compiler build method still
> a work in progress or is it regarded as a finished product ?

We are first building a cross compiler to build the native compiler.

Note that I am pretty sure we still have patches (at least for Ada) that
aren't merged into FSF gcc.

> Now I know you have added cross compiler support instead of building
> everything native on VMS, I've spent a bit of time over the last couple
> of days trying to build at least the first part of the tool chain.

Humm, good luck :-)

> Of course, I have several questions which have cropped up as a result. :-)
>
> Which exception model are you using ? I had _many_ attempts at trying to
> get unwind-dw2.c to build, before I gave up and switched to sjlj exceptions
> to bypass this issue.

We are using dwarf-2, but it may be simpler to use sjlj at first.

> Are you using a sysroot during building and are you replacing the gcc
> headers with the VMS versions or just adding missing headers as required ?

There is no gcc headers (except a few one that are very compiler dependent, such
as stdargs or limits)

> After trying various options, I'm currently using the gcc supplied
> headers instead of the VMS versions to build gcc and adding to the set
> of headers (ie: stdlib.h) from the VMS headers as required. I also have
> a full copy of the extracted starlet headers in include/vms/ and I've
> tweaked the various VMS headers (__int64/resource.h/etc) as required.

Most of the tweaks are handled by fixincludes.

> In the final built and installed compiler, is it intended to have a
> mixture of gcc supplied and VMS headers on the include search path,
> or are you removing all the gcc supplied headers and replacing them
> with the VMS headers ?

No, you cannot remove the gcc supplied headers.

> BTW, in case you are not aware, binutils 2.23.2 is broken while
> assembling crtbegin; you get the following errors:
>
> ../../gcc-4.6.2/gcc/crtstuff.c: In function 'frame_dummy':
> ../../gcc-4.6.2/gcc/crtstuff.c:381:19: warning: array subscript is above array bounds [-Warray-bounds]
> /tmp/ccexkclj.s: Assembler messages:
> /tmp/ccexkclj.s:106: Error: previous .ent not closed by a .end
> /tmp/ccexkclj.s:149: Error: previous .ent not closed by a .end

No, the latest version of binutils correctly reports issues in the
assembly file.

Tristan.

Simon Clubley

unread,

Apr 23, 2013, 7:57:20 AM4/23/13

to

On 2013-04-23, gin...@adacore.com <gin...@adacore.com> wrote:
> On Tuesday, April 23, 2013 2:43:31 AM UTC+2, Simon Clubley wrote:
>>
>> Interesting, thanks.
>>
>> Given the last sentence above, is the cross-compiler build method still
>> a work in progress or is it regarded as a finished product ?
>
> We are first building a cross compiler to build the native compiler.
>

Clarification: in this context, I just meant finished product as in capable
of been used as a fully functional cross compiler, not finished product as
in selling it to your customers.

> Note that I am pretty sure we still have patches (at least for Ada) that
> aren't merged into FSF gcc.
>

Ok, I'll keep that in mind, thanks.

>> Now I know you have added cross compiler support instead of building
>> everything native on VMS, I've spent a bit of time over the last couple
>> of days trying to build at least the first part of the tool chain.
>
> Humm, good luck :-)
>

Thanks. :-) This is just a little diversion for me from my current hobbyist
projects, so I will not be spending much more time on it anyway.

>> Of course, I have several questions which have cropped up as a result. :-)
>>
>> Which exception model are you using ? I had _many_ attempts at trying to
>> get unwind-dw2.c to build, before I gave up and switched to sjlj exceptions
>> to bypass this issue.
>
> We are using dwarf-2, but it may be simpler to use sjlj at first.
>

Thanks. That tells me it is possible to build unwind-dw2.c if I can just hit
upon the right set of build conditions.

>> Are you using a sysroot during building and are you replacing the gcc
>> headers with the VMS versions or just adding missing headers as required ?
>
> There is no gcc headers (except a few one that are very compiler dependent, such
> as stdargs or limits)
>

Those are the headers I was thinking of. For example, at one point, I had
some issues, since solved, with __size_t (or similar).

>> After trying various options, I'm currently using the gcc supplied
>> headers instead of the VMS versions to build gcc and adding to the set
>> of headers (ie: stdlib.h) from the VMS headers as required. I also have
>> a full copy of the extracted starlet headers in include/vms/ and I've
>> tweaked the various VMS headers (__int64/resource.h/etc) as required.
>
> Most of the tweaks are handled by fixincludes.
>

Oh, that is interesting.

I haven't got as far as trying to think about streamlining the build yet,
so I've been adding in various headers after build failures. Are you making
the headers available to gcc during the configure stage so fixincludes
can find them ?

>> In the final built and installed compiler, is it intended to have a
>> mixture of gcc supplied and VMS headers on the include search path,
>> or are you removing all the gcc supplied headers and replacing them
>> with the VMS headers ?
>
> No, you cannot remove the gcc supplied headers.
>

I've come to that conclusion myself, but it's nice to know the gcc and
VMS headers are supposed to co-exist.

>> BTW, in case you are not aware, binutils 2.23.2 is broken while
>> assembling crtbegin; you get the following errors:
>>
>> ../../gcc-4.6.2/gcc/crtstuff.c: In function 'frame_dummy':
>> ../../gcc-4.6.2/gcc/crtstuff.c:381:19: warning: array subscript is above array bounds [-Warray-bounds]
>> /tmp/ccexkclj.s: Assembler messages:
>> /tmp/ccexkclj.s:106: Error: previous .ent not closed by a .end
>> /tmp/ccexkclj.s:149: Error: previous .ent not closed by a .end
>
> No, the latest version of binutils correctly reports issues in the
> assembly file.
>

I may need to use the latest gcc then.

Because these were just experiments and because it appeared Alpha may have
been added a while back, I just used the latest version of gcc I had to
hand locally.

Bob Koehler

unread,

Apr 23, 2013, 11:16:52 AM4/23/13

to

In article <kl3l7r$9ff$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> Indeed. Fortran-IV-Plus had a lot of things that ended up in the F77
> standard. F4P was pretty nice, but once F77 came out, DEC stopped the
> F4P compiler.
>

My first 11/780 was running VMS 1.x, and lots of things were in
compatability mode. Don't know about the compiler.

My next 11/780 arrived at the time of VMS 2.2, and lots of things
were still in compatability mode, but DEC told us the only two
native compilers were Fortran and COBOL.

We started interfacing Fortran routines with Macro-32 routines right
away, so I don't think the compiler could have been generating
PDP-11 object, although it could have had heritage to a
cross-compiler from RSX (running in compatability mode but generating
VAX object).

I just recall the day I got the last programmer off SOS and on to
EDT, and the CPU load went way down. Seems SOS must have been quite
a compatability mode CPU hog.

Bob Koehler

unread,

Apr 23, 2013, 11:23:33 AM4/23/13

to

In article <kl4ag3$29k$1...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> It seems to have taken a special fixup in the VMS linker to make it work.

For passing CHARACTER to CHARACTER, no fix up is needed. Lots of
Fortran-77 compilers only support that. To implement the
Fortran-77 standard the compiler needs to pass both the size and
location of CHARACTER arguments.

But DEC supported passing character constants to integer, real, ...
variables, as we had always done in Fortran-IV. That took a linker
fixup as in the calling routine the compiler would generate pass by
descriptor, but in the receiving routine it would be expecting pass
by reference.

Different Fortran compilers have different ways of passing CHARACTER
variable length between routines, but the RSX just didn't pass it.
So existing RSX code that passed character constants to integer, ...
would keep running, but new code could not take advantage of the
passed length wihtout explicitly passing it.

Bob Koehler

unread,

Apr 23, 2013, 11:29:31 AM4/23/13

to

In article <kl4b2h$n6h$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> I also seem to remember that strings in Fortran 77 under VMS could
> actually be dynamic in length, but I might be remembering wrong. Too
> long since I worked on that.

Native Fortran strings still don't support dynamic lengths, even in
the 2008 standard (there was a proposal, but I guess it didn't pass).
The only work around is allocated variables, but those don't
automagically change allocation.

VMS Fortran compilers don't have an extension that I know of to
enable dynamic length strings.

But VMS programmers, in any language, can take adavantage of LIB$
and STR$ routines that do dynamic length strings. And there are
dynamic length string library implementations in Fortran, using
allocated variables and user defined types, if you look around the
'net.

Johnny Billquist

unread,

Apr 23, 2013, 10:32:18 AM4/23/13

to

On 2013-04-23 17:16, Bob Koehler wrote:
> In article <kl3l7r$9ff$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>
>> Indeed. Fortran-IV-Plus had a lot of things that ended up in the F77
>> standard. F4P was pretty nice, but once F77 came out, DEC stopped the
>> F4P compiler.
>>
>
> My first 11/780 was running VMS 1.x, and lots of things were in
> compatability mode. Don't know about the compiler.
>
> My next 11/780 arrived at the time of VMS 2.2, and lots of things
> were still in compatability mode, but DEC told us the only two
> native compilers were Fortran and COBOL.
>
> We started interfacing Fortran routines with Macro-32 routines right
> away, so I don't think the compiler could have been generating
> PDP-11 object, although it could have had heritage to a
> cross-compiler from RSX (running in compatability mode but generating
> VAX object).

Well, if the Fortran compiler was "native" I wouldn't expect it to have
anything to do with the compatibility mode...

unread,

Apr 23, 2013, 3:22:55 PM4/23/13

to

Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:
> In article <kl4ag3$29k$1...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:

>> It seems to have taken a special fixup in the VMS linker to make it work.

> For passing CHARACTER to CHARACTER, no fix up is needed. Lots of
> Fortran-77 compilers only support that. To implement the
> Fortran-77 standard the compiler needs to pass both the size and
> location of CHARACTER arguments.

Yes.

> But DEC supported passing character constants to integer, real, ...
> variables, as we had always done in Fortran-IV. That took a linker
> fixup as in the calling routine the compiler would generate pass by
> descriptor, but in the receiving routine it would be expecting pass
> by reference.

I think you pretty much have to do that to support Fortran 77, which
should remain back compatible. Well, I suppose strictly only for
Hollerith constants, but for compilers that supported them,
apostrophe delimited constants were usual.

> Different Fortran compilers have different ways of passing CHARACTER
> variable length between routines,

I figured this out about 10 years ago in a discussion on
comp.lang.fortran.

I knew that I had done it in VAX/VMS so many years before, but hadn't
thought at the time why it should or should not work.

More usual for Fortran compilers is to pass extra arguments at the
end of the argument list with the lengths, most likely by value.
Passing a CHARACTER constant (or variable) to a routine with an INTEGER
(or REAL or REAL*8, etc.) dummy argument just works. It ignores the
length argument, as usual for Fortran-IV.

But VAX/VMS wanted to keep a consistent calling convention across
languages, and that meant passing CHARACTER by descriptor.
So, the fixup was needed if the callee wasn't expecting a
descriptor to be passed.

> but the RSX just didn't pass it.
> So existing RSX code that passed character constants to integer, ...
> would keep running, but new code could not take advantage of the
> passed length wihtout explicitly passing it.

-- glen

unread,

Apr 24, 2013, 10:39:42 AM4/24/13

to

In article <kl6n2f$7bl$1...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:

> Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:
>
>> But DEC supported passing character constants to integer, real, ...
>> variables, as we had always done in Fortran-IV. That took a linker
>> fixup as in the calling routine the compiler would generate pass by
>> descriptor, but in the receiving routine it would be expecting pass
>> by reference.
>
> I think you pretty much have to do that to support Fortran 77, which
> should remain back compatible. Well, I suppose strictly only for
> Hollerith constants, but for compilers that supported them,
> apostrophe delimited constants were usual.

I thought so, too. But I've heard from folks who's compiler didn't
support it and I don't know if the standard requires that kind of
upward compatability, or if it's just because DEC believed in upward
compatability.

glen herrmannsfeldt

unread,

Apr 24, 2013, 2:19:45 PM4/24/13

to

I remember SOS on TOPS-10, not EDIT.

Before TOPS-10, the system I knew best was WYLBUR, which has commands
close enough to SOS that I had a pretty easy time learning to use it.

I didn't learn TECO until some years later, working on RT-11.

Last time I used TECO was with VMS/Itanium, and it crashed every few
commands.

-- glen

glen herrmannsfeldt

unread,

Apr 24, 2013, 2:23:21 PM4/24/13

to

OK, I have never thought about this one before. Does Fortran 77 allow
Hollerith constants as actual arguments to CHARACTER dummy arguments?

Otherwise, the DEC Fortran IV compilers allowed apostrophed constants
for so long that I think VAX compilers would have to support them, even
if the standard didn't require it.

-- glen

Bob Koehler

unread,

Apr 24, 2013, 3:48:33 PM4/24/13

to

In article <kl97o1$uc4$1...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> I remember SOS on TOPS-10, not EDIT.

Yes, now that I remeber further back, it was known as SOS on
TOPS-10, too. Only on TOPS-20 did I see it called EDIT.

> Before TOPS-10, the system I knew best was WYLBUR, which has commands
> close enough to SOS that I had a pretty easy time learning to use it.

I knew guys who used WYLBUR, but I never worked on those systems.

My first editor was TECO on TOPS-10. That's what our Physics lab TA
taught us before he sent us off to pick up a FORTRAN manual and write
something. I learned SOS at the next school.

Bob Koehler

unread,

Apr 24, 2013, 3:49:57 PM4/24/13

to

In article <kl97uo$uvr$1...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> OK, I have never thought about this one before. Does Fortran 77 allow
> Hollerith constants as actual arguments to CHARACTER dummy arguments?

I don't think the Fortran-77 standard recognizes Hollerith, but I
think lots of compilers do. And treats them the same as quoted
character strings.

Ken Fairfield

unread,

Apr 24, 2013, 3:15:13 PM4/24/13

to

On Wednesday, April 24, 2013 11:23:21 AM UTC-7, glen herrmannsfeldt wrote:
[...]

> OK, I have never thought about this one before. Does Fortran 77 allow
> Hollerith constants as actual arguments to CHARACTER dummy arguments?

No. You probably know that already from discussions over
in c.l.f. That VAX Fortran allowed it was/is an extension
that allowed old programs to work under the new compiler.

But as Bob said in another follow-up, Hollerith was already
gone as of the F77 standard.

Also note that in the port of the Fortran compiler to Alpha,
this backward compatibility (with ancient source code) was
lost. You "can't do that" on an Alpha (or Itanium).

> Otherwise, the DEC Fortran IV compilers allowed apostrophed constants
> for so long that I think VAX compilers would have to support them, even
> if the standard didn't require it.

I'm not entirely sure what you mean by "apostrophed constants".
That *is* the way you write a character constant, right? If you
mean assigning that character constant to a numerical variable
(all that was available pre-F77), that is simply non-standard.
VAX Fortran may have allowed it as an extension, but...

-Ken

glen herrmannsfeldt

unread,

Apr 24, 2013, 4:27:02 PM4/24/13

to

Ken Fairfield <ken.fa...@gmail.com> wrote:
> On Wednesday, April 24, 2013 11:23:21 AM UTC-7, glen herrmannsfeldt wrote:
> [...]
>> OK, I have never thought about this one before. Does Fortran 77 allow
>> Hollerith constants as actual arguments to CHARACTER dummy arguments?

> No. You probably know that already from discussions over
> in c.l.f. That VAX Fortran allowed it was/is an extension
> that allowed old programs to work under the new compiler.

I mostly never used Hollerith constants. The IBM OS/360
compilers allowed apostrophed constants in the places where
Hollerith constants were allowed.

In standard Fortran 66, I believe that they are allowed only
in DATA statements and subprogram actual arguments.

> But as Bob said in another follow-up, Hollerith was already
> gone as of the F77 standard.

> Also note that in the port of the Fortran compiler to Alpha,
> this backward compatibility (with ancient source code) was
> lost. You "can't do that" on an Alpha (or Itanium).

>> Otherwise, the DEC Fortran IV compilers allowed apostrophed constants
>> for so long that I think VAX compilers would have to support them,
>> even if the standard didn't require it.

> I'm not entirely sure what you mean by "apostrophed constants".

Constants like 'XYZ' instead of 3HXYZ.

> That *is* the way you write a character constant, right? If you
> mean assigning that character constant to a numerical variable
> (all that was available pre-F77), that is simply non-standard.
> VAX Fortran may have allowed it as an extension, but...

In Fortran 66, you can:

CALL SUB(4HABCD)

and

SUBROUTINE SUB(I)
WRITE(6,1) I
1 FORMAT(1X,A4)
RETURN
END

but many compilers allowed

CALL SUB('ABCD')

But yes, many DEC compilers allowed assignment of character or
Hollerith constants in assignment statements as an extension.

I='ABCD'
J=4HEFGH

I usually avoided that, and just used DATA statements.

-- glen

glen herrmannsfeldt

unread,

Apr 24, 2013, 4:34:19 PM4/24/13

to

Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:

(snip, I wrote)

>> I remember SOS on TOPS-10, not EDIT.

> Yes, now that I remeber further back, it was known as SOS on
> TOPS-10, too. Only on TOPS-20 did I see it called EDIT.

That is what I forgot. It was a few years between when I used TOPS-10
and TOPS-20 (at a completely different place), but yes it did work
the same.

>> Before TOPS-10, the system I knew best was WYLBUR, which has commands
>> close enough to SOS that I had a pretty easy time learning to use it.

> I knew guys who used WYLBUR, but I never worked on those systems.

> My first editor was TECO on TOPS-10. That's what our Physics lab TA
> taught us before he sent us off to pick up a FORTRAN manual and write
> something. I learned SOS at the next school.

-- glen

glen herrmannsfeldt

unread,

Apr 24, 2013, 4:36:41 PM4/24/13

to

OK, I was thinking that if they allowed Hollerith constants, passed by
reference, and quoted (with apostrophes) strings by descriptor, then
Fortran 66 programs would work, and also Fortran 77 programs, but not
mixtures between the two.

-- glen

Craig A. Berry

unread,

Apr 24, 2013, 10:36:21 PM4/24/13

to

In article <kl823c$8u1$1...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> Success: I now have gcc built as a cross compiler on Linux and it is
> outputting simple executable which run on VMS:
>
> $ sh sys/noproc
> OpenVMS V8.3 on node EISNER 24-APR-2013 02:38:50.85 Uptime 36 11:11:53
> $ r hello.exe
> Hello world

Very cool. How different is cross compiling a simple program from
cross compiling the compiler itself?

> I probably will not be spending much more time on this so this is as far
> as I am likely to go.

I do wish you would continue, but I understand it's likely more than a
single afternoon's work to have something worth sharing.

gin...@adacore.com

unread,

Apr 25, 2013, 2:44:18 AM4/25/13

to

Congrats!

Paul Sture

unread,

Apr 25, 2013, 6:40:20 AM4/25/13

to

In article <kl8f3s$43c$1...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> On 2013-04-24, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
> >
> > Just so that I'm understanding here... :-)
> >
> > Whas that "Hello world" program in Fortran or in C ?
> >
>
> It was in C; I don't even know how much work would be needed before
> the Fortran implementation in gcc will build on VMS (even as a
> cross compiler).

As an aside, I have this Fortran from 24-APR-2009

$ type hello.for
cDEC$ IDENT '1.2.3'
program hello
print *,"Hello World."
end program hello

Yes, I was testing the behaviour of the cDEC$ directive here, which
possibly opens up another can of worms.

--
Paul Sture

Simon Clubley

unread,

Apr 25, 2013, 7:47:19 AM4/25/13

to

On 2013-04-24, Craig A. Berry <craig...@mac.com.invalid> wrote:
> In article <kl823c$8u1$1...@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>> Success: I now have gcc built as a cross compiler on Linux and it is
>> outputting simple executable which run on VMS:
>>
>> $ sh sys/noproc
>> OpenVMS V8.3 on node EISNER 24-APR-2013 02:38:50.85 Uptime 36 11:11:53
>> $ r hello.exe
>> Hello world
>
> Very cool. How different is cross compiling a simple program from
> cross compiling the compiler itself?
>

Thanks.

It's kind of like the difference between building a model aircraft and
building a 747. :-)

In principle, you follow the same build process for both types of aircraft;
it's just that building one of the latter involves a lot more steps and many
more prerequisites. :-)

There's also many more things which can go wrong when you try to build one
of the latter...

Simon Clubley

unread,

Apr 25, 2013, 8:07:01 AM4/25/13

to

On 2013-04-25, gin...@adacore.com <gin...@adacore.com> wrote:
> Congrats!

Thank you.

As I wanted to try building a larger program, I tried to use the cross
compiler to build binutils in VMS hosted mode. I got through a large
part of the process (with mainly header related issues) before ld failed
with a internal error in vms-alpha.c while building size.

However, it looks like the section of code in vms-alpha.c which failed
has been worked on since the version of binutils I am using[*], so I will
have another play with it sometime.

Simon.

[*] When building gcc/binutils over the years, I've traditionally liked to
stay a couple of versions behind when possible as the issues I trip over
tend to have made it to Bugzilla and elsewhere by then.

When I started looking at this, it looked like the majority of public
commits for VMS Alpha had happened several years ago, so I thought a
gcc/binutils from a year or two ago would not make any difference.
I'm currently rethinking that given come of the recent commits I've now
come across. :-)