"andy/christine" wrote in message
news:490e6d14@news.mel.dft.com.au...
> We had a VT220 on the fifteenth floor connected via 4 wire modem
> as the secondary console to the VAX8800s PRO380.
> It could do everything but power on/off.

I assume you mean power off the Pro380 as I believe powering off the 8800
was done from the console (only worked on 1 8800 in my field service
experience).

Bob Koehler wrote:
(snip)

> 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.

I don't know this one at all.

> 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.

Around then I worked in a place with three 11/750's and one 11/730.

It was well known that the 730 was faster for H-float, as it was
emulated on the 750. It might be, though, that the 750 had both
G-float and D-float microcode, if that was an option.

As I understood it at the time, it was standard on the 730.

-- glen

Bob Koehler wrote:
(snip)

> 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.

The convention is that it would be (long double), though I don't
know which systems have compilers that implement it.

-- glen

On Sat, 01 Nov 2008 15:01:03 -0400, Arne Vajhøj
wrote in <490ca76d$0$90264$14726298@news.sunsite.dk>:
> JF Mezei wrote:
>> At the opposite scale of things...

>> I ran an all mighty Microvax 2 with 8 megs of RAM and a 154meg drive to
>> support 8 users runing WPS-Plus. The success of the project lead the
>> MVII to be upgraded to 16 meg of RAM to support 12 users.

>> This was circa 1987.

> And today a single word processing user is using a PC
> with 4 MB L2 cache, 2 GB RAM and 320 GB disk ...

> HW has changed !

Not everybody has a single-user PC, tho'.

[ireid:~] > top
top - 08:16:57 up 55 days, 13:54, 75 users, load average: 2.23, 0.95, 0.72
Tasks: 648 total, 1 running, 643 sleeping, 3 stopped, 1 zombie
Cpu0 : 1.7% us, 1.0% sy, 0.0% ni, 96.9% id, 0.0% wa, 0.0% hi, 0.3% si
Cpu1 : 0.0% us, 0.3% sy, 0.0% ni, 0.0% id, 99.7% wa, 0.0% hi, 0.0% si
Cpu2 : 0.0% us, 0.3% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 0.0% us, 0.7% sy, 0.0% ni, 0.0% id, 95.6% wa, 0.3% hi, 3.4% si
Mem: 8162216k total, 7465120k used, 697096k free, 811288k buffers
Swap: 16771520k total, 136920k used, 16634600k free, 4377612k cached
....
[ireid:~] > cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
stepping : 6
cpu MHz : 2992.598
cache size : 4096 KB
....

There'll be more users later in the day of course. I'm not sure
how many machines are actually in the lxplus cluster; at least four.
This is at CERN, natuerlich.

[ireid:~] > uname -a
Linux lxplus235.cern.ch 2.6.9-78.0.1.EL.cernsmp #1 SMP Tue Aug 5 11:01:13 CEST
2008 x86_64 x86_64 x86_64 GNU/Linux

--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".

"Bob Koehler" wrote in message >
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.

"long double" on OpenVMS Alpha or OpenVMS I64 should get you X-float. I
don't think the VAX compiler knows about H-float however.

>
> 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.

REAL*16 on OpenVMS Alpha and OpenVMS I64 should get you X-float.

And for those of you keeping score at home, the QUADRUPLE datatype in Pascal
gives H-float on VAX, and X-float on Alpha and I64.

John

In article , "John Reagan" writes:
>
> "Bob Koehler" wrote in message >
> 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.
>
> "long double" on OpenVMS Alpha or OpenVMS I64 should get you X-float. I
> don't think the VAX compiler knows about H-float however.

What about if I'm not compiling with IEEE on my Alpha. Will "long
double" get me H-float?

In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article , "John Reagan" writes:
>>
>> "Bob Koehler" wrote in message >
>> 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.
>>
>> "long double" on OpenVMS Alpha or OpenVMS I64 should get you X-float. I
>> don't think the VAX compiler knows about H-float however.
>
> What about if I'm not compiling with IEEE on my Alpha. Will "long
> double" get me H-float?

