Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/17/2016 05:50 PM, Eric Smith wrote: > > The TI TMS34010 and TMS34020 graphics processors were > bit-addressable, though instructions had to be 16-bit aligned. The > TMS34010 and the default mode of the TMS34020 were little-endian, > with bit 0 being the least significant bit. The TMS34020 has > configurable support for big-endian memory addressing. I'd forgotten about the TIGA chips, thanks. --Chuck
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Sat, Dec 17, 2016 at 2:59 PM, Chuck Guziswrote: > What perplexed me is that the address of 0 0 specified the first > bit in byte 0 of word 0, but that same bit was the *high order* bit in > the corresponding byte and word. It would seem to make more sense > reversing the significance of bits in a byte and bytes in a word such > that the lowest-numbered addresses corresponded to the least-significant > bits in a word or byte. > > Call it "extreme little endianess". Does anyone know of such an > architecture? > The IBM 7030 "Stretch" was bit-addressable for integer operations, but not for floating point or instructions. It used typical IBM big-endian bit numbering, with bit 0 being the most significant bit. The TI TMS34010 and TMS34020 graphics processors were bit-addressable, though instructions had to be 16-bit aligned. The TMS34010 and the default mode of the TMS34020 were little-endian, with bit 0 being the least significant bit. The TMS34020 has configurable support for big-endian memory addressing.
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Here's a tickler for the list... I've used bit-addressable machines, where individual bits were directly addressed without regard to their position within a byte or word. E.g., a system with 48 bit addresses, where the lower 3 bits of an address specified the bit within a byte; the next 3 specified the address of a byte within a (64 bit) word, and so on. Bit vectors were an important part of the architecture. What perplexed me is that the address of 0 0 specified the first bit in byte 0 of word 0, but that same bit was the *high order* bit in the corresponding byte and word. It would seem to make more sense reversing the significance of bits in a byte and bytes in a word such that the lowest-numbered addresses corresponded to the least-significant bits in a word or byte. Call it "extreme little endianess". Does anyone know of such an architecture? --Chuck
RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Lars Brinkhoff Sent: Wednesday, December 14, 2016 3:54 AM > Noel Chiappa wrote: >>> 9-track tapes on the PDP-10 used one of the following encodings: >> What about 7-track, any idea? I would assume 6 x 6-bit tape frames per >> 36-bit word, but that's just a guess. > A reasonable guess, and one I'd make too. But I don't know either. According to the monitor calls manuals for both Tops-10 and TOPS-20, as well as the manual specifically on tape labels etc., that's a very good guess, and a correct one. > Supposedly, many ITS backups were made to 7-track tapes. That became a > problem when the old tape drives started to fail, and available new tape > drives were only 9-track. The same issue occurred at SAIL for the early WAITS backups prior to the introduction of a KL-10 into the system (which grew from a PDP-6 to a PDP-10/PDP-6 to a KL-10/KA-10/166, then shrank to a KL-10/KA-10 down to a KL-10 only). The KL-10 had TU-78 drives on an RH20. AIUI, the older backup tapes were refrangled onto new 9-track media before the KA-10 and its drives were retired. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Noel Chiappa wrote: > > 9-track tapes on the PDP-10 used one of the following encodings: > > What about 7-track, any idea? I would assume 6 x 6-bit tape frames per > 36-bit word, but that's just a guess. A reasonable guess, and one I'd make too. But I don't know either. Supposedly, many ITS backups were made to 7-track tapes. That became a problem when the old tape drives started to fail, and available new tape drives were only 9-track.
RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Eric Smith Sent: Saturday, December 10, 2016 6:38 PM > On Fri, Dec 9, 2016 at 12:47 PM, Rich Alderson> wrote: >> [1] For non-PDP10 programmers: The original architecture of the PDP-6 >> and PDP-10 used an 18-bit (256KW) address space. The KI-10 >> processor added a 22-bit pager and a concept of sections to the >> hardware. > As you say, the KI10 had 22-bit physical memory addressing, almost > identical to the "KI paging" of the later Model A KL10. There were two > PTEs per 36-bit word in the page table, with the five of the 18 bits > being the APWSX properties, and the remaining 13 being a physical page > number. The 13-bit physical page number was concatenated with the > offset into the 512-word page (low 9 bits of the virtual address) to > get the 22-bit physical address. > However, the KI10 did not have any "sections". Sections were introduced > with the Extended ("Model B", "KL paging") KL10. I knew that was wrong just as soon as I had hit "Send", but I also knew that I could count on one of the PDP-10 subgroup to fix that. Thanks! Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Fri, Dec 9, 2016 at 12:47 PM, Rich Aldersonwrote: > [1] For non-PDP10 programmers: The original architecture of the PDP-6 and > PDP-10 used an 18-bit (256KW) address space. The KI-10 processor added > a 22-bit pager and a concept of sections to the hardware. > As you say, the KI10 had 22-bit physical memory addressing, almost identical to the "KI paging" of the later Model A KL10. There were two PTEs per 36-bit word in the page table, with the five of the 18 bits being the APWSX properties, and the remaining 13 being a physical page number. The 13-bit physical page number was concatenated with the offset into the 512-word page (low 9 bits of the virtual address) to get the 22-bit physical address. However, the KI10 did not have any "sections". Sections were introduced with the Extended ("Model B", "KL paging") KL10.
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
> Both One-Word and Two-Word Global Byte Pointers were added at the same > time as extended addressing, according to the HRM. Simple "Global Byte > Pointer" would have been inherently ambiguous. OWG's were added to the KL ucode later: ;251ADD CODE FOR ONE WORD GLOBAL BYTE POINTERS. ; TOOK OUT EDITS 243 AND 250 TO GET ENOUGH SPACE IN CRAM ; FOR THIS EDIT. OWGBP WITH EXTEND INSTRUCTIONS WILL NOT ; RETURN A OWGBP. THEY WILL RETURN A TWO WORD GLOBAL BP. I can't tell off hand if there was a TOPS-20 release that supported extended addressing earlier than UCODE version 251. Hey! here's a ref to TWG's in the UCODE history: ;3369 Aug 83--Back off 330 for a bit, since TOPS-10 7.02 must be tested ; and OWGs in section 0 fail for string instructions (they get converted ; to TWGs, which are illegal in section 0). For now, we will maintain ; both sources. Maybe I'm conflating things with the legalization of OWGs in section zero (the low 256KW of address space that behaved like a non-extended machine) > The KI-10 processor added > a 22-bit pager and a concept of sections to the hardware. Are you sure? KI (aka TOPS-10) paging may have extended the physical address space, but not the virtual address space (still limited to 18 bits). In the end TOPS-10 used "KL" paging: DECnet had to live in a non-zero section in the monitor (in 7.02?), and user-mode extended address was finally added later.
RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Phil Budne Sent: Friday, December 09, 2016 10:44 AM > Rich Alderson wrote: >> There are also Two-Word Global Byte Pointers (which I've never seen >> abbreviated) which carry the standard "any size byte at any position" > Maybe they were just Global Byte Pointers? OWG's were a late > addition. I was a member of the FORTRAN-10/20 v10 project to make it > generate/run code in extended addressing... It's tempting to look at > the compiler and FOROTS to see what terms we used a the time... Both One-Word and Two-Word Global Byte Pointers were added at the same time as extended addressing, according to the HRM. Simple "Global Byte Pointer" would have been inherently ambiguous. OWGBPs were a way not to increase the memory footprint of a program when moving it into a non-zero section,[1] at the expense of some microcode. In theory, a binary could be patched for use in a non-zero section without a recompile, as long as it was using 6-, 7-, 8-, 9-, or 18-bit bytes. >> Neither of those is entirely accurate. 9-track tapes on the PDP-10 used >> one of the following encodings: > 8-bit characters became more important near the end of PDP-10 software > development. ISTR TOPS-10 getting new 8-bit I/O modes, but I have a > vague recollection that translation between 36-bit words and mag tape > frames was handled by the "tape formatter" hardware, which means that > writing two words with 8 bit bytes in way that was easily legible on > 8-bit byte oriented hardware ("high density mode" was only "legible" > for the even words). Yes, all the translations are handled in the formatter, which is part of the tape controller. To continue the example, in Industry-Compatible format, where the ASCII characters have been moved into 8-bit bytes in 36-bt words, on 9-track tape we have "HELLOworld" as _HHH _EEE _LLL _LLL _OOO _www _ooo _rrr _lll _ddd In memory, this takes 3 words: _HHH_EEE_LLL_LLL _OOO_www_ooo_rrr _lll_ddd Rich [1] For non-PDP10 programmers: The original architecture of the PDP-6 and PDP-10 used an 18-bit (256KW) address space. The KI-10 processor added a 22-bit pager and a concept of sections to the hardware. When the address space was expanded to 30 bits (1MW) on the KL-10 processor (in anticipation of the KC-10 a/k/a "Jupiter"), it was done by retaining 18-bit local addressing and adding a 12-bit section number to provide global addresses. Section 0 is special, working like the older 256KW memory space; non-zero sections can reference all of memory, with an 18-bit address in a non-zero section being section local and a 30-bit address referencing anything except section 0. Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/08/2016 07:08 PM, dwight wrote: Not meaning to throw things to far off but on my NC4000 machine( 16 bit ), I found ByteSwap useful enough that I had it hard wired. I have an old computer that was intended to do FFTs. It has a complete bit order swap, MSB to LSB, instruction. Yup, this is to implement the "butterfly" mirroring of the addresses for the FFT. Jon
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/09/2016 07:02 AM, Paul Koning wrote: > Rather than "can't make up their mind", a good reason to have > selectable endian processors is that the best choice may depend on > the application. So for embedded systems in particular, it's good to > be able to pick which you want. My quip was an attempt at levity. One interesting aspect of the later ARM (e.g. Cortex M3) are the "reverse" instructions: REV reverses the byte order in a 32-bit words. Thus, ABCD becomes DCBA. REV16 reverses the byte order in each halfword of a 32 bit word, ABCD becomes BADC. REVSH reverses the byte order in the low-order halfword and sign extends to 32 bits. Thus ABCD becomes SSDC (with S symbolizing the extended sign bit) RBIT reverses the bit order in a 32 bit word. So lots of choices for those who feel that variety is the spice of life. --Chuck
RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Rich Alderson wrote: > There are also Two-Word Global Byte Pointers (which I've never seen > abbreviated) which carry the standard "any size byte at any position" Maybe they were just Global Byte Pointers? OWG's were a late addition. I was a member of the FORTRAN-10/20 v10 project to make it generate/run code in extended addressing... It's tempting to look at the compiler and FOROTS to see what terms we used a the time... > Neither of those is entirely accurate. 9-track tapes on the PDP-10 used > one of the following encodings: 8-bit characters became more important near the end of PDP-10 software development. ISTR TOPS-10 getting new 8-bit I/O modes, but I have a vague recollection that translation between 36-bit words and mag tape frames was handled by the "tape formatter" hardware, which means that writing two words with 8 bit bytes in way that was easily legible on 8-bit byte oriented hardware ("high density mode" was only "legible" for the even words). phil
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Chuck I was just trying to squeeze Peter Jennings code for the KIM-1 into a single 1K worth of EPROM that would self load. There was enough space if I didn't include the opening moves. I wanted to use the empty space in my KIM-1 debug board EPROM. Some of the test use so little space. I finally split it into two blocks. So once one gets their KIM-1 working again, they can play MicroChess. I've not tried to play it yet. I have to pull out my chess board. So, some interest in Chess playing. I have my KIM-1 working on my prototype 6532 to 6530 adapter. Dwight From: cctalk <cctalk-boun...@classiccmp.org> on behalf of jim stephens <james.w.steph...@gmail.com> Sent: Thursday, December 8, 2016 10:48:05 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list] On Thu, Dec 8, 2016 at 9:51 AM, Chuck Guzis <ccl...@sydex.com> wrote: > On 12/07/2016 11:03 PM, jim stephens wrote: > > > > I must have the wrong mindset. Does computer chess hold any interest > today? Or is the matter of machine-over-human pretty much a fait accompli? > > --Chuck > > I'll run thru some moves with any new chess program I find. I'm so rusty and try such oddball moves in messing with them that I lose too much of the time. I first had a copy of Sargon for the Apple 2 eons ago, and it was impressive for the time. Also useful for doing study of positions and the like too. I really like Adventure and got totally geeked out meeting Don Woods @ VCF West (thanks guys who put on VCF West again) Thanks Jim
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
> On Dec 9, 2016, at 1:25 AM, Chuck Guziswrote: > > On 12/08/2016 08:46 PM, Cameron Kaiser wrote: I have an old computer that was intended to do FFTs. It has a complete bit order swap, MSB to LSB, instruction. >>> >>> Well, there's the PowerPC "endian" mode (settable in the MSR)--but >>> it's just "sort of"--the little-endian mode simply XORs the lower 3 >>> bits of the address with 111 (i.e. "flips them"). >> >> Or you could use the PowerPC byte-swapped instructions (lwbrx, etc.) > > Forgot to mention the ARM CPUs/MCUs. Supports both, for people who > can't make up their mind. Rather than "can't make up their mind", a good reason to have selectable endian processors is that the best choice may depend on the application. So for embedded systems in particular, it's good to be able to pick which you want. paul
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Rich Aldersonwrites: > The 5 characters per word is irrelevant to a discussion of tape, whether > 9- or 7-track: That's how ASCII text was represented in memory, on disk, > on DECtape, or on any other word-oriented medium. Representing the bits > in an ASCII character by the character itself (to make divisions on the > tape more clear), this appears diagrammatically as follows: > > Text: HELLOworld > > Memory: > HHHEEELLOOO_wwwooorrrlllddd_ > > Core Dump: High Density: SIXBIT: (7 track) > HHHEHHHEHH > EELLEELLHE > EE > LL > OOO_OOO_OO > wwwowwwoO_ > oorroorrww > rlllrlllwo > ddd_oo > ddd_rrrlll > dd > d_ Let's add ANSI-ASCII: .HHH .EEE .LLL .LLL _OOO .www .ooo .rrr .lll _ddd The nice property with this format is that ASCII text in 36-bit words comes out as ASCII text in octets, while also preserving binary 36-bit data.
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Thu, Dec 8, 2016 at 9:51 AM, Chuck Guziswrote: > On 12/07/2016 11:03 PM, jim stephens wrote: > > > > I must have the wrong mindset. Does computer chess hold any interest > today? Or is the matter of machine-over-human pretty much a fait accompli? > > --Chuck > > I'll run thru some moves with any new chess program I find. I'm so rusty and try such oddball moves in messing with them that I lose too much of the time. I first had a copy of Sargon for the Apple 2 eons ago, and it was impressive for the time. Also useful for doing study of positions and the like too. I really like Adventure and got totally geeked out meeting Don Woods @ VCF West (thanks guys who put on VCF West again) Thanks Jim
RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Chuck Guzis Sent: Wednesday, December 07, 2016 10:43 PM > On 12/07/2016 12:46 PM, Rich Alderson wrote: >> Neither of those is entirely accurate. 9-track tapes on the PDP-10 >> used one of the following encodings: > The last time that I had to deal with PDP-10 tapes, admittedly also 40 > years ago was essentially core-dump format. 5 7-bit characters per > word, with one bit unused; words packed end-to-end; i.e. 9 frames for 2 > PDP 10 words. That sounds more like high density format, if there were 9 frames for 2 words (i.e., 72 bits total). Core dump format would require 10 frames. The 5 characters per word is irrelevant to a discussion of tape, whether 9- or 7-track: That's how ASCII text was represented in memory, on disk, on DECtape, or on any other word-oriented medium. Representing the bits in an ASCII character by the character itself (to make divisions on the tape more clear), this appears diagrammatically as follows: Text: HELLOworld Memory: HHHEEELLOOO_wwwooorrrlllddd_ Core Dump: High Density: SIXBIT: (7 track) HHHEHHHEHH EELLEELLHE EE LL OOO_OOO_OO wwwowwwoO_ oorroorrww rlllrlllwo ddd_oo ddd_rrrlll dd d_ where _ represents the unused bit 35 in the word and . represents the don't-care bits inserted by the tape controller/formatter for core dump. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
> > I have an old computer that was intended to do FFTs. It has a > > complete bit order swap, MSB to LSB, instruction. > > Well, there's the PowerPC "endian" mode (settable in the MSR)--but it's > just "sort of"--the little-endian mode simply XORs the lower 3 bits of > the address with 111 (i.e. "flips them"). Or you could use the PowerPC byte-swapped instructions (lwbrx, etc.) -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Maybe this world is another planet's hell. -- Aldous Huxley
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/08/2016 05:08 PM, dwight wrote: > Not meaning to throw things to far off but on my > > NC4000 machine( 16 bit ), I found ByteSwap useful enough that I had it > > hard wired. > > I have an old computer that was intended to do FFTs. It has a > > complete bit order swap, MSB to LSB, instruction. Well, there's the PowerPC "endian" mode (settable in the MSR)--but it's just "sort of"--the little-endian mode simply XORs the lower 3 bits of the address with 111 (i.e. "flips them"). --Chuck
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Not meaning to throw things to far off but on my NC4000 machine( 16 bit ), I found ByteSwap useful enough that I had it hard wired. I have an old computer that was intended to do FFTs. It has a complete bit order swap, MSB to LSB, instruction. All interesting. Dwight From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Noel Chiappa <j...@mercury.lcs.mit.edu> Sent: Thursday, December 8, 2016 1:30:48 PM To: cctalk@classiccmp.org Cc: j...@mercury.lcs.mit.edu Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list] > From: Rich Alderson > 9-track tapes on the PDP-10 used one of the following encodings: What about 7-track, any idea? I would assume 6 x 6-bit tape frames per 36-bit word, but that's just a guess. Noel
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
> From: Rich Alderson > 9-track tapes on the PDP-10 used one of the following encodings: What about 7-track, any idea? I would assume 6 x 6-bit tape frames per 36-bit word, but that's just a guess. Noel
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/07/2016 11:03 PM, jim stephens wrote: > The Multics version I saw came from a Fortran version taken from a > PDP10. If I'm not mistaken it was directly from the timeshare > system they used in Billerica,Ma where Don Woods worked. After some > massaging it was unleashed on Multics. Most of Honeywell was wiped > out by copies on various machines for quite some time (2 or 3 > months?) before people quit risking getting into trouble to play it > anyway. > > There were two files, the main fortran file, and the table file with > the cave encoding. I suspect anyone who got a copy of the latter, > and read the former wrote a program to print out a very useful cheat > sheet. If you had that, you could solve all of the puzzles from data > in the table, and you only had to worry about the problems associated > with random behavior. > > The PDP-10 source did have a schedule feature to allow the game to > only be played during certain hours, but in the copy we were running > that was bypassed to allow it to run 24 / 7. That sounds right. I also remember the process in the PDP10 version involved saving the entire core image of the game. While I didn't make a cheat sheet from the travel tables, a couple of friends did. ADVENTure turned out to be a huge black hole for employees' time. I never owned up to being the ne'er do well who introduced it--it could have turned into a big obstacle in my career had the facts been known. I loosed the source on the landscape like a bunch of locusts--my name never appeared anywhere in the CDC adaptation. But I never took to the game very much. I've never been one for computer games and wheile Adventure was interesting, I grew disinterested after about a week. I knew people who'd sit at the 6600 operator's console playing Chess 3.0 for hours in the middle of the night, but the idea of playing against a machine held no fascination. That has proved to be the pattern ever since for computer games. When I wrote SIMCGA for the Hercules-Graphics-equipped PC, publishers would send me games to try out. None of them did a thing for me other than make some money. I must have the wrong mindset. Does computer chess hold any interest today? Or is the matter of machine-over-human pretty much a fait accompli? --Chuck
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/7/2016 10:42 PM, Chuck Guzis wrote: On 12/07/2016 12:46 PM, Rich Alderson wrote: Neither of those is entirely accurate. 9-track tapes on the PDP-10 used one of the following encodings: The last time that I had to deal with PDP-10 tapes, admittedly also 40 years ago was essentially core-dump format. 5 7-bit characters per word, with one bit unused; words packed end-to-end; i.e. 9 frames for 2 PDP 10 words. It was the "Adventure" game, smuggled to me by a DEC field engineer. Translating to CDC display code and then dealing with the differences in FORTRAN made the work interesting. The thing spread like wildfire throughout the CDC corporate system and was ardently hunted and purged by COMSOURCE administrators. --Chuck The Multics version I saw came from a Fortran version taken from a PDP10. If I'm not mistaken it was directly from the timeshare system they used in Billerica,Ma where Don Woods worked. After some massaging it was unleashed on Multics. Most of Honeywell was wiped out by copies on various machines for quite some time (2 or 3 months?) before people quit risking getting into trouble to play it anyway. There were two files, the main fortran file, and the table file with the cave encoding. I suspect anyone who got a copy of the latter, and read the former wrote a program to print out a very useful cheat sheet. If you had that, you could solve all of the puzzles from data in the table, and you only had to worry about the problems associated with random behavior. The PDP-10 source did have a schedule feature to allow the game to only be played during certain hours, but in the copy we were running that was bypassed to allow it to run 24 / 7. thanks Jim
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/07/2016 12:46 PM, Rich Alderson wrote: > Neither of those is entirely accurate. 9-track tapes on the PDP-10 > used one of the following encodings: The last time that I had to deal with PDP-10 tapes, admittedly also 40 years ago was essentially core-dump format. 5 7-bit characters per word, with one bit unused; words packed end-to-end; i.e. 9 frames for 2 PDP 10 words. It was the "Adventure" game, smuggled to me by a DEC field engineer. Translating to CDC display code and then dealing with the differences in FORTRAN made the work interesting. The thing spread like wildfire throughout the CDC corporate system and was ardently hunted and purged by COMSOURCE administrators. --Chuck
RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Chuck Guzis Sent: Monday, December 05, 2016 6:15 PM > On 12/05/2016 01:09 PM, Lars Brinkhoff wrote: >> As Charles wrote, the PDP-10 commonly uses 7-bit bytes for ASCII >> text, but that's only part of the truth. The architecture is quite >> byte size agnostic. There are instructions to operate on any byte >> size from 1 to 36 bits, at any position inside a word. (Well, a >> later extension to the architecture restricted this a bit.) The restriction Lars mentions only applies to what are referred to as One-Word Global Byte Pointers (OWGBPs), which encode the divisions of a 36-bit word into 6, 7, 8, 9, or 18 bit bytes into a 6-bit value in the high-order bits of a word with a 30-bit address filling the rest. There are also Two-Word Global Byte Pointers (which I've never seen abbreviated) which carry the standard "any size byte at any position" in the first word, with a zero address in the right half, and the 30-bit extended address (with 0's in the 6 high-order bits) in the second. > I've seen PDP-10 9-track tapes done two ways--one character per frame > and then 4 frames (36 bits) with 5 7-bit characters and the sign bit > left over. Neither of those is entirely accurate. 9-track tapes on the PDP-10 used one of the following encodings: 1. Core-Dump: 4 frames of 8 bits, 5th frame with 4 leading 0's (or 0100 on one type of controller) and the last 4 bits. 2. Industry-Compatible: 4 frames of 8 bits, and ignore the low order 4. 3. ANSI-ASCII: 4 frames of 7 bits padded with a leading 0, 5th frame with low order bit (B35) followed by the remaining 7 bits. In this case, B35 is usually 0, but in the case of line-numbered files B35 = 1 is the indicator that the 5 ASCII digits are a line number (and the parity bit is set incorrectly on the tape). 4. High-Density: 4 frames of 8 bits, 5th frame has low order 4 bits of the 1st word in its high order bits + high order 4 bits of the 2nd word in its low order bits, then 4 frames of 8 bits finishing up the 2nd word. I've been dealing with PDP-10 tapes for 40 years now. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Charles Anthony wrote: > PDP-10: 36 bit word, 5*7bit characters. Mouse wrote: >> You mean like any 36-bit machine? > No, they usually either ran as 6 6-bit bytes or 4 9-bit bytes, from > what I understand. As Charles wrote, the PDP-10 commonly uses 7-bit bytes for ASCII text, but that's only part of the truth. The architecture is quite byte size agnostic. There are instructions to operate on any byte size from 1 to 36 bits, at any position inside a word. (Well, a later extension to the architecture restricted this a bit.)
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
>>> Middle-endian FTW >> That makes me wonder: was there any hardware that used an endianness >> such that conversion didn't loop with period 2? > Not quite the same thing but weren't longwords on the PDP-11 > little-endian for the bytes within the word but big-endian for words > within the longword? Yes. As I said in the very next paragraph, > Conversion between PDP11-endian (0x87654321 stored as 0x65 0x87 0x21 > 0x43) and [...] /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
>> Or how about architectures not using a word length that's an >> integral number of bytes? > You mean like any 36-bit machine? No, they usually either ran as 6 6-bit bytes or 4 9-bit bytes, from what I understand. (The era of 36-bit machines was before "byte" had drifted to its current synonymity with "octet".) Byte sex is really an issue of conversion between numbers and their serializations. For example, it does not make sense to speak of the number 2271560481 (0x87654321) having an endianness in its own right; endianness becomes a meaningful concept only when a number is made up of smaller units with some kind of ordering among themselves. Most commonly these are memory-addressing units, with the order being increasing address order, but the terminology can also be used when, for exmaple, discussing serializing bits onto a bit-serial transmission medium, with the order being transmission order (eg, when sending characters over a serial line). To address the comment, I don't know enough about any of the 36-bit machines to know whether they had sub-36-bit-word addressing or any such, which would be necessary for concepts such as endianness to make sense. I think at least one early (by modern standards) machine supported addressing memory as if it were an array of bits, extracting an arbitrary block of those bits not longer than a machine word; if true, that addressing order would induce an endianness /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Mon, Dec 5, 2016 at 11:14 AM, Dave Wade <dave.g4...@gmail.com> wrote: > > -Original Message- > > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of David > > Bridgham > > Sent: 05 December 2016 18:37 > > To: General Discussion: On-Topic and Off-Topic Posts > > <cctalk@classiccmp.org> > > Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list] > > > > On 12/05/2016 12:17 PM, Chuck Guzis wrote: > > > > > Or how about architectures not using a word length that's an integral > > > number of bytes? > > > > You mean like any 36-bit machine? > > Honeywell L66 & DPS8 used to have 36 bit words which originally contained 6 > x 6-bit characters. > When they extended the machines to work with ASCII they put 4 x 9-bit > characters which I seem to > remember they called 9-bit bytes.. > > Yes; the Extended Instruction set handles 4*9bit, 6*6bit, 8*4bit (with the 4 padding bits scattered through the word). >From memory: PDP-10: 36 bit word, 5*7bit characters. PDP-15: 18 bit word, but it was so long ago, I don't remember CDC 6000: 60 bit word, 10 six bit characters. PDP11 "middle endian" see "NUXI problem: http://www.catb.org/jargon/html/M/middle-endian.html PDP11 RADIX-50 3 characters packed into a 16 bit word; each character in a 0:39 set. Back to Der Mouse question re: non-symmetrical mapping hton and ntoh are not meant has generalized data conversion; they are intended as network data packet field conversion; the domain of ntohl is a 32bit unsigned integer; the range is a host object larger enough to contain all possible values. For hosts that are base 2 and have word sizes that divide 32bits evenly, the functions would typically be identity or bit rearrangement, and the htonl and ntohl functions would be symmetric -- I suspect that a good mathematician could 'prove' that cycle length is always 2 given the constraints. Cases like 36 bits words mean that htonl is "lossy"; it throws away bits and and ntohl pads the result with 0s -- they are not symmetrical, thus the answer to the order-2 cycle question is 'not applicable' -- Charles
RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]
> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of David > Bridgham > Sent: 05 December 2016 18:37 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk@classiccmp.org> > Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list] > > On 12/05/2016 12:17 PM, Chuck Guzis wrote: > > > Or how about architectures not using a word length that's an integral > > number of bytes? > > You mean like any 36-bit machine? Honeywell L66 & DPS8 used to have 36 bit words which originally contained 6 x 6-bit characters. When they extended the machines to work with ASCII they put 4 x 9-bit characters which I seem to remember they called 9-bit bytes.. Dave
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 11:51 AM, Mouse wrote: >> Middle-endian FTW > That makes me wonder: was there any hardware that used an endianness > such that conversion didn't loop with period 2? Not quite the same thing but weren't longwords on the PDP-11 little-endian for the bytes within the word but big-endian for words within the longword?
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 12:17 PM, Chuck Guzis wrote: > Or how about architectures not using a word length that's an integral > number of bytes? You mean like any 36-bit machine?
Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 08:51 AM, Mouse wrote: > > Little- and big-endian do this; conversion between them is > byteswapping, which is self-inverse. Conversion between > PDP11-endian (0x87654321 stored as 0x65 0x87 0x21 0x43) and either > big- or little-endian is also self-inverse. Is there any hardware > for which conversion between its native storage format and any of > these three is not self-inverse? To put it another way, and rather > more loosely, is there one for which htonl and ntohl are actually > different operations? Decimal machines, such as the 1620 and 1401? Of course, these aren't word-oriented machines either, but variable-length systems. Conversion between either of those and your VAX is not simply a matter of byte-swapping. Or how about architectures not using a word length that's an integral number of bytes? --Chuck
Odd "endianness" [was Re: RE: Base 64 posts to the list]
>> Little-endian!!! > Middle-endian FTW That makes me wonder: was there any hardware that used an endianness such that conversion didn't loop with period 2? Little- and big-endian do this; conversion between them is byteswapping, which is self-inverse. Conversion between PDP11-endian (0x87654321 stored as 0x65 0x87 0x21 0x43) and either big- or little-endian is also self-inverse. Is there any hardware for which conversion between its native storage format and any of these three is not self-inverse? To put it another way, and rather more loosely, is there one for which htonl and ntohl are actually different operations? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B