Most impressive VAX installations

In article <00A82051.B459084E@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:[color=blue]
>
> BINGO! There still are sites that have not bothered to port their apps to
> Alpha or Itanium. If H-float is needed, I'd wager that a library could be
> developed to provide it and, on faster hardware, it may even best perform-
> ance on VAX.[/color]

Did any Alpha ever actually implement X-float? It was in my early
Alpha architecture books, fully desribed, but documented as not
implemented.

Does Itanium do X-float?

There were calculations we did on our almighty MV II that were
trivial to code up because the Fortran compiler fully supported
H-float.

In article <490e0d30$0$90272$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:[color=blue]
>
> If I remember correctly then only VAX 7xx, 8xxx and 9xxx implemented
> H-floating in HW.[/color]

VAX 11/780 implemented H-float (and G-float) only in optional
microcode. I once had 300,000 lines of code compiled with G float
and trapping to the emulator just to get some result comparisons
with D-float (which was in the FP780).

In article <wpmdnRePQ9wSiJPUnZ2dnUVZ_tHinZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:[color=blue]
>
> Funny! I do word processing on a PC with ONLY 1 GB of RAM and only 40
> GB of disk! I don't recall how much "Level X" cache it has; If anyone
> cares, it's an HP DC5750 with W/XP SP2.[/color]

And I recall getting a Mac with a 603e chip. The 603e was designed
for laptops but had a major performance problem. So it only shipped
On desktops where the problem was solved with a big primary cache.
My system shipped with 8MB RAM and 4MB cache.

But it still ran faster than the models my friends ordered with the
previous chip so they could avoid the 603e performance problem.

In article <wpmdnRaPQ9zZi5PUnZ2dnUVZ_tHinZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:[color=blue]
>
> Did you drop an "x" up there? VAX 7xx???? I hope you meant 7000
> because the 700 series VAXen did not have H-floating point![/color]

The 11/780 did, as an option. You had to buy both an optional user
writeable control store, and the optional microcode to be loaded into
it. I remember doing testing on my second 11/780 to see if it was
worth it.

IIRC, the 11/782 and 11/785 had the same options. I think the 11/750
shipped with the H- and G-float microcode, but I don't recall how
it was handled on the 11/730 and 11/725.

In article <LqKdncVRP7voj5PUnZ2dnUVZ_srinZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:[color=blue]
>
> DEC could not, or would not, sell anything cheaply! That's one of the
> many reasons DEC is no more; their competitors could and did sell things
> cheaper than DEC did.[/color]

Yeah, right. Just go back the the 1960s and 1970s and compare prices
between any DEC PDP-x and IBM 360 series.

IBM was not into competing with DEC desktop PDP-8. Granted, the
PDP-8 took the whole desktop.

In article <mlhF2UsI0AG5@eisner.encompasserve.org>, [email]koehler@eisner.nospam.encompasserve.org[/email] (Bob Koehler) writes:[color=blue]
>
> Since the 11/780 had a 30 bit backplane and following systems were
> 20 bit or smaller, most VAXen can't handle more than 30 bits worth
> of RAM.[/color]

Typo. That should read "30 bit or smaller".

Neil Rieck wrote:[color=blue]
> On Oct 31, 8:15 pm, "Richard B. Gilbert" <rgilber...@comcast.net>
> wrote:[color=green]
>> urbancamo wrote:[color=darkred]
>>> To anyone listening!
>>> I was flicking through the VAX Architecture Reference Manual earlier
>>> and it got me wondering about the ratio between physically installed
>>> memory in a VAX setup and the maximum theoretical limit of 4 GB. As
>>> far as I'm aware for VAXen the physical never to close to the virtual.
>>> I remember when 64MB was an astronomic amount of memory, which was
>>> around the time of the last VAXes, so I'm asking - how much RAM did
>>> you see crammed into the latest or greatest of the VAXen (and what
>>> else was interesting about the setups, for example maximum number of
>>> users, storage etc)
>>> Or just tell me to get a life ;)
>>> Mark.[/color]
>> I don't know of ANY VAX that actually supported four GB of memory. I
>> don't recall the largest VAX memory I ever encountered but I doubt if it
>> was more than 128 MB.
>>
>> RISC processors, such as the Alpha need a great deal more memory for the
>> executable code, about four times as much as a VAX. With the Alphas, a
>> GB or more was not only reasonable but also possible! But only if you
>> were very rich! ;-)- Hide quoted text -
>>
>> - Show quoted text -[/color]
>
> We are currently running 3 GB of memory in our AS-DS20e. IIRC, each
> gig was $700 which seemed reasonable at the time. One unexpected
> surprise is that most of our RMS database is cached in memory.
>[/color]

