der> That sounds a whole lot like a hardware-supported way of der> addressing an object of an arbitrary size in bits. And that der> would mean that bytes of any size *are* individually der> addressible. "Addressable" is a somewhat slippery concept. In the PDP-10, the architecture description clearly is in terms of 36-bit words as the addressable entity. Loads and stores act on them, memory addresses (for example in jumps) are addresses of 36-bit words, and so forth. But yes, you could claim that the byte operations "address" smaller units. A PDP-10 person would argue they don't -- they address words, and then extract or insert the smaller bytes. CDC 6000s have something analogous, a set of character instructions that interpret 60-bit words as collections of 10 6-bit characters. I don't think a strict literal reading of bits of spec will give you clean answers. You have to go by what the intent of the designers was when they created their models. For example, older Alphas can't load/store bytes either, you have to extract or insert them. But the memory addresses, at least as seen by the program, are considered to be byte addresses, so one would call an Alpha byte-addressed even though it can't load and store bytes. Maybe a good test is to look at program addresses. If those look like byte addresses -- though often they will have alignment rules -- then I'd call the beast byte addressable. By that test, Alpha and PDP-11 clearly are, and PDP-10 and CDC 6000 clearly are not. (That assumes von Neumann machines -- it doesn't help with Harvard machines.) der> There even are relatively modern machines which don't fit it der> very well. Some DSPs, for example, have 32 bits as their der> smallest directly addressible unit. Some don't even use power of 2 word lengths, e.g., the 24 bit Motorola ones. paul

der Mouse wrote: Umm words... it has six bit bytes. I think the lack of 18 bit byte cpu's has limited the use of 9 bit bytes. ( No comment from any 36 bitters ) I belive so, but I have not programmed a 10. I suspect this is in regards to string operations rather say accessing character sized data data. Two different things. Well in most cases a byte is a unsigned 1/2 half word. I still like view of the PDP-11 a byte is signed data. I think the lack of real byte access has forced the C standard to have unsigned bytes because the machines ( 8080,Z80) can't handle real bytes . It is word access I found the problem , not byte acess in the smaller machines a problem. As for the 386(+) I can say it still needs 8080 style code generation for simple compilers and compilers provide it. IE pesudo code. LD A,(FOO); LD B,BYTE(BAR);CLR B_HIGH;ADD A,B;ST A,(FOOBAR); Ben alias woodelf

Sean 'Captain Napalm' Conner wrote: Now they default to bloat or C++ or the 'NEW' standard. I read the C-bible once ... C was clean on the PDP-11 but not so any more. What I did notice is how improved basic hardware has defined the basic language one programmed in. 8080/8088 languages all have seem to very verbose and very primitve with very few operations. PL/M-8080 and PASCAL-8088. The 6502/6800 ended primary BASIC machines. The 6809 BASIC/PASCAL but better basic/pascal with OS/9. Every thing else got programmed in assembler. Note this does not cover Mini or bigger computers. Ben Alias woodelf

By the "byte = addressing unit" definition? It's been a while since I had a PDP-8 (I had an -8/f but I long ago gave it to a collector much more serious than I), but I'm fairly sure the addressing unit was the 12-bit word. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Ah, I like my morning "serial" to be "byte-sized"..... All seriousness aside, here in California, the cultural and computing center of the universe (you're suppose to laugh at this point), a "byte" was always 8 bits, half-word was 16 bits (or a short-word) and a word was 32 bits (or a long-word). On a 64 bit machine a byte was still the same but a "word" doubled. But throughout the known universe a "nybble" (or nibble) was always 4 bits (reference: reality and the Computer Webopedia.....). Let the bludgeoning begin.... Best regards, Steven C.

der> This must be a different California from the one that developed der> 4.3BSD for the VAX, a machine on which a byte is 8 bits, a word der> 16, and 32 is a long (or more formally longword) - terminology der> inherited in large part (in toto?) from the PDP-11 and for some der> reason I do not understand not updated to match the VAX. "word" for 16 bits and "longword" for 32 bits IS the VAX terminology. The VAX kept the PDP-11 terminology for the simple reason that the VAX was supposed to be seen as an upward compatible extension of the PDP-11. That's clear from the PDP-11 instruction set emulation, of course. It's also clear from the data formats used -- not just the integer data but also F and D float come straight from the PDP-11, even though on a VAX those layouts look very contorted. paul

Actually, the switch to the eight bit byte (I am of the camp that a byte is 8 bits by default, then adjust to suit) was dictated not by characters, but by numbers - the vast majority of data in the 1960s was BCD. Six bit is not very efficient for handling BCD. William Donzelli aw288 at osfn.org

Very inefficient. I hope you are not serious. Back in the 1960s, most data was numeric, due to banking. It may still be the dominant form (with maybe porn mpgs a close second). Each field of a database might have 10, 12, perhaps 16 BCD characters. Why on Earth would you want a sign bit associated with each one? If the field even needed a sign, only one would be needed. Parity? That is the job of the memory controller - having the processor figure out parity is just a waste of CPU. You need to realize that back in the 1960, each bit was counted with a price tag. A medium sized mainframe might only have 64K with a few tens of megs on disk. A batch might take all night to run, with no time for fooling around with extra bits. Basically, sixbit died when it should have. The DEC 36 bit line suffered the PDP-6 was being wheeled out. The S/360 made the world 8 bits, and signed the PDP-6/10s death certificate.). I don't understand this - clarify? William Donzelli aw288 at osfn.org

