Re: Direction of Stack Growth - Embedded

This is a discussion on Re: Direction of Stack Growth - Embedded ; On Oct 22, 9:12 pm, jo...@iecc.com (John L) wrote: > >I am pretty sure that this is yet another artifact of the way that > >DEC was the dominating computer science supplier in the 1970s. Now, > >why DEC did ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Re: Direction of Stack Growth

  1. Re: Direction of Stack Growth

    On Oct 22, 9:12 pm, jo...@iecc.com (John L) wrote:
    > >I am pretty sure that this is yet another artifact of the way that
    > >DEC was the dominating computer science supplier in the 1970s. Now,
    > >why DEC did things the way they did, I don't know.

    >
    > It was the same time they gave us little-endian addressing. Perhaps
    > it was just to do everyhing sdrawkcab.


    Interesting
    But, I think, in those days IBM used little-endian. DEC used Big-
    endian.
    Later came the tie-up of Motorola(Big-Endian) with Apple and
    Intel(Little-Endian) with IBM.
    After that many other competitors.
    Intel's 80x86 processors and their clones - little endian (also
    called as Intel format).
    SPARC, Motorola's 68K, and the PowerPC families - big endian.

    Earlier ARM processors (ARM2, ARM3, ARM2aS) - little-endian.
    Current generation ARM processors (from ARM6 onwards) - can operate in
    either little-endian or big-endian mode.

    Karthik Balaguru


  2. Re: Direction of Stack Growth


    In article <1193135352.100503.51110@i13g2000prf.googlegroups.c om>,
    karthikbalaguru writes:
    |>
    |> But, I think, in those days IBM used little-endian. DEC used Big-
    |> endian.

    IBM was primarily (perhaps entirely - I don't know) big-endian from
    the early 1960s onwards.


    Regards,
    Nick Maclaren.

  3. Re: Direction of Stack Growth

    On Oct 23, 3:40 pm, n...@cus.cam.ac.uk (Nick Maclaren) wrote:
    > In article <1193135352.100503.51...@i13g2000prf.googlegroups.c om>,karthikbalaguru writes:
    >
    > |>
    > |> But, I think, in those days IBM used little-endian. DEC used Big-
    > |> endian.
    >
    > IBM was primarily (perhaps entirely - I don't know) big-endian from
    > the early 1960s onwards.
    >


    The 370 series(IBM System/370) of computers was a 32-bit big endian
    style mainframe architecture,
    as compared with little endian architectures such as the x86 series of
    32-bit microprocessors.

    Refer -> http://en.wikipedia.org/wiki/System/370

    Karthik Balaguru



  4. Re: Direction of Stack Growth

    On Oct 23, 3:40 pm, n...@cus.cam.ac.uk (Nick Maclaren) wrote:
    > In article <1193135352.100503.51...@i13g2000prf.googlegroups.c om>,karthikbalaguru writes:
    >
    > |>
    > |> But, I think, in those days IBM used little-endian. DEC used Big-
    > |> endian.
    >
    > IBM was primarily (perhaps entirely - I don't know) big-endian from
    > the early 1960s onwards.
    >
    > Regards,
    > Nick Maclaren.


    http://www.intel.com/design/intarch/papers/endian.pdf ->
    Refer the section "Merits of Endian Architectures" and the Table for
    clarifications w.r.t endiannes

    DEC Alpha* - Little-Endian
    IntelŪ 80x86 - Little-Endian
    ARM* - Bi-Endian
    HP PA-RISC 8000* - Bi-Endian
    IBM PowerPC* - Bi-Endian
    IntelŪ IXP network processors - Bi-Endian
    IntelŪ ItaniumŪ processor family - Bi-Endian
    Java Virtual Machine* - Big-Endian
    MIPS* - Bi-Endian
    Motorola 68k* - Big-Endian
    Sun SPARC* - Big-Endian

    Also,
    DEC Alpha computers are configurable for Big Endian or Little Endian
    (that is, it is Bi-Endian as told in wikipedia).

    Thx,
    Karthik Balaguru


  5. Re: Direction of Stack Growth

    On Oct 23, 6:06 am, karthikbalaguru
    wrote:
    > http://www.intel.com/design/intarch/papers/endian.pdf ->
    > Refer the section "Merits of Endian Architectures" and the Table for
    > clarifications w.r.t endiannes
    >
    > DEC Alpha* - Little-Endian
    > IntelŪ 80x86 - Little-Endian
    > ARM* - Bi-Endian
    > HP PA-RISC 8000* - Bi-Endian
    > IBM PowerPC* - Bi-Endian
    > IntelŪ IXP network processors - Bi-Endian
    > IntelŪ ItaniumŪ processor family - Bi-Endian
    > Java Virtual Machine* - Big-Endian
    > MIPS* - Bi-Endian
    > Motorola 68k* - Big-Endian
    > Sun SPARC* - Big-Endian
    >
    > Also,
    > DEC Alpha computers are configurable for Big Endian or Little Endian
    > (that is, it is Bi-Endian as told in wikipedia).



    A number of the architectures listed as bi-endian, have a definite
    preferred mode. PPC, for example, has a significant amount of
    privileged stuff which is big endian, no matter the mode the processor
    is in, so your OS will always have to deal with a significant amount
    of big endian stuff. And the little endian mode, if present at all
    (it's optional, and not present on a number of important CPUs in the
    family), only swizzles the low few address bits, so unaligned accesses
    (which are supported in the ISA to a significant extent) don't work
    "correctly" in little endian mode.


  6. Re: Direction of Stack Growth


    In article <1193136826.834413.289410@q5g2000prf.googlegroups.c om>,
    karthikbalaguru writes:
    |>
    |> > |> But, I think, in those days IBM used little-endian. DEC used Big-
    |> > |> endian.
    |> >
    |> > IBM was primarily (perhaps entirely - I don't know) big-endian from
    |> > the early 1960s onwards.
    |>
    |> The 370 series(IBM System/370) of computers was a 32-bit big endian
    |> style mainframe architecture,
    |> as compared with little endian architectures such as the x86 series of
    |> 32-bit microprocessors.

    That was not an IBM design - IBM had manufacturing rights, and used
    them only from 1980 onwards.

    |> Refer -> http://en.wikipedia.org/wiki/System/370

    Sigh. It ain't what you don't know that causes the trouble; it's
    what you know that ain't so.

    Some of us were quite closely involved with IBM during the relevant
    period.


    Regards,
    Nick Maclaren.

  7. Re: Direction of Stack Growth

    On Oct 23, 4:15 pm, "robertwess...@yahoo.com"
    wrote:
    > On Oct 23, 6:06 am, karthikbalaguru
    > wrote:
    >
    >
    >
    >
    >
    > >http://www.intel.com/design/intarch/papers/endian.pdf->
    > > Refer the section "Merits of Endian Architectures" and the Table for
    > > clarifications w.r.t endiannes

    >
    > > DEC Alpha* - Little-Endian
    > > IntelŪ 80x86 - Little-Endian
    > > ARM* - Bi-Endian
    > > HP PA-RISC 8000* - Bi-Endian
    > > IBM PowerPC* - Bi-Endian
    > > IntelŪ IXP network processors - Bi-Endian
    > > IntelŪ ItaniumŪ processor family - Bi-Endian
    > > Java Virtual Machine* - Big-Endian
    > > MIPS* - Bi-Endian
    > > Motorola 68k* - Big-Endian
    > > Sun SPARC* - Big-Endian

    >
    > > Also,
    > > DEC Alpha computers are configurable for Big Endian or Little Endian
    > > (that is, it is Bi-Endian as told in wikipedia).

    >
    > A number of the architectures listed as bi-endian, have a definite
    > preferred mode. PPC, for example, has a significant amount of
    > privileged stuff which is big endian, no matter the mode the processor
    > is in, so your OS will always have to deal with a significant amount
    > of big endian stuff. And the little endian mode, if present at all
    > (it's optional, and not present on a number of important CPUs in the
    > family), only swizzles the low few address bits, so unaligned accesses
    > (which are supported in the ISA to a significant extent) don't work
    > "correctly" in little endian mode.- Hide quoted text -
    >
    > - Show quoted text -


    I like the table 2 that has clear information w.r.t Endianness w.r.t
    Protocols and Fileformats in that pdf . Find it below for your
    reference .
    http://www.intel.com/design/intarch/papers/endian.pdf -> Nice link for
    endianness

    Table 2 contains examples of some common file formats and the Endian
    order that they use:
    ================================================== ===================

    Little-Endian Format
    ------------------------------
    BMP (Windows* & OS/2)
    GIF
    FLI (Autodesk Animator*)
    PCX (PC Paintbrush*)
    QTM (MAC Quicktime*)
    RTF (Rich Text Format)

    Big-Endian Format
    --------------------------------
    PSD (Adobe Photoshop*)
    IMG (GEM Raster*)
    JPEG, JPG
    MacPaint
    SGI (Silicon Graphics*)
    Sun Raster
    WPG (WordPerfect*)

    Variable or Bi-Endian Format
    -------------------------------------------
    DXF (AutoCAD*)
    PS (Postscript*, 8 bit interpreted text, no Endian issue)
    POV (Persistence of Visionraytracer*)
    RIFF (WAV & AVI*)
    TIFF
    XWD (X Window Dump*)

    Bus Protocols - Little Endian Format
    ------------------------------------------------------
    Infiniband
    PCI Express
    PCI-32/PCI-64
    USB

    Network Protocols - Big Endian Format
    -------------------------------------------------------------
    TCP/IP
    UDP

    Bus Protocols - Bi-Endian Format
    ------------------------------------------------------
    GMII (8 bit wide bus, no Endian issue)

    Karthik Balaguru


  8. Re: Direction of Stack Growth

    On Oct 23, 4:24 pm, n...@cus.cam.ac.uk (Nick Maclaren) wrote:
    > In article <1193136826.834413.289...@q5g2000prf.googlegroups.c om>,karthikbalaguru writes:
    >
    > |>
    > |> > |> But, I think, in those days IBM used little-endian. DEC used Big-
    > |> > |> endian.
    > |> >
    > |> > IBM was primarily (perhaps entirely - I don't know) big-endian from
    > |> > the early 1960s onwards.
    > |>
    > |> The 370 series(IBM System/370) of computers was a 32-bit big endian
    > |> style mainframe architecture,
    > |> as compared with little endian architectures such as the x86 series of
    > |> 32-bit microprocessors.
    >
    > That was not an IBM design - IBM had manufacturing rights, and used
    > them only from 1980 onwards.
    >
    > |> Refer ->http://en.wikipedia.org/wiki/System/370
    >
    > Sigh. It ain't what you don't know that causes the trouble; it's
    > what you know that ain't so.
    >
    > Some of us were quite closely involved with IBM during the relevant
    > period.
    >

    hmm. Interesting
    Thx for mentioning it.

    Karthik Balaguru


  9. Re: Direction of Stack Growth

    karthikbalaguru wrote:
    (snip)

    > The 370 series(IBM System/370) of computers was a 32-bit big endian
    > style mainframe architecture,


    Note that IBM was consistently big-endian for S/370.
    Though there are no bit addressing instructions, all the documentation
    numbers bits with the least significant bit as zero.

    It does get interesting with the extension to 64 bit z/architecture,
    now the bits of a 32 bit register are numbered 32 to 63.
    (That is, 32 bit instructions use bits 32 to 63 of the
    64 bit registers defined by the architecture.)

    -- glen


  10. Re: Direction of Stack Growth

    On Oct 23, 3:39 pm, glen herrmannsfeldt wrote:
    > karthikbalaguru wrote:
    >
    > (snip)
    >
    > > The 370 series(IBM System/370) of computers was a 32-bit big endian
    > > style mainframe architecture,

    >
    > Note that IBM was consistently big-endian for S/370.
    > Though there are no bit addressing instructions, all the documentation
    > numbers bits with the least significant bit as zero.
    >
    > It does get interesting with the extension to 64 bit z/architecture,
    > now the bits of a 32 bit register are numbered 32 to 63.
    > (That is, 32 bit instructions use bits 32 to 63 of the
    > 64 bit registers defined by the architecture.)



    Your second statement is correct, I assume the first is a typo. In
    IBM S/360 (and many other IBM designed ISAs, like PPC), the *most*
    significant bit of a register or word is zero.


  11. Re: Direction of Stack Growth

    robertwessel2@yahoo.com wrote:

    (I wrote)

    >>Note that IBM was consistently big-endian for S/370.
    >>Though there are no bit addressing instructions, all the documentation
    >>numbers bits with the least significant bit as zero.


    >>It does get interesting with the extension to 64 bit z/architecture,
    >>now the bits of a 32 bit register are numbered 32 to 63.
    >>(That is, 32 bit instructions use bits 32 to 63 of the
    >>64 bit registers defined by the architecture.)


    > Your second statement is correct, I assume the first is a typo. In
    > IBM S/360 (and many other IBM designed ISAs, like PPC), the *most*
    > significant bit of a register or word is zero.


    Sometimes different words come out on the screen than
    the ones you think you are typing.

    Yes, I meant to say most significant bit is bit zero.
    (Otherwise it would not have been consistent.)

    Consistency seems worthwhile, otherwise you might end
    up like VAX with middle-endian floating point formats, carried
    over from the PDP-11 and continued on (as one option) in Alpha.

    -- glen


  12. Re: Direction of Stack Growth

    On Oct 23, 11:06 am, karthikbalaguru
    wrote:
    > http://www.intel.com/design/intarch/papers/endian.pdf ->
    > Refer the section "Merits of Endian Architectures" and the Table for
    > clarifications w.r.t endiannes
    >

    [...]
    > Java Virtual Machine* - Big-Endian


    FWIW, this is a misleading, if not actually incorrect statement. The
    Java virtual machine is endian-independent, in that the architecture
    is defined such that an implementation may use any byte order, and it
    is impossible for a program running on it to determine which is in
    use. Software implementations typically use the endianness of their
    underlying hardware. Hardware implementations seem to normally be big-
    endian, but there is no reason this is necessary.

    Java's I/O libraries are defined to use big-endian order, but this is
    a library issue, not an architectural one.




  13. Re: Direction of Stack Growth

    On Oct 31, 1:20 am, Jules wrote:
    > On Oct 23, 11:06 am, karthikbalaguru
    > wrote:
    >
    > >http://www.intel.com/design/intarch/papers/endian.pdf->
    > > Refer the section "Merits of Endian Architectures" and the Table for
    > > clarifications w.r.t endiannes

    >
    > [...]
    > > Java Virtual Machine* - Big-Endian

    >
    > FWIW, this is a misleading, if not actually incorrect statement. The
    > Java virtual machine is endian-independent, in that the architecture
    > is defined such that an implementation may use any byte order, and it
    > is impossible for a program running on it to determine which is in
    > use. Software implementations typically use the endianness of their
    > underlying hardware. Hardware implementations seem to normally be big-
    > endian, but there is no reason this is necessary.
    >
    > Java's I/O libraries are defined to use big-endian order, but this is
    > a library issue, not an architectural one.
    >
    >


    But, i got another link that states the same info.

    http://www.netrino.com/Publications/...Endianness.php -> This
    link
    also states that "The Java Virtual Machine is big endian as well."

    Is there any modified version of 'Java Virtual Machine' that is
    independent of endianness ?

    Can you share some link in the internet that discusses more about
    this.

    Karthik Balaguru


  14. Re: Direction of Stack Growth

    Jules wrote:
    (snip)

    > FWIW, this is a misleading, if not actually incorrect statement. The
    > Java virtual machine is endian-independent, in that the architecture
    > is defined such that an implementation may use any byte order, and it
    > is impossible for a program running on it to determine which is in
    > use. Software implementations typically use the endianness of their
    > underlying hardware. Hardware implementations seem to normally be big-
    > endian, but there is no reason this is necessary.


    > Java's I/O libraries are defined to use big-endian order, but this is
    > a library issue, not an architectural one.


    As visible to the user, it is big-endian. If you consider
    JVM as a processor architecture intended to run JVM code
    and Java libraries it is reasonable to call it big-endian.

    Many processors now are bi-endian, but internally they choose
    one or the other with conversion done on load/store operations.
    Alpha, can even load/store VAX middle-endian floating point data.

    In general, one doesn't define endianness where it isn't visible
    to the user in any way (for example, on internal processor registers).
    Externally, JVM looks big-endian.

    -- glen


+ Reply to Thread