If it does, it would be emulated in or provided by some library.


--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

Glen Herrmannsfeldt wrote:
> Bob Koehler wrote:
> (snip)
>
>> 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.
>
> The convention is that it would be (long double), though I don't
> know which systems have compilers that implement it.

DEC C 6.5 on Alpha has long double = X-float.

Arne

Bob Koehler wrote:
> In article , "John Reagan" writes:
>> "Bob Koehler" wrote in message >
>> 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.
>> "long double" on OpenVMS Alpha or OpenVMS I64 should get you X-float. I
>> don't think the VAX compiler knows about H-float however.
>
> What about if I'm not compiling with IEEE on my Alpha. Will "long
> double" get me H-float?

No. Always X on Alpha.

Arne

VAXman- @SendSpamHere.ORG wrote:
> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article , "John Reagan" writes:
>>> "Bob Koehler" wrote in message >
>>> 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.
>>> "long double" on OpenVMS Alpha or OpenVMS I64 should get you X-float. I
>>> don't think the VAX compiler knows about H-float however.
>> What about if I'm not compiling with IEEE on my Alpha. Will "long
>> double" get me H-float?
>
> If it does, it would be emulated in or provided by some library.

It is X. But that is also emulated.

Arne

"Bob Koehler" wrote in message

>
> What about if I'm not compiling with IEEE on my Alpha. Will "long
> double" get me H-float?
>

As Arne mentioned, you'll always get X. Other than binary compatibility
with VAX, H doesn't buy you anything that X doesn't provide.

On Alpha and I64, you can pick between

F/D/X
F/G/X
S/T/X

for real, double, long double, respectively. Only the defaults have changed
from Alpha to I64 [and the comparative speeds since F/D/G on I64 involve
converting to/from S/T].

John

John Reagan wrote:
(snip)

> On Alpha and I64, you can pick between

> F/D/X
> F/G/X
> S/T/X

> for real, double, long double, respectively. Only the defaults have changed
> from Alpha to I64 [and the comparative speeds since F/D/G on I64 involve
> converting to/from S/T].

As I understand it, F, D, and G on Alpha also involve conversion to S/T,
but the conversion is done in hardware. The load/store instructions load
F, D , or G from memory into S or T form in registers, and do the reverse
on store instructions.

-- glen

Glen Herrmannsfeldt wrote:
> John Reagan wrote:
> (snip)
>
>> On Alpha and I64, you can pick between
>
>> F/D/X
>> F/G/X
>> S/T/X
>
>> for real, double, long double, respectively. Only the defaults have
>> changed from Alpha to I64 [and the comparative speeds since F/D/G on
>> I64 involve converting to/from S/T].
>
> As I understand it, F, D, and G on Alpha also involve conversion to S/T,
> but the conversion is done in hardware. The load/store instructions load
> F, D , or G from memory into S or T form in registers, and do the reverse
> on store instructions.
>

F/G and S/T both look the same in registers and are very
similar in memory format also. Field sizes are all the same,
it's just a question of order. All are supported natively.

Limited D support is offered by using a LDG (LoaD G_floating)
to get the D value into a register and then using the CVTDG
and CVTGD instructions to convert between the two. So, you
get D, but less three bits of precision.

Tim.

In article , Glen Herrmannsfeldt writes:
>
> As I understand it, F, D, and G on Alpha also involve conversion to S/T,
> but the conversion is done in hardware. The load/store instructions load
> F, D , or G from memory into S or T form in registers, and do the reverse
> on store instructions.

No, D is converted to/from G on store/load, but F and G operations
are implemented.

"Glen Herrmannsfeldt" wrote in message
news:get3qq$5n2$1@aioe.org...