It is still very inefficient, with lots of wasted bits. It would not matter with a small machine like a 1620, but it does when the system gets larger. Even a small S/360 dwarfs a 1620. All those wasted bits add up. Parity checking is the job of the memory controller, not the processor. In fact, I am having a hard time thinking of a processor that did its own parity checking in software (yes, I know any processor could do it, but did any really do it?). Even if the parity checking is a lowly 74180, like in a microcomputer - it is still not boggin down the processor. The processor really doesn't need to know about parity, unless things go bad. 9 is even more inefficient. Some Univacs. Going back a few days to a previous thread about books, I suggest you read pages 148 and 149 of *IBMs System 360 and Early 370 Computers*. You may then see that there was no conspiracy against sixbit. William Donzelli aw288 at osfn.org

On Tue, 15 Mar 2005 07:21:42 +0100, woodelf <bfranchuk at jetnet.ab.ca> wrote: The 1620 was one of the first computers I used, but only at high-level (FORTRAN II). Compiling was interesting - put the source cards in the reader, punch out an intermediate deck, then pass both through for the second pass. I used it for my physics lab tests, plotted nice graphs on the Calcomp drum plotter. We also had a line printer making 50 lines per minute. I never saw one like it, characters were on quarter-circle segments which rotated back and forth. The Univac 1107 was a more impressive beast, with both a drum storage and a drum printer. One of my major goofs was when I first used the drum, not knowing that it did not write any end of file marker. Computer time was valuable in the sixties, and my program was reading from the drum for 20 minutes before the operator terminated it. My favourite old big iron is the NCR 315. I worked for NCR Norway, who hade one in their data processing center. The 315 was, of course, a BCD system. It had 12-bit bytes (which were calles slabs, since the byte term was not established when it was new), and 24-bit words. I just found a couple of old pictures of the operator looking helplessly at a mess of magnetic tape. The really cool thing was that most of the input came from OCR - cash register journals written with National Optical Font. Scanned by a rotating drum with a tiny diamond-shaped opening and a photomultiplier inside. -- Bj?rn

Rumor has it that William Donzelli may have mentioned these words: 8085? There's a P bit in the condition code register (in 6809 speak) -- I think it's called the PSW -- Program Status Word? I'm just beginning learning assembly on my Tandy 10x/200 machines... Anyway, there are several arithmetic operations that automatically set the Parity bit and there are branch and return instructions that utilize the status of the P bit. Altho it's not a *huge* need, it can be handy for serial I/O... that would be a function that uses parity, but is not reliant on the memory controller. Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger | "Bugs of a feather flock together." sysadmin, Iceberg Computers | Russell Nelson zmerch at 30below.com |

interconnect. the chip. I don't think that the code density was that bad since it was a two address instruction. If you consider at the time most computers had the power of a 4 function calculator with tiny amount of data memory the base machine with 20,000 digit memory was a lot of memory. What was real inefficient was converting from internal codes to external coding like printers, paper tape, punch cards all with different formats. (I don't have one, I just read the book about it)

Sorry, minor nit... The first 20K characters of memory resided in the CPU cabinet, up to 40K characters of optional add-on memory resided in the external cabinet. Cheers, Lee Courtney CHM 1620 Restoration Team Member

William wrote: That originated with the IBM 7030 Data Processing System (Stretch), introduced in 1961. It was also the first system to use ECC memory. Eric

