Most impressive VAX installations - DEC

This is a discussion on Most impressive VAX installations - DEC ; JF Mezei wrote: > Bob Koehler wrote: >> There were calculations we did on our almighty MV II that were >> trivial to code up because the Fortran compiler fully supported >> H-float. > > Out of curiosity, what sort ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 80 of 80

Thread: Most impressive VAX installations

  1. Re: Most impressive VAX installations

    JF Mezei wrote:
    > Bob Koehler wrote:
    >> There were calculations we did on our almighty MV II that were
    >> trivial to code up because the Fortran compiler fully supported
    >> H-float.

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


    None.

    Because IEEE has X-float with the same precision.

    But in some cases 128 bit floating point (H or X) can fix
    numerical problems in 64 bit float (D/G/T).

    Arne

  2. Re: Most impressive VAX installations

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


  3. Re: Most impressive VAX installations

    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


  4. Re: Most impressive VAX installations

    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


  5. Re: Most impressive VAX installations

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

  6. Re: Most impressive VAX installations


    "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



  7. Re: Most impressive VAX installations

    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?


  8. Re: Most impressive VAX installations

    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.

  9. Re: Most impressive VAX installations

    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

  10. Re: Most impressive VAX installations

    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

  11. Re: Most impressive VAX installations

    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

  12. Re: Most impressive VAX installations


    "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



  13. Re: Most impressive VAX installations

    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


  14. Re: Most impressive VAX installations

    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.

  15. Re: Most impressive VAX installations

    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.


  16. Re: Most impressive VAX installations


    "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



  17. Re: Most impressive VAX installations

    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


  18. Re: Most impressive VAX installations

    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.

  19. Re: Most impressive VAX installations

    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.

  20. Re: Most impressive VAX installations

    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.

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4