VMS in the medical field
Bill Gunshannon
by the American Military I did a little research. First, what I
learned and then a question or two.
It seems that currently there are three independant systems. CHCS,
which is a government contract run (by SAIC) system that appears
to run on VMS but is Cache based which means it is definitely not
tied there. The we have AHLTA, which is the DOD system and appears
to be Windows based. And, lastly we have VISTA which was developed
and is used by the VA and runs on MUMPS. So, apparently there is
still a piece of DOD's medical systems running on VMS but one must
also observe that it is not the government using it but SAIC.
Next we come to the article. Apparently the government wants to
make these systems more able to interact and share date. The obvious
answer to that is pick one and standardize. Anyone care to guess who
the frontrunner is? No, not CHCS. :-)
So, being as there are opensource versions of MUMPS available and that
VISTA is publicly available, has anyone ever given any thought to doing
a port of MUMPS to VMS, getting VISTA running on it and offering this
as a turnkey system, possibly to the government if they go in that
direction but also to other hospitals?
Just curious (as someone who until recently didn't even realize MUMPS
was still as widespread and with as large a user base as it actually
has!!)
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>
Arne Vajhøj
> Well, after reading an interesting article on Medical Systems in use
> by the American Military I did a little research. First, what I
> learned and then a question or two.
>
> It seems that currently there are three independant systems. CHCS,
> which is a government contract run (by SAIC) system that appears
> to run on VMS but is Cache based which means it is definitely not
> tied there. The we have AHLTA, which is the DOD system and appears
> to be Windows based. And, lastly we have VISTA which was developed
> and is used by the VA and runs on MUMPS. So, apparently there is
> still a piece of DOD's medical systems running on VMS but one must
> also observe that it is not the government using it but SAIC.
>
> Next we come to the article. Apparently the government wants to
> make these systems more able to interact and share date. The obvious
> answer to that is pick one and standardize. Anyone care to guess who
> the frontrunner is? No, not CHCS. :-)
>
> So, being as there are opensource versions of MUMPS available and that
> VISTA is publicly available, has anyone ever given any thought to doing
> a port of MUMPS to VMS,
Anything wrong with:
http://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/
?
> getting VISTA running on it and offering this
> as a turnkey system, possibly to the government if they go in that
> direction but also to other hospitals?
>
> Just curious (as someone who until recently didn't even realize MUMPS
> was still as widespread and with as large a user base as it actually
> has!!)
MUMPS is like COBOL.
Arne
Bill Gunshannon
Arne Vajhøj <ar...@vajhoej.dk> writes:
> On 06-03-2011 09:06, Bill Gunshannon wrote:
>> Well, after reading an interesting article on Medical Systems in use
>> by the American Military I did a little research. First, what I
>> learned and then a question or two.
>>
>> It seems that currently there are three independant systems. CHCS,
>> which is a government contract run (by SAIC) system that appears
>> to run on VMS but is Cache based which means it is definitely not
>> tied there. The we have AHLTA, which is the DOD system and appears
>> to be Windows based. And, lastly we have VISTA which was developed
>> and is used by the VA and runs on MUMPS. So, apparently there is
>> still a piece of DOD's medical systems running on VMS but one must
>> also observe that it is not the government using it but SAIC.
>>
>> Next we come to the article. Apparently the government wants to
>> make these systems more able to interact and share date. The obvious
>> answer to that is pick one and standardize. Anyone care to guess who
>> the frontrunner is? No, not CHCS. :-)
>>
>> So, being as there are opensource versions of MUMPS available and that
>> VISTA is publicly available, has anyone ever given any thought to doing
>> a port of MUMPS to VMS,
>
> Anything wrong with:
> http://sourceforge.net/projects/fis-gtm/files/GT.M-Alpha-OpenVMS/
> ?
OK, it already exists. So, is there any VAR offering a turnkey VISTA
system on VMS? Maybe Cerner wasn't the answer after all.
>
>> getting VISTA running on it and offering this
>> as a turnkey system, possibly to the government if they go in that
>> direction but also to other hospitals?
>>
>> Just curious (as someone who until recently didn't even realize MUMPS
>> was still as widespread and with as large a user base as it actually
>> has!!)
>
> MUMPS is like COBOL.
As I have learned. I hope to have at least one system running MUMPS
here at the house before too long. Then we will see just how much I
can do with it.
Arne Vajhøj
Note that my comparison was not about syntax and philosophy but
about age and market position.
Arne
Bill Gunshannon
Oh, I understood that completely. I have had people telling me how
COBOL was dead for over a decade now (just like and in some cases the
same people who shared the same sentiment about VMS). I had been out
of touch with MUMPS for at least that long and had been assuming the
same fate but recently have come back in touch with it and, like COBOL,
it has definitely spurred my interest again. And, knowing the market
niche it occupies and and how the strengths of VMS have in the past
and still would fit that niche, thus my query!
Arne Vajhøj
> In article<4d73b430$0$23752$1472...@news.sunsite.dk>,
And MUMPS expertise are still somewhat in demand.
dice.com has 69 open jobs mentioning MUMPS.
Comparison: 17 for OpenVMS and 684 for COBOL.
Arne
Graham Burley
>It seems that currently there are three independant systems. CHCS,
>which is a government contract run (by SAIC) system that appears
>to run on VMS but is Cache based which means it is definitely not
>tied there. The we have AHLTA, which is the DOD system and appears
>to be Windows based. And, lastly we have VISTA which was developed
>and is used by the VA and runs on MUMPS. So, apparently there is
>still a piece of DOD's medical systems running on VMS but one must
>also observe that it is not the government using it but SAIC.
The VA used to run Vista on DSM on VMS clusters, I know they migrated
from DSM to Cache but I don't know what OS, I believe they initially
moved to Cache on VMS but I don't know the current status.
BTW Cache is Mumps, plus alot of stuff.
Mumps is also known as M.
GT.M is freely available on VMS Alpha. GT.M is slighty unusual in
that M code is compiled rather than interpreted.
VAXman-
>In article <8thimq...@mid.individual.net>, billg999@.uofs.edu (Bill Gunshannon) writes:
>
>>It seems that currently there are three independant systems. CHCS,
>>which is a government contract run (by SAIC) system that appears
>>to run on VMS but is Cache based which means it is definitely not
>>tied there. The we have AHLTA, which is the DOD system and appears
>>to be Windows based. And, lastly we have VISTA which was developed
>>and is used by the VA and runs on MUMPS. So, apparently there is
>>still a piece of DOD's medical systems running on VMS but one must
>>also observe that it is not the government using it but SAIC.
>
>The VA used to run Vista on DSM on VMS clusters, I know they migrated
>from DSM to Cache but I don't know what OS, I believe they initially
>moved to Cache on VMS but I don't know the current status.
>
>BTW Cache is Mumps, plus alot of stuff.
Cache being Cache'?
It's a lot of stuff like processes hung at priority 0 in kernel mode. ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.
brendan welch
> MUMPS is like COBOL.
>
> Arne
Just last month, and related to some postings here, I was interested in
a job at the Veterans Administration. One of the qualifications was
MUMPS. When I looked it up on Google, I found the code to be even older
and worse than COBOL. I thought it was more like Postscript (?)
in that it was still tied to the days of stacks. I think of stacks as
being related to the earliest processors, where there was no room or
ability to have even a handful of variables which could be referred to
by name, such as Fortran or Basic.
About 20 years ago, when I was working at a state-sponsored university
(i.e., considered a place where employees seldom left) one of my
co-workers had previous experience on MUMPS and was now working on VMS.
A job opportunity arose in the "outside" world, apparently MUMPS on VMS,
which was just so lucrative, that he abandoned his university job and
took the MUMPS one.
Totally off topic:
Many years ago, I was interviewing for a job at BBN. On the wall of the
important person conducting the interview, I saw some posting with the
name of a nurse, and I recognized the name as the roommate of someone I
knew. I looked into it, and the nurse was working at Massachusetts
General Hospital in Boston, on a computer project. This was in the
EARLY days. The "computer" at the patient's bedside was a teletype, the
actual computer was at BBN in Cambridge. As I see from
my Google above, the language was a predecessor to MUMPS, so that is
really old. I did get an interview, but did not get a job. The reason
was that I did not have enough credits in Statistics; at least that is
what they said.
The function of the teletype was pretty much to tell a nurse, in
somewhat real time, that the patient was due for medication.
Bill Gunshannon
brendan welch <w1...@uml.edu> writes:
>
>> MUMPS is like COBOL.
>>
>> Arne
>
> Just last month, and related to some postings here, I was interested in
> a job at the Veterans Administration. One of the qualifications was
> MUMPS.
To be honest, didn't it acually say ANSI-M as the requirement?
I put infor it, too, but didn't expect to make even the first
cut. Looking at VA jobs was one of the things the got me interested
in MUMPS again.
> When I looked it up on Google, I found the code to be even older
> and worse than COBOL.
Some of us don't consider COBOL to be at all bad. :-) As for MUMPS,
I read an thread in another newsgroup recently where someone posted
an example of his code, and it was truly terrible. Deliberatly
obtuse, one character variables, one character command abbreviations.
Anyone seeing this would be bound to shudder. But then, his later
statement explains it all. Job security!! I thought those days were
long gone and that most places had programming standards. I kinow the
VA does.
> I thought it was more like Postscript (?)
> in that it was still tied to the days of stacks. I think of stacks as
> being related to the earliest processors, where there was no room or
> ability to have even a handful of variables which could be referred to
> by name, such as Fortran or Basic.
It made me think much more of SNOBOL or SPITBOL.
>
> About 20 years ago, when I was working at a state-sponsored university
> (i.e., considered a place where employees seldom left) one of my
> co-workers had previous experience on MUMPS and was now working on VMS.
> A job opportunity arose in the "outside" world, apparently MUMPS on VMS,
> which was just so lucrative, that he abandoned his university job and
> took the MUMPS one.
I would leave here in a heartbeat for a job doing MUMPS on VMS!!
Even faster for COBOL. :-)
Phillip Helbig---undress to reply
Gunshannon) writes:
> >>> MUMPS is like COBOL.
> >>
> >> As I have learned. I hope to have at least one system running MUMPS
> >> here at the house before too long. Then we will see just how much I
> >> can do with it.
> >
> > Note that my comparison was not about syntax and philosophy but
> > about age and market position.
> >
>
> Oh, I understood that completely. I have had people telling me how
> COBOL was dead for over a decade now (just like and in some cases the
> same people who shared the same sentiment about VMS).
This about sums it up:
JF Mezei
platform, I think that many organisations will shun away for new
projects, especially when Intel has no vested interest in that platform
since it has the 64 bit 8086 which performs equally or better except in
a few instance.
storage arrays bring sufficient detachement from computers that
operating systems without VMS's clustering can still provide adequate
availability. And decision makers doNt realise the technical advantages
of VMS' clustering.
Richard B. Gilbert
If memory serves me, COBOL dates from the late 1950s or very early
1960s. Google for the late Rear Admiral Grace Murray Hopper. She
practically invented COBOL.
Ca. 1967 the University of Virginia offered Computer Programming 101 &
102 in COBOL. I got a job fresh out of the Army
on the strength of those courses and some programming in assembler.
I taught myself Fortran using "A Guide to FORTRAN Programming" as my
textbook.
COBOL is, AFAIK, still in use. Computer Science type probably still
sneer at it but there are a few billion lines of COBOL out there.
Phillip Helbig---undress to reply
Gilbert" <rgilb...@comcast.net> writes:
> COBOL is, AFAIK, still in use.
Definitely. Fortran is also still in use at a lot of places, though
many people wrongly think of it as old-fashioned.
JF Mezei
>> COBOL is, AFAIK, still in use.
>
> Definitely. Fortran is also still in use at a lot of places, though
> many people wrongly think of it as old-fashioned.
Are new applications/systems written in those languages, or do they use
different ones when writing new applications from scratch ?
VMS is still in use today, but new applications tend to go to other
platforms. I feel the same is happening to "legacy languages".
Jan-Erik Soderholm
From http://en.wikipedia.org/wiki/COBOL :
"In 1997, the Gartner Group reported that 80% of the world's business ran
on COBOL with over 200 billion lines of code in existence and with an
estimated 5 billion lines of new code annually."
I do not know how much that might have changed in the 14 years since
1997, but probably not that drasticly.
Jan-Erik Soderholm
> Phillip Helbig---undress to reply wrote:
>
>>> COBOL is, AFAIK, still in use.
>>
>> Definitely. Fortran is also still in use at a lot of places, though
>> many people wrongly think of it as old-fashioned.
>
>
> Are new applications/systems written in those languages,
I am writing new applications in COBOL. OK, maybe becuse teh whole
environment where these runs is in COBOL, but anyway... :-)
Pays my bills...
Michael Kraemer
> Are new applications/systems written in those languages, or do they use
> different ones when writing new applications from scratch ?
>
> VMS is still in use today, but new applications tend to go to other
> platforms. I feel the same is happening to "legacy languages".
That's probably true on average,
but it would depend on the industry sector.
Heavy number crunchers might still consider
Fortran for new projects, but most of the time
it will be little more than adding new features to old code.
An indicator for the importance of a language
might be how serious the vendor is about the
respective compiler.
Didn't DEC/Compaq/HP drop e.g. PL/I and Fortran
for VMS quite some time ago?
Phillip Helbig---undress to reply
Mezei <jfmezei...@vaxination.ca> writes: > Phillip Helbig---undress
to reply wrote:
> >> COBOL is, AFAIK, still in use.
> >
> > Definitely. Fortran is also still in use at a lot of places, though
> > many people wrongly think of it as old-fashioned.
>
> Are new applications/systems written in those languages, or do they use
> different ones when writing new applications from scratch ?
Fortran programs aren't written; they are re-written.
More seriously, I don't know what the histogram of the age of (currently
active?) Fortran or Cobol programs looks like.
Phillip Helbig---undress to reply
<M.Kr...@gsi.de> writes:
> An indicator for the importance of a language
> might be how serious the vendor is about the
> respective compiler.
> Didn't DEC/Compaq/HP drop e.g. PL/I and Fortran
> for VMS quite some time ago?
AFAIK, you can still get a Fortran compiler for VMS, but it doesn't
incorporate the new standards.
Sic transit gloria mundi. There was a time when VAX FORTRAN was the de
facto standard and widely recognised as the best Fortran compiler.
Bill Gunshannon
JF Mezei <jfmezei...@vaxination.ca> writes:
And you would be wrong. New applications are being written in COBOL
everyday. I know, because I still write them. ;-)
glen herrmannsfeldt
> Definitely. Fortran is also still in use at a lot of places, though
> many people wrongly think of it as old-fashioned.
So, when will we see a Fortran 2008 compiler for VMS?
(I believe there is work on another, maybe 2013, standard.)
-- glen
glen herrmannsfeldt
(someone wrote)
>> Definitely. Fortran is also still in use at a lot of places, though
>> many people wrongly think of it as old-fashioned.
> Are new applications/systems written in those languages, or do they use
> different ones when writing new applications from scratch ?
One big advantage of Fortran is the legacy of libraries of
routines written in Fortran, waiting to be called from
new programs. If one writes a new main program that calls
many existing routines, does that count as new or old?
-- glen
glen herrmannsfeldt
(snip)
> Just last month, and related to some postings here, I was interested in
> a job at the Veterans Administration. One of the qualifications was
> MUMPS. When I looked it up on Google, I found the code to be even older
> and worse than COBOL. I thought it was more like Postscript (?)
> in that it was still tied to the days of stacks. I think of stacks as
> being related to the earliest processors, where there was no room or
> ability to have even a handful of variables which could be referred to
> by name, such as Fortran or Basic.
A stack is a useful data structure for storing data that will
be needed later, in a Last In First Out manner. That is often true
of intermediate values in evaluating complicated expressions,
one example being the RPN used by HP calculators. TI, who made
algebraic entry calculators competing with HP remarked that theirs
followed the way math was written. In contrast, HP would claim
that they modeled the way people think.
(A+B)*(C+D)
You think: Add A and B, then add C and D, then multiply.
You don't think: left paren, a, plus, b, right paren, times,
left paren, c, plus, d, right paren.
It does have the advantage that it removes the need for instruction
bits to indicate which register is used in an expression, as long
as they follow the LIFO model.
-- glen
Arne Vajhøj
Newer Fortran versions are relative modern.
But Fortran 77 is rather old-fashioned.
Arne
Arne Vajhøj
> On 3/6/2011 2:22 PM, Phillip Helbig---undress to reply wrote:
>> In article<8thrk1...@mid.individual.net>, bill...@cs.uofs.edu (Bill
>> Gunshannon) writes:
>>
>>>>>> MUMPS is like COBOL.
>>>>>
>>>>> As I have learned. I hope to have at least one system running MUMPS
>>>>> here at the house before too long. Then we will see just how much I
>>>>> can do with it.
>>>>
>>>> Note that my comparison was not about syntax and philosophy but
>>>> about age and market position.
>>>>
>>>
>>> Oh, I understood that completely. I have had people telling me how
>>> COBOL was dead for over a decade now (just like and in some cases the
>>> same people who shared the same sentiment about VMS).
>>
>> This about sums it up:
>>
>> http://abstrusegoose.com/323
>>
>
> If memory serves me, COBOL dates from the late 1950s or very early
> 1960s. Google for the late Rear Admiral Grace Murray Hopper. She
> practically invented COBOL.
1959-1960 (design-implementation)
> Ca. 1967 the University of Virginia offered Computer Programming 101 &
> 102 in COBOL. I got a job fresh out of the Army
> on the strength of those courses and some programming in assembler.
> I taught myself Fortran using "A Guide to FORTRAN Programming" as my
> textbook.
>
> COBOL is, AFAIK, still in use. Computer Science type probably still
> sneer at it but there are a few billion lines of COBOL out there.
Usually the estimates for COBOL code are in the range 200-300 BLOC.
But even Fortran are still used a bit in the scientific computing/
number crunching.
Arne
Arne Vajhøj
The answer depends a bit on the granularity you look at.
New company - will not pick COBOL/Fortran
New system - will only pick COBOL/Fortran if that is what the available
resources available knows
New subsystem (for system written in COBOL/Fortran) - may pick
COBOL/Fortran to minimize integration problems, may pick something else
as part of a long term strategy
New module (for system written in COBOL/Fortran) - has to pick COBOL/Fortran
Modifying existing code(for system written in COBOL/Fortran) - has to
pick COBOL/Fortran
Arne
Arne Vajhøj
> JF Mezei wrote 2011-03-06 23:11:
>> Phillip Helbig---undress to reply wrote:
>>>> COBOL is, AFAIK, still in use.
>>>
>>> Definitely. Fortran is also still in use at a lot of places, though
>>> many people wrongly think of it as old-fashioned.
>>
>>
>> Are new applications/systems written in those languages,
>
> I am writing new applications in COBOL. OK, maybe becuse teh whole
> environment where these runs is in COBOL, but anyway... :-)
>
> Pays my bills...
If the purpose of the program is within what COBOL was
designed for, then there are really not that much
technical benefit from picking a newer language.
The most important reason not to pick COBOL must be
resource availability.
Arne
Arne Vajhøj
PL/I comes from Kednos today.
Fortran is still/now HP Fortran (and currently at
versions 8.2 AFAIK).
Arne
Arne Vajhøj
> In article<il11tv$l1n$01$1...@news.t-online.com>, Michael Kraemer
> <M.Kr...@gsi.de> writes:
>
>> An indicator for the importance of a language
>> might be how serious the vendor is about the
>> respective compiler.
>> Didn't DEC/Compaq/HP drop e.g. PL/I and Fortran
>> for VMS quite some time ago?
>
> AFAIK, you can still get a Fortran compiler for VMS, but it doesn't
> incorporate the new standards.
HP Fortran claims to be fully Fortran 90 and 95 compliant.
I have no reason to doubt that.
They do not sypport Fortran 2003 and 2008.
But it is not my impression that those standards are
completely implemented by many vendors.
> Sic transit gloria mundi. There was a time when VAX FORTRAN was the de
> facto standard and widely recognised as the best Fortran compiler.
VAX extensions was the defacto standard.
Quality wise the IBM compiler also had a very good
reputation, but it had a lot less extensions to the
standard.
Arne
Bill Gunshannon
And the aerospace industry. And the defense industries. And I am
sur a number of others that most people think abandoned it long ago.
Arne Vajhøj
> As long as VMS is restricted to a low volume prorietary hardware
> platform, I think that many organisations will shun away for new
> projects, especially when Intel has no vested interest in that platform
> since it has the 64 bit 8086 which performs equally or better except in
> a few instance.
AIX/pSeries and Solaris/SPARC are sold even though they
somewhat also match that description.
IBM and SUN/Oracle is just more aggressive in marketing.
> storage arrays bring sufficient detachement from computers that
> operating systems without VMS's clustering can still provide adequate
> availability. And decision makers doNt realise the technical advantages
> of VMS' clustering.
Todays apps uses databases not files and databases have their own
ways of clustering.
And DLM is not that unique any more.
Arne
Michael Kraemer
>
> AFAIK, you can still get a Fortran compiler for VMS, but it doesn't
> incorporate the new standards.
Incorporating the new standards would mean "being serious".
Michael Kraemer
>
> PL/I comes from Kednos today.
Outsourcing to a 3rd party means there's
not enough business for the original vendor,
which in turn means the language is in decline.
Michael Kraemer
>
> VAX extensions was the defacto standard.
and were a p.i.t.a. because they made Fortran
programs unportable.
> Quality wise the IBM compiler
on S/390 or RS/6000?
> also had a very good
> reputation, but it had a lot less extensions to the
> standard.
not so much in the language itself, but they supported
specific features of the underlying OS, iirc.
Arne Vajhøj
> Arne Vajhøj schrieb:
>> PL/I comes from Kednos today.
>
> Outsourcing to a 3rd party means there's
> not enough business for the original vendor,
> which in turn means the language is in decline.
That is one very likely reason.
But other reasons can exist - "focusing on core
competencies" can lead to sale of profitable
parts of a company.
Arne
Arne Vajhøj
> Arne Vajhøj schrieb:
>> VAX extensions was the defacto standard.
>
> and were a p.i.t.a. because they made Fortran
> programs unportable.
Lots of other compilers supported VAX extensions.
>> Quality wise the IBM compiler
>> also had a very good reputation, but it had a lot less extensions to the
>> standard.
>
> on S/390 or RS/6000?
Mainframe.
Arne
Michael Kraemer
Programming languages are a very important tool
tool to strengthen the own platform.
So why would a Fortran or PL/I compiler be less
"core compentency" than a C/C++ compiler?
Michael Kraemer
> Lots of other compilers supported VAX extensions.
Such as?
Back in the ol' times we used a variety of RISC
Unices (including DEC's) plus IBM mainframe.
None of them had VAX extensions, iirc.
At least not to the extent we could
use them as a common denominator.
>>> Quality wise the IBM compiler
>>> also had a very good reputation, but it had a lot less extensions to the
>>> standard.
>>
>>
>> on S/390 or RS/6000?
>
>
> Mainframe.
Given how long mainframes existed at that time
(20+ years, compared to 10+ years for VAX)
this supports the notion that software quality
mainly depends on the time the respective
software is on the market, rather than
supernatural abilities of its developers.
Michael Kraemer
> From http://en.wikipedia.org/wiki/COBOL :
>
> "In 1997, the Gartner Group reported
(...)
aren't we told in this group that
the Gartner guys are the bad boys,
mainly because they (correctly) predicted
the demise of VMS?
So this time they are more credible?
Phillip Helbig---undress to reply
herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> Phillip Helbig---undress to reply <hel...@astro.multiclothesvax.de> wrote:
>
> > Definitely. Fortran is also still in use at a lot of places, though
> > many people wrongly think of it as old-fashioned.
>
> So, when will we see a Fortran 2008 compiler for VMS?
> (I believe there is work on another, maybe 2013, standard.)
Well, let's not jump the gun. First, a standard is published then
compilers appear within the next few years (depending on how many new
features the standard demands). In a good world, we should be expecting
a Fortran2008 compiler about now. We should have had a Fortran 2003
(lots of new features) by, say, 2007 at the latest. As far as I know,
VMS is still stuck at Fortran 95.
There was a decision made to have Fortran90 only on ALPHA, not VAX. I
would have thought that at least on Itanium the newer standards would be
supported.
As part of the big staff shuffle, many (most? all?) of DEC's Fortran
people ended up at Intel.
I don't use Fortran at work and at home, now that there is no access to
patches for hobbyists, the inertia to stay with what software works well
enough for my purposes is great.
Phillip Helbig---undress to reply
=?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
> Fortran is still/now HP Fortran (and currently at
> versions 8.2 AFAIK).
What version of the Fortran standard does that support?
Jan-Erik Soderholm
If one talks about personal resources, yes.
OTOH, I don't think we'd run 100+ interactive users and 200 detached
processes if all apps where in Java on our 4GB, 666 Mhz DS20. COBOL
is still way more effective. And it is more or less the same sources
since when this runed on a 11/750.
Phillip Helbig---undress to reply
=?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
> HP Fortran claims to be fully Fortran 90 and 95 compliant.
>
> I have no reason to doubt that.
Right. The Fortran95 compiler on ALPHA is quite good.
> They do not sypport Fortran 2003 and 2008.
>
> But it is not my impression that those standards are
> completely implemented by many vendors.
2003 was a big revision, but I think there are some compilers which
implement them. Of course it's chicken and egg to some extent, but it
would be interesting to know how much these new standards are used in
the real world.
Phillip Helbig---undress to reply
<M.Kr...@gsi.de> writes:
> Phillip Helbig---undress to reply schrieb:
>
> >
> > AFAIK, you can still get a Fortran compiler for VMS, but it doesn't
> > incorporate the new standards.
>
> Incorporating the new standards would mean "being serious".
My thoughts exactly.
Phillip Helbig---undress to reply
<M.Kr...@gsi.de> writes:
> Arne Vajhøj schrieb:
>
> >
> > VAX extensions was the defacto standard.
>
> and were a p.i.t.a. because they made Fortran
> programs unportable.
Right, but one didn't have to use them. The time between 1977 and 1990
was too long.
Jan-Erik Soderholm
This was not a prediction of the future.
It was a estimation of the current state.
Jan-Erik Soderholm
F95.
Michael Kraemer
>>
>>
>>>VAX extensions was the defacto standard.
>>
>>and were a p.i.t.a. because they made Fortran
>>programs unportable.
>
>
> Right, but one didn't have to use them.
In a group of 1+ developers there's
always at least one idiot who violates
local coding standards and starts
using those extensions.
VAXman-
>Arne Vajhøj schrieb:
>
>>
>> VAX extensions was the defacto standard.
>
>programs unportable.
If VAX or VMS are/were the target, portability is/was moot.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.
Richard B. Gilbert
I'm not surprised! Fortran was intended for scientific computing/number
crunching and it gets the job done.
Bob Koehler
>
> So, being as there are opensource versions of MUMPS available and that
> VISTA is publicly available, has anyone ever given any thought to doing
> a port of MUMPS to VMS, getting VISTA running on it and offering this
> as a turnkey system, possibly to the government if they go in that
> direction but also to other hospitals?
Although MUPS is available on IBM mainframes, I'm assuming that it
is actually the same language and environment as DSM (Digital Standard
MUMPS), available on VMS. MUMPS on IBM or VAXen has a long history in
the medical profession.
Bob Koehler
>
> Just last month, and related to some postings here, I was interested in
> a job at the Veterans Administration. One of the qualifications was
> MUMPS. When I looked it up on Google, I found the code to be even older
> and worse than COBOL. I thought it was more like Postscript (?)
> in that it was still tied to the days of stacks. I think of stacks as
> being related to the earliest processors, where there was no room or
> ability to have even a handful of variables which could be referred to
> by name, such as Fortran or Basic.
OK, it's not April 1, yet. Many early processors had no built-in
stack, and on some of them emulating stacks in an interrupt safe
manner would not be easy.
Fortran did not originally assume a stack, later languages like C
certainly do.
Bob Koehler
>
> That's probably true on average,
> but it would depend on the industry sector.
> Heavy number crunchers might still consider
> Fortran for new projects, but most of the time
> it will be little more than adding new features to old code.
This depends veru much on the environment. I am surrounded by
astronomers who are quite happy working in Fortran 77.
Bob Koehler
> Phillip Helbig---undress to reply <hel...@astro.multiclothesvax.de> wrote:
>
>> Definitely. Fortran is also still in use at a lot of places, though
>> many people wrongly think of it as old-fashioned.
>
On IA64, sometime before we see a Fortran 90 compiler for VAXen, I think.
What a pain writing a quick bit of Fortran for some little thing in
my home cluster only to be painfully reminded that my VAX can't
compile it.
Bob Koehler
> Arne Vajhøj schrieb:
>
>>
>> PL/I comes from Kednos today.
>
> Outsourcing to a 3rd party means there's
> not enough business for the original vendor,
> which in turn means the language is in decline.
IIRC, Kendos was always the supplier, even when it was badged as
digital.
Bob Koehler
>
> Arne Vajhøj schrieb:
>
>
> Back in the ol' times we used a variety of RISC
> Unices (including DEC's) plus IBM mainframe.
> None of them had VAX extensions, iirc.
> At least not to the extent we could
> use them as a common denominator.
I recall the day IBM brought a bunch of AIX systems to our work
site to show how readily "VAX Fortran" ported. And I recall the
evolution of VAX Fortran extensions on HP-UX and Solaris from just
barley, to just recompile.
Bill Gunshannon
I thought the PL/I compiler for VMS (and a number of other systems)
was always a Kednos product? I actually thought they went all the
way back to PDP-11 and maybe TOPS days.
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>
Bill Gunshannon
Before people start pooh-poohing VSM for not supporting the current
staandard one should look at wether or not the user base is really
interested. I know somone who is always blaiming the demise of
COBOL (sic) on the fact that the COBOL community didn't jump on the
OO bandwagon. What would be the incentive for compiler vendors to
add features to their compilers that the user base doesn't want but
some ivroy tower standards body has proclaimed as necessary?
Bill Gunshannon
Michael Kraemer <M.Kr...@gsi.de> writes:
> Phillip Helbig---undress to reply schrieb:
>> In article <il1g08$ep9$01$1...@news.t-online.com>, Michael Kraemer
>> <M.Kr...@gsi.de> writes:
>>
>>
>>>Arne Vajh?j schrieb:
>>>
>>>
>>>>VAX extensions was the defacto standard.
>>>
>>>and were a p.i.t.a. because they made Fortran
>>>programs unportable.
>>
>>
>> Right, but one didn't have to use them.
>
> In a group of 1+ developers there's
> always at least one idiot who violates
> local coding standards and starts
> using those extensions.
That's a management problem and easily fixed. :-)
Bill Gunshannon
koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <8thimq...@mid.individual.net>, billg999@.uofs.edu (Bill Gunshannon) writes:
>>
>> So, being as there are opensource versions of MUMPS available and that
>> VISTA is publicly available, has anyone ever given any thought to doing
>> a port of MUMPS to VMS, getting VISTA running on it and offering this
>> as a turnkey system, possibly to the government if they go in that
>> direction but also to other hospitals?
>
> Although MUPS is available on IBM mainframes, I'm assuming that it
> is actually the same language and environment as DSM (Digital Standard
> MUMPS),
Only in a general sense. MUMPS, like anything else int he IT world has
evolved rather a lot. and I doubt DSM would meet the ANSI Standard.
> available on VMS.
Is it still?
> MUMPS on IBM or VAXen has a long history in
> the medical profession.
Has? or Had? It is nice to look at VistA running on Cache and say "well,
Cache runs on VMS, too." But the question really is; "Is any one (to
include the VA) actually still running it on VMS Systems?
Thus the reason for my original query in this thread. Is anyone currentlly
looking at or building such a system in an effort to try to get VMS back
into this niche if the opportunity arises?
K.S. Bhaskar
> In article <il0h6i$ep...@speranza.aioe.org>,
> brendan welch <w1...@uml.edu> writes:
[KSB] <...snip...>
> > When I looked it up on Google, I found the code to be even older
> > and worse than COBOL.
>
> Some of us don't consider COBOL to be at all bad. :-) As for MUMPS,
> I read an thread in another newsgroup recently where someone posted
> an example of his code, and it was truly terrible. Deliberatly
> obtuse, one character variables, one character command abbreviations.
> Anyone seeing this would be bound to shudder. But then, his later
> statement explains it all. Job security!! I thought those days were
> long gone and that most places had programming standards. I kinow the
> VA does.
[KSB] So the point is that it is possible to write unreadable code in
any language? Or that code written twenty years ago may be written to
different coding standards than code written today?
The Wikipedia page on MUMPS (https://secure.wikimedia.org/wikipedia/en/
wiki/MUMPS) includes code written in 2010 and code written in the
1970s and last edited in 1982.
Incidentally, COBOL is much older than MUMPS. MUMPS, SQL, C (or at
least its predecessor B) and the UNIX shell all have origins circa
1970.
> > I thought it was more like Postscript (?)
> > in that it was still tied to the days of stacks. I think of stacks as
> > being related to the earliest processors, where there was no room or
> > ability to have even a handful of variables which could be referred to
> > by name, such as Fortran or Basic.
>
> It made me think much more of SNOBOL or SPITBOL.
[KSB] MUMPS is no more stack oriented than C, but does have many
features in common with SNOBOL4 (and with JavaScript & PHP for that
matter). Forth is stack oriented, and is very different (I managed a
Forth implementation in a prior life).
> > About 20 years ago, when I was working at a state-sponsored university
> > (i.e., considered a place where employees seldom left) one of my
> > co-workers had previous experience on MUMPS and was now working on VMS.
> > A job opportunity arose in the "outside" world, apparently MUMPS on VMS,
> > which was just so lucrative, that he abandoned his university job and
> > took the MUMPS one.
>
> I would leave here in a heartbeat for a job doing MUMPS on VMS!!
> Even faster for COBOL. :-)
[KSB] The job market for those knowledgeable in VistA currently
appears to have more openings than talent. But that's not really
about MUMPS programming per se - it's more about a complex ERP system
that requires knowledge about the application domain as well as the
culture of the application.
Disclosure: I manage GT.M (http://fis-gtm.com) the implementation of
which on OpenVMS on Alpha/AXP is free / open source software.
Regards
-- Bhaskar (yes, it's my last name, but that's what I'm called)
ks dot bhaskar at fisglobal dot com <-- send e-mail here
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
> bill
>
> --
> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
> billg...@cs.scranton.edu | and a sheep voting on what's for dinner.
Bill Gunshannon
"K.S. Bhaskar" <ksbh...@gmail.com> writes:
> On Mar 6, 1:06 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
>> In article <il0h6i$ep...@speranza.aioe.org>,
>> brendan welch <w1...@uml.edu> writes:
> [KSB] <...snip...>
>> > When I looked it up on Google, I found the code to be even older
>> > and worse than COBOL.
>>
>> Some of us don't consider COBOL to be at all bad. :-) As for MUMPS,
>> I read an thread in another newsgroup recently where someone posted
>> an example of his code, and it was truly terrible. Deliberatly
>> obtuse, one character variables, one character command abbreviations.
>> Anyone seeing this would be bound to shudder. But then, his later
>> statement explains it all. Job security!! I thought those days were
>> long gone and that most places had programming standards. I kinow the
>> VA does.
> [KSB] So the point is that it is possible to write unreadable code in
> any language?
No, the point is that if you see a badly written peice of code it
doesn't mean all code written in thaqt language needs to be like that.
> Or that code written twenty years ago may be written to
> different coding standards than code written today?
Again, not really. Let's go back a bit further, say 30 years. It
was a fairly common practice for programmers to write deliberately
obfuscated code in a mis-guided effort to increase their apparent
value to the company. Even companies did it (McDonnell Douglas
held a lucrative government contract captive for years by using
routines registered as trade secrets external to the contract in
a System they had been contracted for by The Corps of Engineers!)
> The Wikipedia page on MUMPS (https://secure.wikimedia.org/wikipedia/en/
> wiki/MUMPS) includes code written in 2010 and code written in the
> 1970s and last edited in 1982.
> Incidentally, COBOL is much older than MUMPS. MUMPS, SQL, C (or at
> least its predecessor B) and the UNIX shell all have origins circa
> 1970.
Actually, MUMPS, under that name, dates to 1966 and earlier under its
original names.
>> > I thought it was more like Postscript (?)
>> > in that it was still tied to the days of stacks. I think of stacks as
>> > being related to the earliest processors, where there was no room or
>> > ability to have even a handful of variables which could be referred to
>> > by name, such as Fortran or Basic.
>>
>> It made me think much more of SNOBOL or SPITBOL.
> [KSB] MUMPS is no more stack oriented than C, but does have many
> features in common with SNOBOL4 (and with JavaScript & PHP for that
> matter). Forth is stack oriented, and is very different (I managed a
> Forth implementation in a prior life).
As one who has also done some work in Forth, You have my sympathies!! :-)
>> > About 20 years ago, when I was working at a state-sponsored university
>> > (i.e., considered a place where employees seldom left) one of my
>> > co-workers had previous experience on MUMPS and was now working on VMS.
>> > A job opportunity arose in the "outside" world, apparently MUMPS on VMS,
>> > which was just so lucrative, that he abandoned his university job and
>> > took the MUMPS one.
>>
>> I would leave here in a heartbeat for a job doing MUMPS on VMS!!
>> Even faster for COBOL. :-)
> [KSB] The job market for those knowledgeable in VistA currently
> appears to have more openings than talent. But that's not really
> about MUMPS programming per se - it's more about a complex ERP system
> that requires knowledge about the application domain as well as the
> culture of the application.
> Disclosure: I manage GT.M (http://fis-gtm.com) the implementation of
> which on OpenVMS on Alpha/AXP is free / open source software.
> Regards
> -- Bhaskar (yes, it's my last name, but that's what I'm called)
> ks dot bhaskar at fisglobal dot com <-- send e-mail here
> --
> GT.M - Rock solid. Lightning fast. Secure. No compromises.
And I plan to have a system up and running soon so I can get my feet
wet again. But at this stage in my career I see little liklihood of
this going anywhere beyond having a lot of fun. But I do think there
are opportunities coming up with the proposed merger of VistA and AHLTA.
The question is who will be there to take advantage of them.
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.
Phillip Helbig---undress to reply
koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <il18im$i14$1...@news.eternal-september.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> > Phillip Helbig---undress to reply <hel...@astro.multiclothesvax.de> wrote:
> >
> >> Definitely. Fortran is also still in use at a lot of places, though
> >> many people wrongly think of it as old-fashioned.
> >
> > So, when will we see a Fortran 2008 compiler for VMS?
>
> On IA64, sometime before we see a Fortran 90 compiler for VAXen, I think.
Do you really have any evidence that VMS will, on any hardware (in
practice: Itanium) ever support a Fortran standard later than F95?
glen herrmannsfeldt
(snip)
> OK, it's not April 1, yet. Many early processors had no built-in
> stack, and on some of them emulating stacks in an interrupt safe
> manner would not be easy.
S/360 and S/370 don't have a stack. ESA/390 has PC, which is a
little bit like a stack.
> Fortran did not originally assume a stack, later languages like C
> certainly do.
Well, C doesn't require a physical stack, but it does require some
type of last-in-first-out data structure. For S/370 that is
commonly done as a linked list instead of a physical stack.
(Convenient in that you don't need to know the maximum depth
when you start.)
-- glen
JF Mezei
> OK, it's not April 1, yet. Many early processors had no built-in
> stack, and on some of them emulating stacks in an interrupt safe
> manner would not be easy.
OK, I gotta ask this. Pardon my newbieness.
I learned CPU architecture based on IBM 360/370. It had 16 integer
registers (or was it 14 ?) if I remember correctly. And some floating
point one. Those were 16 physical storage areas. The number of bits
allocated for register specification within the architecture was 4 which
meant that you couldn't add more registers.
There was no "stack" in the architecture.
I never really learned VAX architecture/assembler (mea culpa).
I can understand how a stack can be implemented by a compiler or
application.
How is it implemented in hardware ?
Is this just a set of fixed registers that contain a base address for a
stack, and the location of the last entry, with all entries assumed to
be 4 bytes, so stack operations just increment or decrement that second
pointer ? How does the hardware know where to place the stack and how
big it is to be ?
Also, on the IBM mainframe, registers were physical entities on the
chip. Are registers these days virtualised and mapped to cache memory or
even real memory ?
Just curious on how they can add registers to an architecture of the
number of bits reserved for register specification within binary
instructions don't allow for a greater range of registers.
Jan-Erik Soderholm
> I can understand how a stack can be implemented by a compiler or
> application.
>
> How is it implemented in hardware ?
I had a lot written about this, but then did what you *should* have
done in the first place, asked Google.
Michael Kraemer
>
> I learned CPU architecture based on IBM 360/370. It had 16 integer
> registers (or was it 14 ?)
16, but some of them you better don't touch.
By convention R14/R15 are used for subroutine linkage (BALR 14,15)
> if I remember correctly. And some floating
> point one.
four.
> Those were 16 physical storage areas. The number of bits
> allocated for register specification within the architecture was 4 which
> meant that you couldn't add more registers.
>
> There was no "stack" in the architecture.
>
> I never really learned VAX architecture/assembler (mea culpa).
>
> I can understand how a stack can be implemented by a compiler or
> application.
>
> How is it implemented in hardware ?
It isn't (at least in my understanding).
There's nothing magic about a stack,
it's just a piece of RAM "big enough"
to hold register save areas and variables
of "automatic" (PL/I speak) storage class.
Some architectures have a dedicated "holy"
register (e.g. 68K A7/A7') pointing to the next free location.
By convention S/370 uses R13 for that purpose,
but it lacks auto increment/decrement.
Jan-Erik Soderholm
> JF Mezei schrieb:
>
>>
>> I learned CPU architecture based on IBM 360/370. It had 16 integer
>> registers (or was it 14 ?)
>
> 16, but some of them you better don't touch.
> By convention R14/R15 are used for subroutine linkage (BALR 14,15)
>
>> if I remember correctly. And some floating
>> point one.
>
> four.
>
>> Those were 16 physical storage areas. The number of bits
>> allocated for register specification within the architecture was 4 which
>> meant that you couldn't add more registers.
>>
>> There was no "stack" in the architecture.
>>
>> I never really learned VAX architecture/assembler (mea culpa).
>>
>> I can understand how a stack can be implemented by a compiler or
>> application.
>>
>> How is it implemented in hardware ?
>
> It isn't (at least in my understanding).
Highly depending in the architecure.
On an architecure with a fixed hardware based stack,
it is of course implemented in pure hardware. No software
and no RAM involved.
> There's nothing magic about a stack,
> it's just a piece of RAM "big enough"
Can be. *Usualy* is. Doesn't *have* to be.
JF Mezei
> Highly depending in the architecure.
> On an architecure with a fixed hardware based stack,
> it is of course implemented in pure hardware. No software
> and no RAM involved.
In the case of VAX (does Alpha have stacks ?), is the memory used to
store the stack embedded into the CPU chip and fixed in size ? What
happens when you push too many items onto the stack ?
On a IBM mainframe, when a subroutine is called, the registers of the
caller are saved, and restored when the subroutine returns. This way,
the subroutine is free to modify registers as it wants (but has to abide
by the subroutine calling standards).
Does this means that on architectures that have a hardware stack, the
stack is saved the same way and restored to its previous status after
the subroutine returns ?
Isn't it simpler to have a stack that fully resides in virtual memory so
that in context switches, the stack need not be copied to a safe place
and restored later on ?
I am used to stacks at much higher levels (for instance Postscript where
each stack item can be a totally different object or different size).
Just wondering what the advantage was/is to have stacks implenmented in
the architecture/hardware.
Rich Alderson
> I thought the PL/I compiler for VMS (and a number of other systems)
> was always a Kednos product? I actually thought they went all the
> way back to PDP-11 and maybe TOPS days.
There was never a PL/I for the 36-bit line, or I'd never have learned Pascal.
(My first decade as a programmer was strictly IBM oriented, and I was really
good at PL/I programming.)
--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
Jan-Erik Soderholm
> Jan-Erik Soderholm wrote:
>
>> Highly depending in the architecure.
>> On an architecure with a fixed hardware based stack,
>> it is of course implemented in pure hardware. No software
>> and no RAM involved.
>
>
> In the case of VAX (does Alpha have stacks ?), is the memory used to
> store the stack embedded into the CPU chip and fixed in size ? What
> happens when you push too many items onto the stack ?
Most (all) larger architecures always implement the stack as a part
of the available memory (RAM) and pointed to by the "stack pointer".
And "larger" is anything from most 8-bit processor and up.
Some 8-bit single-chip microcontrolers like the Microchip PIC has
a true hardware stack.
>
> On a IBM mainframe, when a subroutine is called, the registers of the
> caller are saved, and restored when the subroutine returns. This way,
> the subroutine is free to modify registers as it wants (but has to abide
> by the subroutine calling standards).
>
> Does this means that on architectures that have a hardware stack, the
> stack is saved the same way and restored to its previous status after
> the subroutine returns ?
Not rellevant. See above.
>
> Isn't it simpler to have a stack that fully resides in virtual memory so
> that in context switches, the stack need not be copied to a safe place
> and restored later on ?
You usualy need severel different stacks. A user stack that is mapped into
your user/process address space. And then a kernel stack used by the
kernel to handle interrupts and so on.
>
>
> I am used to stacks at much higher levels (for instance Postscript where
> each stack item can be a totally different object or different size).
> Just wondering what the advantage was/is to have stacks implenmented in
> the architecture/hardware.
>
A whole other meaning of "stack".
>
Rich Alderson
> I can understand how a stack can be implemented by a compiler or
> application.
> How is it implemented in hardware ?
> Is this just a set of fixed registers that contain a base address for a
> stack, and the location of the last entry, with all entries assumed to
> be 4 bytes, so stack operations just increment or decrement that second
> pointer ? How does the hardware know where to place the stack and how
> big it is to be ?
Your architecture bias is showing.
On the PDP-10, any of the 16 accumulators ("registers") can function as a stack
pointer; the convention in most programs (the Tops-10 monitor is a notable
exception) is to use AC 17.
The programmer initializes the stack pointer with a length and initial address
(in 18-bit address mode; 30-bit addressing adds wrinkles not germane to this
discussion):
move 17,[-100,,pdl] ;where elsewhere you'll find PDL: BLOCK 100
There are 5 instructions which deal directly with the stack: PUSH and POP are
data oriented, PUSHJ and POPJ are subroutine call and return, and ADJSP is a
fast instruction to ADJust the Stack Pointer.
pushj 17,subrtn ;call silly subroutine
jrst failur
succes: haltf%
.
.
.
subrtn: skipge 17 ;is the SP negative?
aos (17) ;yes, skip-return for success
popj 17, ;return from subroutine
The hardware interrupts the program if the stack pointer overflows.
Note the nifty feature of being able to change the return address from within
the subroutine, which is used as a common idiom in PDP-10 programming. The
usual pattern is to have the first instruction after a subroutine call branch
to an error handling routine, and the successful completion of the subroutine
goes to the second instruction after the call.
A program can use multiple stacks with multiple stack pointers, since any AC
can function as an SP (unlike, for example, the 680x0).
Richard B. Gilbert
> Jan-Erik Soderholm wrote:
>
>> Highly depending in the architecure.
>> On an architecure with a fixed hardware based stack,
>> it is of course implemented in pure hardware. No software
>> and no RAM involved.
>
>
> In the case of VAX (does Alpha have stacks ?), is the memory used to
> store the stack embedded into the CPU chip and fixed in size ? What
> happens when you push too many items onto the stack ?
It's called "stack overflow". Depending on the hardware and O/S you get
some sort of signal that tells you that you have violated the rules and
tried to store to memory that does not belong to you.
You can also run into trouble by trying to pop more from the stack than
you pushed
onto the stack. It's called stack underflow.
Of course *I* never did anything like that! ;-)
glen herrmannsfeldt
> Bob Koehler wrote:
>> OK, it's not April 1, yet. Many early processors had no built-in
>> stack, and on some of them emulating stacks in an interrupt safe
>> manner would not be easy.
> OK, I gotta ask this. Pardon my newbieness.
> I learned CPU architecture based on IBM 360/370. It had 16 integer
> registers (or was it 14 ?) if I remember correctly. And some floating
> point one. Those were 16 physical storage areas. The number of bits
> allocated for register specification within the architecture was 4 which
> meant that you couldn't add more registers.
> There was no "stack" in the architecture.
> I never really learned VAX architecture/assembler (mea culpa).
> I can understand how a stack can be implemented by a compiler or
> application.
> How is it implemented in hardware ?
When discussing stacks, there are two kinds of machines to consider:
Stack machines like the B5500 or (mostly) the x87 floating point unit.
Machines that use a call stack like many DEC machines, the 8080 and
its descendants, and VAX (a PDP-11 descendant).
A true stack machine like the B5500 doesn't have addressable
registers. There is push and pop, and all operations are done between
stack registers, with the result on the stack. The tradition was
to allow the processor to keep some values in hardware registers,
and the rest in memory.
The x87 is strange, in that it allows addressing within the stack.
It was supposed to allow for a virtual stack, where a stack full
interrupt would write to memory, and stack empty would read back.
After it was built, it was found that the status bits needed for
the interrupt weren't available. It couldn't be done.
Then there are machines like the PDP-11 that use a stack for
procedure call, but registers for arithmetic operations. One can
also push onto the stack for temporary storage. The stack is
implemented through a register with a memory address, and appropriate
updating of that register. (The autoincrement and autodecremnt
modes are about what is needed.)
> Is this just a set of fixed registers that contain a base address for a
> stack, and the location of the last entry, with all entries assumed to
> be 4 bytes, so stack operations just increment or decrement that second
> pointer ? How does the hardware know where to place the stack and how
> big it is to be ?
The user (or OS) must initialize the stack pointer. How big is
always a question.
> Also, on the IBM mainframe, registers were physical entities on the
> chip. Are registers these days virtualised and mapped to cache memory or
> even real memory ?
"On the chip" isn't quite right. All of S/360 was implemented with
little ceramic blocks with transistors glued onto them. For the
low end S/360 models, I believe that the registers were in special
small and fast core memory. I believe the higher S/360 models
used such transistors for registers.
> Just curious on how they can add registers to an architecture of the
> number of bits reserved for register specification within binary
> instructions don't allow for a greater range of registers.
Well, S/360 and S/370 allow for only four floating point registers,
so extending that to 16 wasn't hard. z/Architecture extends
the S/360 32 bit registers to 64 bits, where the 32 bit instructions
use the low order bits of the bigger registers.
If you really need to do it, the registers can be bank switched,
which, for example, allows for faster interrupt processing.
-- glen
glen herrmannsfeldt
> JF Mezei schrieb:
>> I learned CPU architecture based on IBM 360/370. It had 16 integer
>> registers (or was it 14 ?)
> It isn't (at least in my understanding).
> There's nothing magic about a stack,
> it's just a piece of RAM "big enough"
> to hold register save areas and variables
> of "automatic" (PL/I speak) storage class.
> Some architectures have a dedicated "holy"
> register (e.g. 68K A7/A7') pointing to the next free location.
> By convention S/370 uses R13 for that purpose,
> but it lacks auto increment/decrement.
Well, for OS/360, and still through to MVS, the usual calling
conventions use R13 as a linked list of register save areas.
As R14 (the return address) is in the save area, that allows
for a logical return stack.
Most assembly and Fortran programs use static save areas, such
that recursion is not allowed. For recursion, the save areas
are dynamically allocated.
Otherwise, the only register that is special for S/360 hardware
is zero, which is considered to be zero when used as a base
or index register in an instruction.
-- glen
Arne Vajhøj
> Jan-Erik Soderholm wrote:
>> Highly depending in the architecure.
>> On an architecure with a fixed hardware based stack,
>> it is of course implemented in pure hardware. No software
>> and no RAM involved.
>
> In the case of VAX (does Alpha have stacks ?), is the memory used to
> store the stack embedded into the CPU chip and fixed in size ? What
> happens when you push too many items onto the stack ?
Yes - Alpha uses stack.
For user mode code it is not really a problem.
You fill up the heap from bottom and moving up.
You allocate on the stack from top moving down.
So you have almost 2 GB before the two meet.
The more privileged has limited stack sizes. Kernel mode
stack size is controlled by the SYSGEN parameter KSTACKPAGES.
Something very bad will happen if you try to push too much on the
stack.
> On a IBM mainframe, when a subroutine is called, the registers of the
> caller are saved, and restored when the subroutine returns. This way,
> the subroutine is free to modify registers as it wants (but has to abide
> by the subroutine calling standards).
So does VAX (controlled by a bit mask).
> Does this means that on architectures that have a hardware stack, the
> stack is saved the same way and restored to its previous status after
> the subroutine returns ?
>
> Isn't it simpler to have a stack that fully resides in virtual memory so
> that in context switches, the stack need not be copied to a safe place
> and restored later on ?
I would expect all the mentioned systems to use ordinary RAM for stack.
Arne
Arne Vajhøj
> I never really learned VAX architecture/assembler (mea culpa).
>
> I can understand how a stack can be implemented by a compiler or
> application.
>
> How is it implemented in hardware ?
It is just a few instructions involving the SP.
> Is this just a set of fixed registers that contain a base address for a
> stack, and the location of the last entry, with all entries assumed to
> be 4 bytes, so stack operations just increment or decrement that second
> pointer ?
That is about it.
> How does the hardware know where to place the stack and how
> big it is to be ?
It knows where to start.
It can be fixed size or just grow within the address space.
> Also, on the IBM mainframe, registers were physical entities on the
> chip. Are registers these days virtualised and mapped to cache memory or
> even real memory ?
That would be too slow.
> Just curious on how they can add registers to an architecture of the
> number of bits reserved for register specification within binary
> instructions don't allow for a greater range of registers.
Unless some space was set aside for future expansion, then they
can't.
Arne
Arne Vajhøj
> In article<il0h6i$epd$1...@speranza.aioe.org>, brendan welch<w1...@uml.edu> writes:
>> Just last month, and related to some postings here, I was interested in
>> a job at the Veterans Administration. One of the qualifications was
>> MUMPS. When I looked it up on Google, I found the code to be even older
>> and worse than COBOL. I thought it was more like Postscript (?)
>> in that it was still tied to the days of stacks. I think of stacks as
>> being related to the earliest processors, where there was no room or
>> ability to have even a handful of variables which could be referred to
>> by name, such as Fortran or Basic.
>
> stack, and on some of them emulating stacks in an interrupt safe
> manner would not be easy.
>
> certainly do.
They allow or don't allow recursion. Recursion is a lot easier with
a stack.
Languages that allows recursion has been implemented on systems
with no HW/OS stack. Probably by having some type of stack in
the runtime library of the language.
Arne
Arne Vajhøj
Is anybody looking for it?
Arne
Arne Vajhøj
> In article<4d743b60$0$23757$1472...@news.sunsite.dk>,
> =?ISO-8859-1?Q?Arne_Vajh=F8j?=<ar...@vajhoej.dk> writes:
>
>> HP Fortran claims to be fully Fortran 90 and 95 compliant.
>>
>> I have no reason to doubt that.
>
> Right. The Fortran95 compiler on ALPHA is quite good.
>
>> They do not sypport Fortran 2003 and 2008.
>>
>> But it is not my impression that those standards are
>> completely implemented by many vendors.
>
> 2003 was a big revision, but I think there are some compilers which
> implement them.
http://www.fortranplus.co.uk/resources/fortran_2003_2008_compiler_support.pdf
has a list.
> Of course it's chicken and egg to some extent, but it
> would be interesting to know how much these new standards are used in
> the real world.
I am not really following that world anymore, but I would expect
the usage of 2003/2008 features to be rather small.
Arne
Arne Vajhøj
> In article<il1g08$ep9$01$1...@news.t-online.com>, Michael Kraemer
> <M.Kr...@gsi.de> writes:
>> Arne Vajhøj schrieb:
>>> VAX extensions was the defacto standard.
>>
>> and were a p.i.t.a. because they made Fortran
>> programs unportable.
>
> was too long.
The process dragged out.
I believe 90 started as 8X.
Arne
Arne Vajhøj
> In article<4d743a13$0$23757$1472...@news.sunsite.dk>,
> =?ISO-8859-1?Q?Arne_Vajh=F8j?=<ar...@vajhoej.dk> writes:
>> Fortran is still/now HP Fortran (and currently at
>> versions 8.2 AFAIK).
>
> What version of the Fortran standard does that support?
Full 95 and some 2003/2008 features I believe.
Arne
Arne Vajhøj
> In article<il2244$kaa$2...@online.de>,
> hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:
>> In article<4d743a13$0$23757$1472...@news.sunsite.dk>,
>> =?ISO-8859-1?Q?Arne_Vajh=F8j?=<ar...@vajhoej.dk> writes:
>>
>>> Fortran is still/now HP Fortran (and currently at
>>> versions 8.2 AFAIK).
>>
>> What version of the Fortran standard does that support?
>
> Before people start pooh-poohing VSM for not supporting the current
> staandard one should look at wether or not the user base is really
> interested. I know somone who is always blaiming the demise of
> COBOL (sic) on the fact that the COBOL community didn't jump on the
> OO bandwagon. What would be the incentive for compiler vendors to
> add features to their compilers that the user base doesn't want but
> some ivroy tower standards body has proclaimed as necessary?
COBOL did jump on OO.
COBOL 2002 is supposedly OO.
I am pretty sure that most COBOL compilers and COBOL
code being written is only COBOL 74 or 85.
Which actually illustrated your main point!
Arne
glen herrmannsfeldt
(snip, someone wrote)
>> What version of the Fortran standard does that support?
> Full 95 and some 2003/2008 features I believe.
OK, not so bad. Very few compilers now have all of 2003, and
many of those are starting to add easier 2008 features.
-- glen
glen herrmannsfeldt
(snip)
> I believe 90 started as 8X.
After 66 and 77, I was hoping for 88. I do have the book
"Fortran 8x explained." I suppose if you agree with apple
that x is 10, then it is about right.
-- glen
Richard B. Gilbert
If HP thinks it can make money by offering a Fortran later than F95 for
VMS, it will probably do so. If H-P does not offer an up-to-date
Fortran compiler, it's certainly possible for some third party to do so.
If such a venture looks as if it will make a profit, someone will
undertake it.
No money, no software!!!!
glen herrmannsfeldt
(snip, someone wrote)
>> In the case of VAX (does Alpha have stacks ?), is the memory used to
>> store the stack embedded into the CPU chip and fixed in size ? What
>> happens when you push too many items onto the stack ?
> Yes - Alpha uses stack.
> For user mode code it is not really a problem.
> You fill up the heap from bottom and moving up.
> You allocate on the stack from top moving down.
> So you have almost 2 GB before the two meet.
For a 64 bit address, shouldn't it be more than that?
(snip)
>> On a IBM mainframe, when a subroutine is called, the registers of the
>> caller are saved, and restored when the subroutine returns. This way,
>> the subroutine is free to modify registers as it wants (but has to abide
>> by the subroutine calling standards).
The called routine only needs to save the registers that it will use.
Using STM (store multiple) it isn't hard to save only some.
> So does VAX (controlled by a bit mask).
>> Does this means that on architectures that have a hardware stack, the
>> stack is saved the same way and restored to its previous status after
>> the subroutine returns ?
The usual way is that the stack isn't saved, but each routine gets
to store into the same stack. On many, there is a separate stack
for interrupts and other system functions.
>> Isn't it simpler to have a stack that fully resides in virtual memory so
>> that in context switches, the stack need not be copied to a safe place
>> and restored later on ?
> I would expect all the mentioned systems to use ordinary RAM for stack.
Well, on most processors "ordinary RAM" is cached, and one hopes
that stack data mostly stay in the cache. (With write-back cache.)
-- glen
glen herrmannsfeldt
(snip)
>> Fortran did not originally assume a stack, later languages like C
>> certainly do.
> They allow or don't allow recursion. Recursion is a lot easier with
> a stack.
Fortran didn't allow recursion until Fortran 90, and even so
you have to use the RECURSIVE attribute. Without the attribute,
local variables may be static or automatic.
> Languages that allows recursion has been implemented on systems
> with no HW/OS stack. Probably by having some type of stack in
> the runtime library of the language.
For OS/360 and successors, usually a linked list. GETMAIN (
the system memory allocation routine) is usually considered too
slow, so the library allocates a larger region, and then parcels
it out as needed. Logically it is a doubly linked list.
In PL/I, you can do an interprocedure GOTO (using a LABEL variable),
(about like the C longjmp), which has to release the frames as
it goes. Maybe not quite as easy as with a stack, but not so
hard to do.
-- glen
Arne Vajhøj
> Arne Vajhøj<ar...@vajhoej.dk> wrote:
>
> (snip, someone wrote)
>>> In the case of VAX (does Alpha have stacks ?), is the memory used to
>>> store the stack embedded into the CPU chip and fixed in size ? What
>>> happens when you push too many items onto the stack ?
>
>> Yes - Alpha uses stack.
>
>> For user mode code it is not really a problem.
>
>> You fill up the heap from bottom and moving up.
>
>> You allocate on the stack from top moving down.
>
>> So you have almost 2 GB before the two meet.
>
> For a 64 bit address, shouldn't it be more than that?
As I remember the memory layout then stack is in P1
and P1 has the 33 high bits as zero while P2 is where
the big space is.
That is for Alpha - I don't know about I64.
>>> Isn't it simpler to have a stack that fully resides in virtual memory so
>>> that in context switches, the stack need not be copied to a safe place
>>> and restored later on ?
>
>> I would expect all the mentioned systems to use ordinary RAM for stack.
>
> Well, on most processors "ordinary RAM" is cached, and one hopes
> that stack data mostly stay in the cache. (With write-back cache.)
True.
Arne
Arne Vajhøj
> Arne Vajhøj<ar...@vajhoej.dk> wrote:
>
> (snip)
>>> Fortran did not originally assume a stack, later languages like C
>>> certainly do.
>
>> They allow or don't allow recursion. Recursion is a lot easier with
>> a stack.
>
> Fortran didn't allow recursion until Fortran 90, and even so
> you have to use the RECURSIVE attribute. Without the attribute,
> local variables may be static or automatic.
Yes.
But I believe that VMS Fortran supported /RECURSIVE for F77.
Arne
Arne Vajhøj
> In article<il1g08$ep9$01$1...@news.t-online.com>, Michael Kraemer<M.Kr...@gsi.de> writes:
>> Arne Vajhøj schrieb:
>>> VAX extensions was the defacto standard.
>>
>> and were a p.i.t.a. because they made Fortran
>> programs unportable.
>
VAX extensions was not natural tied to VAX or VMS - it was
just some useful extensions invented by DEC.
Arne
Hans Vlems
wrote:
> JF Mezei wrote 2011-03-07 21:44:
>
> > I can understand how a stack can be implemented by a compiler or
> > application.
>
> > How is it implemented in hardware ?
>
> done in the first place, asked Google.
>
> http://en.wikipedia.org/wiki/Stack_%28data_structure%29
Burroughs built stack machines, google for the B5000, B5500, B6700
etc. and you'll find several references.
There's a book by Organick which explains the architecture quite
nicely.
The architecture is still commercially available (now from Unisys)
though the MCP runs on an emulator.
Hans
Hans Vlems
Neither VAX nor Alpha are stack machines. Both are register
architectures.
The VAX, like the PDP-11, has a register called the SP and is
incremented accordingly.
Hans
glen herrmannsfeldt
(snip)
> Burroughs built stack machines, google for the B5000, B5500, B6700
> etc. and you'll find several references.
> There's a book by Organick which explains the architecture quite
> nicely.
The B5500 was the first computer I ever used, though it
was sold soon after. I even still remember my first program.
Using the triangle inequality, it read in three side lengths,
and indicated if they were, or were not, a triangle.
Then it wasn't until the end of 8th grade that I started on Fortran.
-- glen
Bob Koehler
>
> Do you really have any evidence that VMS will, on any hardware (in
> practice: Itanium) ever support a Fortran standard later than F95?
Sadly, no.
Bob Koehler
> How is it implemented in hardware ?
Atomic push and pop instrutions are a good starting place. On VAX,
one of the "general purpose" registers is the stack pointer (SP).
You can manipulate the stack pointer directly, but instructions like
push, pop, callx, ret, ..., all assume that the SP is pointing to
the top of the stack and all will modify that register in addition to
the other things they do.
On VAXen, changing mode or fielding an interrupt can force a change
of stacks, so the mode change instructions and interrupt mechanism
are changing the content of SP.
On Alpha, the stack pointer is integer register R30. It is used in
a similar manner.
On 80386, it's known as the ESP in 32 bit mode, or SP in 16 bit mode.
And PDP-11 has an SP, too. Lots of processors do.
>
> Also, on the IBM mainframe, registers were physical entities on the
> chip. Are registers these days virtualised and mapped to cache memory or
> even real memory ?
That depends on the architecture and the implementation. On PDP-10,
there are instructions that take an accumulator as the stack pointer,
but accumulators act like memory, not registers, in many ways. In
practice programmers generally treated accumulators like registers,
and they are referenced so often that you can at least assume they are
in CPU local cache even if they are implemented as memory.
On PDP-11, the architecture was set up so that registers were
locations in the CPU, but on the 11/34 there were actuall bus
addresses where register contents could be accessed from the front
panel.
By contrast, we can go back to processors like PDP-1 through PDP-8,
which tended not to have instructions like push, pop, ..., or a
SP register. And just to show there are no real naming conventions,
"the accumulator" was the most frequently used register.
Bob Koehler
Wow, an actual technical discussion on c.o.v.!
>
> In the case of VAX (does Alpha have stacks ?), is the memory used to
> store the stack embedded into the CPU chip and fixed in size ? What
> happens when you push too many items onto the stack ?
VAX and Alpha both have stacks. The memory allocated by VMS starts
somewhere in P1 space and grows downward in addresses until P1 space
runs out. How much space can actually be mapped depends mostly on
SYSGEN parameters.
The stack grows downward because push causes the SP register to end up
with a smaller value and pop causes it to get bigger again. So the
stack is implemented upside down. This is actually very common
accross many different CPU architectures.
> On a IBM mainframe, when a subroutine is called, the registers of the
> caller are saved, and restored when the subroutine returns. This way,
> the subroutine is free to modify registers as it wants (but has to abide
> by the subroutine calling standards).
>
> Does this means that on architectures that have a hardware stack, the
> stack is saved the same way and restored to its previous status after
> the subroutine returns ?
Typically on stack based architecures, the stack is the place things
are saved, including the prior contents of the stack pointer.
> Isn't it simpler to have a stack that fully resides in virtual memory so
> that in context switches, the stack need not be copied to a safe place
> and restored later on ?
Depending on architecture, each task or process tends to have it's
own stack, the OS kernel has at least one of its own, and context
changes occcur by both changing the value of the stack pointer and
changing memory maps.
Advantages to having a hardware stack implementation include
simplicity and speed in implementing push and pop and related
instructions, and atomicity of those instructions so that they are
safe to use in contenxts that might get interrupted.
Bob Koehler
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
> (snip)
>
>
> "Fortran 8x explained." I suppose if you agree with apple
> that x is 10, then it is about right.
Since 77 didn't get standardized until 8x, that's hardly suprising.
(I can't remmeber was x 0 or 1?)
As soon as 77 did come out I had vendors adding extensions and
promising they'd be part of "FORTRAN 82". I didn't hold my breath.
Most of those additions never made it into an ANSI standard, and
many of them can not be compiled on any system currently being
sold.
And with PARAMETER, DEC learned how important it was that the
standard be different from thier extension. Until ANSI decided
to have () in the PARAMETER statement syntax, DEC was facing lots of
broken code since thier parameters assumed the data type of the
constant and ANSI's were typed using the same rules as variables.
Those () make it possible for a compiler to recognize the difference.
Bob Koehler
>
> In PL/I, you can do an interprocedure GOTO (using a LABEL variable),
> (about like the C longjmp), which has to release the frames as
> it goes. Maybe not quite as easy as with a stack, but not so
> hard to do.
I've never tried it, but according to the experts I was learning
from, some IBM 360 Fortran compilers implemented assigned GOTO
by storing and jumping to the full 32 bit address. You could
put the assigned variable in a common block, and GOTO it from
a different routine.
Not promised by the Fortran standards, and not in any way portable.
The VAX compiler implemented assigned GOTO by storing the offset
from the start of the routine, and if you tried the teick above
you could end up in the middle of some instruction, in the routine
that did the GOTO.