> As I understand it, F, D, and G on Alpha also involve conversion to S/T,
> but the conversion is done in hardware. The load/store instructions load
> F, D , or G from memory into S or T form in registers, and do the reverse
> on store instructions.

As Tim and Bob have already mentioned, the register format isn't any of the
memory formats of F/D/G/S/T. The load/store instructions know how to swap
bits around. The various instruction formats essentially control rounding,
precision, etc. So I suppose you can say that Alpha only knows one
floating format since all the operate instructions only work on registers.
The register format is essentially T format.

I64 is the same way. The I64 floating register is 82-bits wide. The
various instruction forms and FPSR bits control the precision, rouding,
shuffling of bits to/from memory, etc.

John

John Reagan wrote:
(I wrote)

>>As I understand it, F, D, and G on Alpha also involve conversion to S/T,
>>but the conversion is done in hardware. The load/store instructions load
>>F, D , or G from memory into S or T form in registers, and do the reverse
>>on store instructions.

> As Tim and Bob have already mentioned, the register format isn't any of the
> memory formats of F/D/G/S/T. The load/store instructions know how to swap
> bits around. The various instruction formats essentially control rounding,
> precision, etc. So I suppose you can say that Alpha only knows one
> floating format since all the operate instructions only work on registers.
> The register format is essentially T format.

Tim and Bob don't seem to mention that the byte order
is completely different. It seems strange to call them 'similar'
or 'implemented' given the differences.

-- glen

Glen Herrmannsfeldt wrote:
> John Reagan wrote:
> (I wrote)
>
>>> As I understand it, F, D, and G on Alpha also involve conversion to S/T,
>>> but the conversion is done in hardware. The load/store instructions
>>> load
>>> F, D , or G from memory into S or T form in registers, and do the
>>> reverse
>>> on store instructions.
>
>> As Tim and Bob have already mentioned, the register format isn't any
>> of the memory formats of F/D/G/S/T. The load/store instructions know
>> how to swap bits around. The various instruction formats essentially
>> control rounding, precision, etc. So I suppose you can say that
>> Alpha only knows one floating format since all the operate
>> instructions only work on registers. The register format is
>> essentially T format.
>
> Tim and Bob don't seem to mention that the byte order
> is completely different. It seems strange to call them 'similar'
> or 'implemented' given the differences.
>

Below is cut-n-paste from my post:

F/G and S/T both look the same in registers and are very
similar in memory format also. Field sizes are all the same,
it's just a question of order. All are supported natively.

------------------------^^^^^

I suppose I could have been clearer. You are correct. They are
in different byte order in memory. However, in registers they
are exactly the same.

On the Alpha this is handled by the LD[G|F] instruction. On I64
the AEST translator loads/stores F/G/D float with the use of of
the mux2 instruction (followed or preceeded with a setf/getf) to
achieve the same result.

Tim.

Michael Moroney wrote:
> Not a single system, but I came across comments in the disk shadowing code
> for a bugfix where a byte field was being treated as a negative number
> if it exceeded 127. That byte field was the number of nodes in a cluster,
> and it was found by a customer (I think I know who), not internal testing.
>
> Also the test followed a decrement of that field, meaning a node left
the
> cluster, so the bug wouldn't have been seen unless there were 129 or
> more nodes in the cluster at some point. (Supported limit was/is 96)

SYSMAN once had a hard-coded limit of 128 nodes, but that limit was
fixed in 5.5-1.

$MOUNT/CLUSTER once had a hard-coded limit of 96 nodes, but that was
fixed in 5.5-2.

I worked with a customer who built a cluster which peaked at 151 nodes
(150 VAXes plus 1 Alpha). See
http://www.geocities.com/keithparris...avc_article.ps

I've heard rumors of even larger clusters than that.

There also was a problem in V6.2-1H3 when the mount count field (UCB
$B_ONLCNT) exceeded 127. This caused a MSCPSERV crash. You had to have
more than 127. nodes in the cluster all mount the same disk. Been
there, seen that ;-)

Volker.