RAM is a LOT cheaper these days! In the days I was writing about, RAM
was anything but cheap; especially if you bought it from DEC.

On Mon, 3 Nov 2008 12:49:02 UTC, [email]johnwallace4@yahoo.co.uk[/email] wrote:
[color=blue]
> Rainbows came out at a time when it wasn't obvious whether CPM or
> MSDOS was the way forward, and when CPM had a relatively reasonable
> installed base. Rainbows had a Z80 for CPM and an x86 (well, 8088) for
> MSDOS. Flexibility? Investment protection?
>
> Iirc, PC clones only did MSDOS and not CPM (no Linux back then, though
> there would soon be Venix/x86 as well as Venix/11 etc). And thus began
> the never-ending PC upgrade-and-discard cycles we all know (and which
> some folks love).[/color]

PCs and PC clones could (and did) run CP/M-86. So, I guess, could the
Rainbow. But the Z80 ran CP/M (the 8 bit version), so that was really as
a migration path rather than an alternative. A transparent one, too.

If CP/M-86 had taken off, it would have 'just run'.

At a time when many people bypassed DOS and used BIOS calls (as they had
to on the PC), the incompatible BIOS of the Rainbow was a major
drawback. Of course, the hardware was *completely* different!

"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message[color=blue]
> Did any Alpha ever actually implement X-float? It was in my early
> Alpha architecture books, fully desribed, but documented as not
> implemented.[/color]

The Alpha books describe the format of X-floating. There was never any
intention of adding instructions to manipulate them that I can remember.
They are completely implemented in software (mostly written in Macro-64).
[color=blue]
>
> Does Itanium do X-float?[/color]

Also in software (Macro-64 parts reimplemented in Itanium assembly).


John

Bob Koehler wrote:[color=blue]
> In article <wpmdnRaPQ9zZi5PUnZ2dnUVZ_tHinZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:[color=green]
>> Did you drop an "x" up there? VAX 7xx???? I hope you meant 7000
>> because the 700 series VAXen did not have H-floating point![/color]
>
> The 11/780 did, as an option. You had to buy both an optional user
> writeable control store, and the optional microcode to be loaded into
> it. I remember doing testing on my second 11/780 to see if it was
> worth it.
>
> IIRC, the 11/782 and 11/785 had the same options. I think the 11/750
> shipped with the H- and G-float microcode, but I don't recall how
> it was handled on the 11/730 and 11/725.
>[/color]

My first VAX was an 11/750. I do not recall it having H-floating point.
IIRC it had 32 bit and 64 bit floating point data types and
instructions. I was just massively relieved not to have to deal with
sixteen or eighteen bit address spaces any longer and didn't get really
excited about the floating point since nothing we were doing really
needed more than 32 bits.

Bob Koehler wrote:[color=blue]
> In article <LqKdncVRP7voj5PUnZ2dnUVZ_srinZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:[color=green]
>> DEC could not, or would not, sell anything cheaply! That's one of the
>> many reasons DEC is no more; their competitors could and did sell things
>> cheaper than DEC did.[/color]
>
> Yeah, right. Just go back the the 1960s and 1970s and compare prices
> between any DEC PDP-x and IBM 360 series.
>
> IBM was not into competing with DEC desktop PDP-8. Granted, the
> PDP-8 took the whole desktop.
>[/color]

My VAX experience dates from early 1984! Before that, my DEC experience
was limited to having seen and touched a PDP-8. I didn't administer or
program the PDP-8.