I don;t know much about IBM stuff, but I do know that the HP9100 calculator had 6-bit memory locations (this is obvious from the schematics of the memory data board, from the fact that the main CPU register (register '2', for some odd reason) is 6 bits wide, etc. These were used in 2 ways. Either to store a user keycode (there were 64 keys [1]), or to store a BCD digit. I seem ro rememebr in the latter case, the 2 extra bits were a sign bit and a blanking flag. [1] yes, I know the 9100B has 65 keys. 2 of them are wired electrically in parallel and send the same code. One is 'hyper', the other is one of the memory transfer functions. If that keyvcode is followed by a trig function, it's taken as 'hyper'., if it's followed by an address, it's the memroy function. -tony

The VAX likewise. But those take multiple operands which collectively name the bits to be operated on. The description of the -10 as I read it implied that there was a single object, defined by the hardware, which encapsulated the word address, bit number, and size, which sounds way too much like a bit address. (You could assemble such a thing for the VAX or the 68k, but the hardware wouldn't understand it; you'd have to pull it apart into individual operands for the instructions.) Now, it may be that I misunderstood the description of the PDP-10, and what it actually has is instructions like the VAX or 68k, in which case my point is a non-point. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Mon, 14 Mar 2005, Eric Smith wrote: Yeah, why is everyone so hung up on defining "byte"? It's not like it's part of some natural order. It's whatever the designers made up off the top of their head for some particular task. It's utterly arbitrary. There's varied interaction with the 'character' unit over time, but the two are not the same. Sometimes they coincide; often they do not. And with UNICODE, who cares any more? Byte don't mean shit no more, it's just an historic leftover. * When you ask how many bits in a byte, you have to ask "for what machine?". 6-bit characters encompass the old ITA2 (aka "baudot") teleprinter codes, which were five bits (*) plus a state maintained in parallel in both sender and receiver (aka FIGS and LTRS). Five bits fits the roman alphabet 26 letters plus a few punctuation characters. (*) Rarely did anyone people before approx. WWII consider the five time intervals that make up the data portion of a telegraph/teletype character to be "bits". That's a modern interpretation.

On Mon, 14 Mar 2005 11:52:06 -0800 (PST) "Eric Smith" <eric at brouhaha.com> wrote: Lots of embedded controllers, including some of the 4-bit ones that I've programmed professionally (8 bit byte ??!!??) have bit manipulation instructions. This is one of those discussion threads where the stuff people bring up is more interesting than the actual issue of 'the size of the byte.'

Bj????rn> On Mon, 14 Mar 2005 13:26:23 +0100, Johnny Billquist Bj????rn> <bqt at Update.UU.SE> wrote: Bj????rn> From Donald Knuth. That's nice. But while Knuth is an authority on many things, he's not necessarily an authority on that. By that definition a PDP-8 byte would be 12 bits, which is clearly not how the term is used there. (Then again, on a CDC 6000 the term "byte" does mean 12 bits, it's the PPU's addressable unit. Hm.) Bj????rn> It does not matter if you do not find it usable, as long as Bj????rn> it IS the traditional definition. The PDP 10 came long after Bj????rn> it had been established. Huh? Knuth's "Fundamental Algorithms" came out well after the PDP-10 (never mind the earlier PDP-6, which is the same architecture). Bj????rn> The most interesting byte is the one Knuth used in his Bj????rn> abstract MIX machine, which he came up with when he was here Bj????rn> in Oslo. To drive home the point that bytes were not Bj????rn> dependent upon any particular hardware implementation, he Bj????rn> defined it as able to hold unspecified information, but at Bj????rn> least 100 different values. I would have thought most people Bj????rn> here had read his "Fundamental Algorithms"? Yes. That's a really cute definition, but it certainly has not been applied anywhere. paul

In message <op.sno3dpaxisslla at yngve.home.norbionics.com>, =?utf-8?Q?Bj=C3=B8rn? = writes: Was it a translation issue? Volume 1 was originally published in 1968. The trigger for developing TeX was the galleys for the second edition of Volume 2. His reaction was that if his books were going to look like that, it was time to stop writing! Fortunately for us, there's probably no one better at mastering the history of a technology, distilling it to its essence and building a new application on it. The set of Vols 1-3 I got for high school graduation in '80 is all done pre-TeX even though Knuth had an early version running in '78. Brian L. Stuart

Bj?rn wrote: The PDP-10 uses the PDP-6 architecture, which offered variable-sized bytes when it was designed in 1963. I do not think that any fixed byte size was firmly established at that time; in fact, available evidence suggest that a variable byte size was prevalent at the time. Even by the time of the first PDP-10 introduction in 1968, the size of the byte had not been standardized industry-wide, although it was moving in that direction. Thus the PDP-10, far from contradicting a traditional definition of byte, was in fact perpetuating the traditional definition. The first computer to use bytes with that name was the IBM 7030 Data Processing System (Stretch), which was designed from about 1957 to 1961 and introduced in 1961. Stretch used instructions that could address variable-sized fields that were subdivided into bytes of from 1 to 8 bits, though they sometimes referred to an entire field longer than 8 bits as a byte. IBM didn't standardize on an 8-bit byte until the introduction of the System/360 in 1964, and I'm not aware of any other vendors having standardized on 8 bit bytes before then. In fact, the PDP-6 is the only non-IBM machine from 1964 or earlier for which I've seen the manufacturer reference bytes at all. Eric References: PDP-6 Handbook, Digital Equipment Corporation, 1964 http://bitsavers.org/pdf/dec/pdp6/F-65_PDP-6_Handbook_Aug64.pdf Planning a Computer System, ed. Werner Buchholz, McGraw-Hill, 1962 http://ed-thelen.org/comp-hist/IBM-7030-Planning-McJones.pdf