On Oct 23, 6:06 am, karthikbalaguru <karthikbalagur...@gmail.com> 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=AE 80x86 - Little-Endian > ARM* - Bi-Endian > HP PA-RISC 8000* - Bi-Endian > IBM PowerPC* - Bi-Endian > Intel=AE IXP network processors - Bi-Endian > Intel=AE Itanium=AE 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.
Direction of Stack Growth
Started by ●October 21, 2007
Reply by ●October 23, 20072007-10-23
Reply by ●October 23, 20072007-10-23
In article <1193136826.834413.289410@q5g2000prf.googlegroups.com>, karthikbalaguru <karthikbalaguru79@gmail.com> 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.
Reply by ●October 23, 20072007-10-23
On Oct 23, 4:15 pm, "robertwess...@yahoo.com" <robertwess...@yahoo.com> wrote:> On Oct 23, 6:06 am, karthikbalaguru <karthikbalagur...@gmail.com> > 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=AE 80x86 - Little-Endian > > ARM* - Bi-Endian > > HP PA-RISC 8000* - Bi-Endian > > IBM PowerPC* - Bi-Endian > > Intel=AE IXP network processors - Bi-Endian > > Intel=AE Itanium=AE 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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
Reply by ●October 23, 20072007-10-23
On Oct 23, 4:24 pm, n...@cus.cam.ac.uk (Nick Maclaren) wrote:> In article <1193136826.834413.289...@q5g2000prf.googlegroups.com>,karthikbalaguru <karthikbalagur...@gmail.com> 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
Reply by ●October 23, 20072007-10-23
Nick Maclaren wrote:> In article <XvmdnaRhB9sU_oDanZ2dnUVZ_o-mnZ2d@speakeasy.net>, > rpw3@rpw3.org (Rob Warnock) writes: > |> > |> Don't forget, DEC did it *both* ways! The PDP-10's hardware stack > |> grew "up"; the PDP-11's grew "down". The overlap in the lifecycle > |> of those two product lines was quite considerable. In fact, many > |> later PDP-10s used PDP-11s as front-end processors, so you even had > |> both ways in one system! ;-} > > Oh, indeed. Now, why the PDP-11 should have disproportionately more > influence on computer scientists (and this is not the only respect), > I leave to the sociologists. > > > Regards, > Nick Maclaren.Or leave it to the ethologists. Why do Teco, Emacs, and VI have disproportionate influence on people? The baby duck syndrome. JKA -- How do you tighten a screw? Turn it until the thread strips and then back it off a quarter of a turn?
Reply by ●October 23, 20072007-10-23
On Mon, 22 Oct 2007 19:53:20 -0700, Archi <z1@podzam.com> wrote:>Paul Keinanen wrote: > >> On 21 Oct 2007 21:25:48 GMT, nmm1@cus.cam.ac.uk (Nick Maclaren) wrote: >> >> With a stack growing upwards >> >> MOV VAR1, (R5)+ ; Push Var1 to top of stack >> ; R5 now points above the value pushed >> COM -2(R5) ; Do some operations on the value on the TOS >> ADD #5,-2(R5) ; Some more operations on TOS >> MOV -(R5),VAR2 ; Pop value from stack > >mov var1, +(r5) >com @r5 >add #5, @r5 >mov (r5)-,var2How on earth would you fit a pre-increment mode into the instruction map of the PDP-11 processor ???> > This is 2 words (4 bytes) longer than the previous example. > >Exactly the same. > >> In processors with pre-increment and post-decrement addressing modes, >> it would be natural to let the stack grow upwards. > >And this machine is the same PDP-11While it might be possible to replace the post-autoincrement with pre-increment mode and pre-decrement with post-decrement modes, by doing some considerable wire wrap work on the CPU boards or doing a complete rewrite of the microcode, what is the point ?? Anyway, after doing this, none of the original PDP-11 programs would run on that processor. Paul
Reply by ●October 23, 20072007-10-23
On Tue, 23 Oct 2007 02:53:13 -0000, Grant Edwards <grante@visi.com> wrote:>On 2007-10-23, Jerry Avins <jya@ieee.org> wrote: >> Randy Yates wrote: >>> Steve Underwood <steveu@dis.org> writes: >>> >>>> There are various machines where there program counter doesn't >>>> actually count at all, but each instruction points to the next. Most >>>> microcoded systems do that, but a few higher level programmable >>>> machines have done so as well. >>> >>> A linked list of instructions? >> >> That's how it was once, youngster. > >And you optimized your program by placing the instructions at >the appropriate places on the magnetic drum so that when each >instruction was finished executing, the next one in the list >was just getting to the R/W heads. > >Or so I'm told. I'm young. My experience only goes back as >far as paper tape on an ASR-33 and punch-cards on an IBM model >029.While I am a youngster, with only vacuum tube experience with audio and RF systems, but no logic vacuum tube systems, it would be interesting to design a usable computer using vacuum tubes (and possibly some semiconductor rectifiers). After all, we currently know something about how to design computers (able to execute usable programs) that the people in the 1940's did not know about. Paul
Reply by ●October 23, 20072007-10-23
Rob Warnock wrote: ...> p.s. O.k., o.k., the PDP-10 copied the PDP-6, but who > other than a few diehard DEC fans [such as yours truly] > even *remember* the PDP-6...?My early lab programs ran on a timeshare-for-hire PDP-6 that we reached by modem. Eventually I had a 9600-baud almost-half-duplex modem. I eventually rigged the 50-baud reverse channel to the keyboard of the 35ASR to get around the time delay for turning the line around. The tape reader ran at 110 baud, do I had to turn the line around for that. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●October 23, 20072007-10-23
Paul Keinanen wrote:> On Tue, 23 Oct 2007 02:53:13 -0000, Grant Edwards <grante@visi.com> > wrote: > >> On 2007-10-23, Jerry Avins <jya@ieee.org> wrote: >>> Randy Yates wrote: >>>> Steve Underwood <steveu@dis.org> writes: >>>> >>>>> There are various machines where there program counter doesn't >>>>> actually count at all, but each instruction points to the next. Most >>>>> microcoded systems do that, but a few higher level programmable >>>>> machines have done so as well. >>>> A linked list of instructions? >>> That's how it was once, youngster. >> And you optimized your program by placing the instructions at >> the appropriate places on the magnetic drum so that when each >> instruction was finished executing, the next one in the list >> was just getting to the R/W heads. >> >> Or so I'm told. I'm young. My experience only goes back as >> far as paper tape on an ASR-33 and punch-cards on an IBM model >> 029. > > While I am a youngster, with only vacuum tube experience with audio > and RF systems, but no logic vacuum tube systems, it would be > interesting to design a usable computer using vacuum tubes (and > possibly some semiconductor rectifiers). > > After all, we currently know something about how to design computers > (able to execute usable programs) that the people in the 1940's did > not know about.You don't want to work with a tube computer. Harvard's, which occupied an entire building, wasn't much better than an 8031. It was possible to stand outside it in the dead of winter and bask in the 60-degree cooling air that issues from gratings in the sidewalk. (In summer, it was best to stay away.) I don't think you can get Special Red tubes any more. With ordinary tubes that have maybe a 2000-hour MTBF, a computer with 10,000 tubes -- fewer active devices than ay pocket calculator -- the up time is tens of minutes. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●October 23, 20072007-10-23
On Oct 22, 2:36 pm, Elcaro Nosille <Elcaro.Nosi...@mailinator.com> wrote:> Terje Mathisen schrieb: > > >> With downwards growing stacks you can address the "top" element of > >> the stack at address sp + 0 and this results often in smaller opodes > >> of the machine-instructions adressing that elements. > >> With upwards growing stacks you either would have to know the size > >> of the top element when pushing another element to the stack or you > >> would have to address the top element at sp - N, you you couldn't > >> address it with an offset-less instruction. > > Sure you could! > > You just need a pre-increment stack pointer. > > Yes, but then a push onto the stack would have to know the size of > the element pushed before; i.e. there would be two operands of this > push-operation - that's bulky and unnecessary.This is logical. Karthik Balaguru