By 1984 DEC was charging top dollar for just about everything. Even
with a 50% educational discount, their prices were out of sight!

Somehow I don't think that the PDP-8 was comparable, in any way, to the
IBM System/360! They were both digital computers and there the
resemblance ended.

The most impressive VAXcluster I've seen was one I had some
responsibility for. 6 VAXes, over 3,300 simultaneous users running
All-in-1, RDB, and a bunch of over stuff. We even had a screaming
solid state disk - 20MB if I remember correctly (mirrored, of course,
talking a full rack). We pulled out multiple pallets of SDI cables
when we migrated from HSC to HSJ-40 controllers.

We had fun stuff like dealing with maximum process count - I remember
we maxed it out and DEC had to update VMS to allow a bigger number. I
think it was 1024 that we maxed out on.

I haven't seen this cluster in nearly 11 years so I don't know what it
looks like today, but I do know the cluster is still there -0 I don't
know if any Vaxes are there or if they've migrated everything to
Alpha. The admin positions are about to be outsourced to HP (EDS) -
the existing staff have been offered jobs with EDS.

.../Ed

Tybalt> write sys$output f$getsyi("cluster_ftime")
30-MAY-1999 07:28:07.05

Bob Koehler wrote:
[color=blue]
> There were calculations we did on our almighty MV II that were
> trivial to code up because the Fortran compiler fully supported
> H-float.[/color]

Out of curiosity, what sort of calculations could H-float do that IEEE
floating point can't do ?

Bob Koehler wrote:
[color=blue]
> Yeah, right. Just go back the the 1960s and 1970s and compare prices
> between any DEC PDP-x and IBM 360 series.[/color]

And therein lies Digital's fatal problem. And it should have known.

DEC grew because it was the new kid on the block with lower prices and
which IBM didn't take seriously. IBM would still charge an arm and a
leg, arguing its software was more sophisticated and for serious
applications. DEC was able to capture a huge new market with its lower
prices, relegating IBM to large businesses only.

In the 1980s, the "PC" and Sun grew in the exact same way: they came in,
offered lower prices, and DEC dismissed them as not serious enough for
real business and DEC continued to charge a premium for its product.
DEC's market shrunk to a handful of customers who still had to buy the
overpriced DEC gear and software.

JF Mezei wrote:[color=blue]
> Bob Koehler wrote:
>[color=green]
>> Yeah, right. Just go back the the 1960s and 1970s and compare prices
>> between any DEC PDP-x and IBM 360 series.[/color]
>
> And therein lies Digital's fatal problem. And it should have known.
>
> DEC grew because it was the new kid on the block with lower prices and
> which IBM didn't take seriously. IBM would still charge an arm and a
> leg, arguing its software was more sophisticated and for serious
> applications. DEC was able to capture a huge new market with its lower
> prices, relegating IBM to large businesses only.
>
> In the 1980s, the "PC" and Sun grew in the exact same way: they came in,
> offered lower prices, and DEC dismissed them as not serious enough for
> real business and DEC continued to charge a premium for its product.
> DEC's market shrunk to a handful of customers who still had to buy the
> overpriced DEC gear and software.[/color]

There is frequently a great reluctance to change something that works.
If it ain't broke, don't fix it!

Suddenly it's 2001 and you've got 1980's technology! Can't compete any
longer? Too bad!!

Those folks in California are selling workstations for a quarter of what
we charge? They can't be any good. . . .

Right! Goodbye DEC, hello Sun Microsystems. And Silicon Graphics, and
.. . . .

In article <e_KdnX0-rc9Ck5LUnZ2dnUVZ_v_inZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:[color=blue]
>
> Somehow I don't think that the PDP-8 was comparable, in any way, to the
> IBM System/360! They were both digital computers and there the
> resemblance ended.[/color]

There were some very small, very low capability, models in the 360
series. Systems like the 360/20 were mostly used to do things like
duplicate card decks. Most folks remember systems like the 360/75,
a multi-user mainframe about the size of a small house and priced a
few orders of magnitude higher. The 360/20 I saw would use just a
little more floor space than a basic 11/780 with one expansion
cabinet.

In article <00010d8a$0$26230$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:[color=blue]
> Bob Koehler wrote:
>[color=green]
>> There were calculations we did on our almighty MV II that were
>> trivial to code up because the Fortran compiler fully supported
>> H-float.[/color]
>
> Out of curiosity, what sort of calculations could H-float do that IEEE
> floating point can't do ?[/color]

H-float is a VAX specific format with about the same number of bits,
but slightly different definition, as IEEE X-float. H-float has
twice as many bits as VAX D-float or G-float. X-float has twice as
many bits as IEEE T-float.

In C speak, float would be done in VAX F-float or IEEE S-float, or
similar. double would be done in VAX D- or G-float, or IEEE T-float.
I don't know of any C compiler that supports VAX H-float or IEEE
X-float.

In Fortran, REAL or REAL*4 would be F-float or S-float. DOUBLE
PRECISION or REAL*8 would be D-, G-, or T-float. REAL*16 would
be H- or X-float. I don't know of any Fortran compiler that
supports X-float.

The extra precision of H-float was usefull in an algorithm that
converted D-float floating point values to 48 bit fixed point.
Just keeping everything in D-float would drop low bits during the
algorithm, leading to an inaccurate result.

We were given the algorithm, coded for Fortran REAL*8 on another
system by someone who didn't realise its limitations. Changing
to REAL*16 was a trivial edit to solve the problem.

In article <00010f78$0$26272$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:[color=blue]
>
> In the 1980s, the "PC" and Sun grew in the exact same way: they came in,
> offered lower prices, and DEC dismissed them as not serious enough for
> real business and DEC continued to charge a premium for its product.
> DEC's market shrunk to a handful of customers who still had to buy the
> overpriced DEC gear and software.[/color]

In the 1980s DEC was trying to overtake IBM and never looked back at
the new kids on the block.

Bob Koehler wrote:[color=blue]
> In article <e_KdnX0-rc9Ck5LUnZ2dnUVZ_v_inZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:[color=green]
>> Somehow I don't think that the PDP-8 was comparable, in any way, to the
>> IBM System/360! They were both digital computers and there the
>> resemblance ended.[/color]
>
> There were some very small, very low capability, models in the 360
> series. Systems like the 360/20 were mostly used to do things like
> duplicate card decks. Most folks remember systems like the 360/75,
> a multi-user mainframe about the size of a small house and priced a
> few orders of magnitude higher. The 360/20 I saw would use just a
> little more floor space than a basic 11/780 with one expansion
> cabinet.
>[/color]

I remember the 360/20. Princeton University used them as Remote Job
Entry (RJE) terminals. You read in your deck of punched cards, waited
while the 360/91 in the computer center crunched your numbers, and when
it was done your printout and maybe freshly punched cards came back.

If you wanted it to do something difficult you had to be prepared to
wait a LONG time! ISTR that the 360/20 used half bytes (4 bits) for
some things; they were christened "nybbles".

The 360/20 was the closest thing in the 360 line to the PDP-8.
Physically it was bigger than a PDP-8. I couldn't say if it was any
faster or smarter.


They made great RJE terminals. It's hard to imagine them doing anything
else!

Bob Koehler wrote:[color=blue]
> In article <00A82051.B459084E@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:[color=green]
>> BINGO! There still are sites that have not bothered to port their apps to
>> Alpha or Itanium. If H-float is needed, I'd wager that a library could be
>> developed to provide it and, on faster hardware, it may even best perform-
>> ance on VAX.[/color]
>
> Did any Alpha ever actually implement X-float? It was in my early
> Alpha architecture books, fully desribed, but documented as not
> implemented.[/color]

AFAIK not in HW.

But VMS does emulate it.
[color=blue]
> Does Itanium do X-float?
>
> There were calculations we did on our almighty MV II that were
> trivial to code up because the Fortran compiler fully supported
> H-float.[/color]

VMS Fortran still support REAL*16 !

Arne