The Museum of HP Calculators

HP Forum Archive 14

 I have a question about "Word Size" and MemoryMessage #1 Posted by Bill Platt on 27 July 2004, 4:31 p.m. I am simply not well versed in the hardware aspects of computing. But occasionally, I see limitations on functionality which seem like they must be hardware dependent. Examples: 1. 33s having a 255 character limit for an equation; 2. 12c platinum having problems with goto if the line number exceeds 254? (255? 256?) Since 2^8 = 256, does this mean that such limitations are hardware dependent? 3. Switching "Modes" in casios, or the 30s, causing all memory to be lost. How do I educate my self about this stuff efficiently? And about "words" "nibbles" etc? Regards, Bill

 Re: I have a question about "Word Size" and MemoryMessage #2 Posted by John Limpert on 27 July 2004, 4:56 p.m.,in response to message #1 by Bill Platt It isn't really a hardware dependency. It has more to do with the design of the software. For example, most computers use the 8-bit byte, or octet, as the base unit of storage. Lets say that we want to design a data structure for storing text strings. One popular way of doing it is to allocate N+1 bytes to store a N byte text string. The first byte is used to store the number of bytes used by the string. The rest of the bytes contain the text. By allocating one byte for the length, we have limited the size of text strings to 0..255 bytes. If we needed to support longer text strings, we could use more memory to record the length. Two bytes for the length would support text strings of 0..65535 bytes. Four bytes for the length would support text strings of 0..(2^32 - 1) bytes. We have lots of choices for our data structure. Which one is the best? That depends on our goals. Using a single byte for the length is efficient in space and the time it takes to manipulate strings, at the expense of limiting the maximum string length. Using four bytes for the length allows for nearly unlimited string size, but it increases the memory overhead for each string and it takes additional time to manipulate strings. For a pocket calculator with limited memory and a slow CPU, one byte is probably the best choice. For a desktop computer, four bytes would be better. Each choice involves a complicated set of tradeoffs.

 Re: I have a question about "Word Size" and MemoryMessage #3 Posted by James M. Prange on 27 July 2004, 8:39 p.m.,in response to message #2 by John Limpert I'll add that in the RPL models (28, 48, and 49 series), the smallest addressable unit of memory is a nibble (4 bits or 1/2 byte) instead of a byte. Memory addresses on these models are always 5 nibbles (20 bits), so they can access up to 2^20 (1048576) nibbles (524288 bytes or 1/2 Megabyte) without bank switching.

 WORDs and DWORDsMessage #5 Posted by Cameron on 28 July 2004, 9:58 a.m.,in response to message #4 by Vieira, Luiz C. (Brazil) To quote someone else: "the wonderful thing about standards is that there are so many to choose from." (that's an IT joke; apologies to the engineer community). About the only three terms that we can call unambiguous have been mentioned by John. James and Luiz: octet, byte and nibble (or nybble). As has been said, the first two describe a logical collection of 8 bits and the third is half that size. I say *logical collection* because none of these terms tell us anything about the way the bits are generated, moved, manipulated or stored by a piece of hardware. The term WORD usually means the logical collection of bits that a given (processor) architecture can sling around most efficiently. You can think of it as an architecture's data atom. You can inspect a word's sub-structure and you can "weakly bond" more than one of them together but they remain the fundamental unit that an architecture is designed to process. Double-words and quad-words, as their prefixes imply, are simply collections of bits that are comprised of 2 and 4 atoms (words). Some architectures are able to manipulate these multi-word quantities more efficiently than arbitrary collections of words which is why there are specific terms that apply to them. Higher up the descriptive food chain we have much more ambiguous terminology. Terms like int, short and long spring to mind (only because I often program in C++). The size (in bits) of these is only defined for a particular platform and can, as Microsoft and Intel have shown us) change across incarnations of the (allegedly) same platform. I often refer people to the Free On-Line Dictionary of Computing as both a reference and a fascinating interconnected web of computing terminology. Cameron PS: Luiz you never type too much. ;-)

 Re: Bytes and octetsMessage #6 Posted by Steve A on 28 July 2004, 10:44 a.m.,in response to message #5 by Cameron Quote: About the only three terms that we can call unambiguous have been mentioned by John. James and Luiz: octet, byte and nibble (or nybble). The first time I saw the word 'octet' used was in the internet RFC docs. I assume that term was used to differentiate an 8 bit value from a 'byte' which could be a 7, 8, or 9 bit value. I know some mainframes have a 9 bit byte. I don't know if any computer used a 7 bit byte, but in an 8 bit system with one bit used for parity, you only have 7 bits left for data. So... byte is not such an unambiguous term. However, whenever I use it, I mean 8 bits. Steve.

 Bytes != OctetsMessage #7 Posted by John Limpert on 28 July 2004, 11:04 a.m.,in response to message #6 by Steve A Some older computers used 6-bit bytes. I've seen computers where the smallest addressable chunk of memory is 32-bits or 64-bits. If UniCode ever becomes universal, we may see computers with larger byte sizes.

 bits and piecesMessage #8 Posted by Steve A on 28 July 2004, 11:36 a.m.,in response to message #7 by John Limpert I guess we're left with just the unambiguous 'bit', then. Steve.

 Re: bits and piecesMessage #9 Posted by James M. Prange on 28 July 2004, 1:43 p.m.,in response to message #8 by Steve A Quote:I guess we're left with just the unambiguous 'bit', then. "Octet" also seems unambiguous to me. I overlooked that bytes are sometimes not octets, but I believe that that is indeed the case. So is a nibble (or nybble) alway 4 bits or is it 1/2 byte? Maybe I should say "quartet"? Regards,James Edited: 28 July 2004, 4:34 p.m.

 Re: bits and piecesMessage #10 Posted by Steve A on 28 July 2004, 9:56 p.m.,in response to message #9 by James M. Prange Quote: "Octet" also seems unambiguous to me. Yes, that was a failed attempt at humour. I was suggesting that only the very simplest things can be defined with absolute accuracy. If I ever invent a technical term, I hope it's at least as amusing as 'nibble'. Steve.

 The "bit" and the "binit"Message #11 Posted by Andrés C. Rodríguez (Argentina) on 29 July 2004, 10:44 p.m.,in response to message #8 by Steve A Well, we may enter the almost endless discussion about the difference between a "binit" (binary digit), which is something like a memory cell, disk spot, etc., that have two possible states (1 and 0); and the real, purest definition of "bit" as a quantity of information: the amount of information needed to reduce uncertainty of an information source by a half. This last definition comes from Information Theory. For instance, a circuit, a magnetic spot, an optical mark with two possible status will have the "potential" to carry up to one bit of information; but if such information is already known, and hence redundant, our "binit" will find itself carrying less than one "bit" of information. The usual metaphor is that a "binit" is like a bottle which can contain up to one "bit" of information (content); but not every bottle carries its maximum load all the time...

 Re: The "bit" and the "binit"Message #12 Posted by Garth Wilson on 30 July 2004, 12:37 p.m.,in response to message #11 by Andrés C. Rodríguez (Argentina) I've never heard that about the binit and the bit. I've been at this gave for over 20 years. We were taught in school in the early 80's that "bit" was short for "binary digit," a definition which I find adequate.

 Once upon a time, when IT was "information theory"...Message #13 Posted by Andrés C. Rodríguez (Argentina) on 30 July 2004, 1:59 p.m.,in response to message #12 by Garth Wilson I accept I went a little off with this matter because, all the time, all we (me included), use the "popular" definition of "bit". I was an electronics engineer student in 1980, when I attended a course on communications systems and information theory. I think (from memory) we used a classical book by Norman Abramson, which covered these subjects; and also presented the main ideas from the Nobel laureate Claude Shannon (father of Information Theory, the scientific approach to information). We had very heated discussions with the professor, because the "binit" was known by none of the students. But, in the end, he convinced us about the difference between the "binary digit" and the "amount of information" it may bear. I think that, to avoid the confusing statement "Not always a bit is worth a bit", they switched to "Not always a binit is worth a bit". There were enlightening discussions about the "entropy" of an information source, redundancy, coding efficiency; the differences between "bit per second" and "baud rate", error correcting codes, etc. Most of those theoretical issues of the '50s were subjects of scientific research between the '60s and the '70s; become critical features of consumer products in the '80s and '90s (fax, CD players, hard disk drives, DVD, dial-up modems); and are now "taken for granted", passing almost unnoticed by millions of users of PCs, communication devices, and the Internet.

 Re: Once upon a time, when IT was "information theory"...Message #14 Posted by James M. Prange on 30 July 2004, 7:02 p.m.,in response to message #13 by Andrés C. Rodríguez (Argentina) I've never heard of a "binit" before, but I suppose it depends a lot on how the potentially available information is being used. For example, a nibble has 16 possible values, but when used as a BCD digit, only 10 of them are meaningful, and when used as a sign, only 2 of them are meaningful. I wonder how a processor being used in decimal mode would respond to invalid nibbles. Regards,James Edited: 30 July 2004, 7:03 p.m.

 Re: Once upon a time, when IT was "information theory"...Message #15 Posted by Andrés C. Rodríguez (Argentina) on 31 July 2004, 11:35 a.m.,in response to message #14 by James M. Prange Just to benefit from your well chosen examples: A "physical" nibble (4 "bits" or binits) will contain: - 4 bits of information when used to keep an hexadecimal digit. - 3.322 bits of information when used to keep a BCD digit (isn't it reassuring to see that 3 bits are not be enough for this?). This is kind to have four bottles, where three are full, but the last has been filled up to only one third of its capacity. - 1 bit of information, when used to keep just a two-valued sign; no matter how much circuitry is used for that matter. The bit scale is logarithmic: In the case of the BCD digit, the information content is calculated as the base-2 logarithm of 10 (the permitted values count). The information content of the "sign" is just the base-2 logarithm of 2, which is 1 by definition.

 Re: WORDs and DWORDsMessage #16 Posted by James M. Prange on 28 July 2004, 4:42 p.m.,in response to message #5 by Cameron For the Saturn processor, a "W" word field is used to refer to an entire 64-bit (16-nibble) "working" register or "scratch" register. These 16-nibble registers are sufficient for holding "real" numbers in decimal mode, where each nibble represents a BCD digit; nibbles 0-2 for the "X" (signed) exponent field, nibbles 3-14 for the "M" mantissa field, and nibble 15 for the (0 for positive, 9 for negative) "S" sign field. Interestingly (to me), an entire nibble is used for the sign, although a single bit would be sufficient. But note that the "long real" numbers used internally need 15 nibbles for the mantissa, 1 nibble for the sign, and 5 nibbles for the signed exponent, so can't fit into a single register. The Saturn processor has several 20-bit registers, and the 64-bit registers each have a 20-bit "A" ("address") field, nibbles 0-4 of these registers. The SysRPL terminology for a 20-bit unsigned integer is "internal binary integer", or "bint" (not the same as a UserRPL binary integer, which is a "hex string" or "hexs" in SysRPL terminology). Note that bints are used in SysRPL for many purposes besides memory addresses; in general where they're always sufficient to describe a quantity. For example, a bint is always sufficient to specify the length (in nibbles) of any object that can possible fit into memory, any address, or any length (again, in nibbles) of memory. Other Saturn registers are 16-bit, 12-bit, 4-bit, and 1-bit. Note that the Saturn processor is based on a 4-bit bus, so 4-bit quantities ("nibbles") are particularly important. A nibble is the smallest addressable unit of memory, and any memory operation always involves a whole number of nibbles; you can't read or write partial nibbles. Also note that a nibble represents one hexadecimal digit, or, in decimal mode, one BCD digit. Regards,James Edited: 28 July 2004, 11:03 p.m.

 Re: I have a question about "Word Size" and MemoryMessage #17 Posted by Dave Shaffer on 28 July 2004, 5:18 p.m.,in response to message #1 by Bill Platt I think the word "byte" originated with IBM for their 360/370 series computers (mid- to late-1960s). At this time, as others have already noted, a computer "word" could be almost any size, depending on what brand of computer you were talking about. An 8-bit byte was the right size for one character as far as IBM was concerned, since it allowed all 256 characters which comprised the extended ASCII set - "EBCDIC" (extended binary-coded decimal information(?) code(?) ) as IBM called it, if I remember correctly. I suspect, but don't know for sure, that "byte" was a play on words: it was clearly more than a bit, and you bit off a "byte" to chew (process). Hence, the logical successor: the nibble ( = half a byte/bite ). Thus, originally at least, byte meant exactly 8 bits, and a nibble was 4 bits. If you need parity for error correction, then adding a parity bit to each byte made it 9 bits in size. This was certainly done when the IBM 360/370 computers wrote tapes - hence the "9-track" tape drive, with 8-bit bytes plus a parity bit laid down across the tape. Previous tape drives were 7 track (and I have no idea how they formatted the bits!). This made exchanging tapes between different computer systems somewhat of a challenge in the late 60s, early 70s!

 7-Track TapeMessage #18 Posted by John Limpert on 28 July 2004, 10:45 p.m.,in response to message #17 by Dave Shaffer I've used old UNIVAC systems that had 7-track tape drives. They used a 6-bit (FIELDATA) character code that predated ASCII and EBCDIC. Seven tracks was a good match for a character plus a parity bit. CDC and DEC also used 6-bit character codes on some of their older systems. Some systems, like the DEC PDP-10, a 36-bit system, supported more than one size of character. You could use the character set that was the best fit for your application.

 EBCDIC and FIELDATAMessage #19 Posted by Karl Schneider on 30 July 2004, 2:46 a.m.,in response to message #18 by John Limpert John posted, Quote: I've used old UNIVAC systems that had 7-track tape drives. They used a 6-bit (FIELDATA) character code that predated ASCII and EBCDIC. Seven tracks was a good match for a character plus a parity bit. I can relate to that... In the mid-eighties, I maintained software written in Fortran '66 and Fortran '77 for Sperry and Sperry*Univac mainframes. The Fortran '77 software (which Sperry caleed "ASCII Fortran") utilized the ASCII character set. The Fortran '66 software ("Fortran IV") utilized FIELDATA. IBM mainframes of the era utilized EBCDIC. -- Karl S.

 Re: EBCDIC and FIELDATAMessage #20 Posted by David Smith on 30 July 2004, 11:35 a.m.,in response to message #19 by Karl Schneider You can't forget Control Data and their 6 bit characters (packed 10 per word). They uses an escape character (76 octal) to handle lower case.

 EBCDICMessage #21 Posted by Paul Brogger on 29 July 2004, 11:07 a.m.,in response to message #17 by Dave Shaffer Finally, a subject I know too much about! EBCDIC: Extended Binary Coded Decimal Interchage Code On a related note, one of my favorite bits of computer humor is "EBCDORK: Extended, Binarily Coded, Decimally Organized, Rbitrary Kludge". IIRC, I read it in Tom Nelson's "Computer Lib/Dream Machines" book.

 Nice to hear from you Paul..Message #22 Posted by Matt Kernal (US) on 29 July 2004, 2:22 p.m.,in response to message #21 by Paul Brogger I was just wondering "wonder where Paul is?", and was about to send you note to ask if you're OK. Glad to see you posting again. Don't be a stranger. Matt ps. Somebody here was asking how to take apart a 49G+, and I thought of the photos you took of your 49G+ "under the knife".

 49G+ Pix are Still AccessibleMessage #23 Posted by Paul Brogger on 29 July 2004, 4:45 p.m.,in response to message #22 by Matt Kernal (US) Thanks for the kind words. Dave has graciously taken on hosting those images, and they're available via the MoHPC Articles Forum, in Article 408. (In case no one mentioned it at the time.)

 Re: I have a question about "Word Size" and MemoryMessage #24 Posted by DavidY on 28 July 2004, 5:56 p.m.,in response to message #1 by Bill Platt Generally, limits on the number of characters allow (1.e.255) came from the way the operating system treats character arrays and how it handles the pointers for such arrays. The origional 255 character limit came from the fact that programmers using the early microprocessors were faced with size limits. It was less wasteful and easier to process the string pointer if it would fit into one memory word--and since most common processors were using 8-bit words this mean 255 characters max (2^8=256 which equals 255 characters+1 index byte). In fact in some earlier (assembly or higher level) code you only got 253 characters: 1 index byte, 253 characters, and 2 null (0) bytes to indicate "end of string". In calculators, often using serial memory bus structure, things were more efficient if you could keep pointer structures small--moving 8 bits was a lot faster than moving 16 or more. In point of fact the 33s "shouldn't" have such a limitation as the ARM cpu can handle much more memory than the origional 33 and I believe has a larger word size. But--since it appears that the "33S" is really code running on an emulator running in ARM microcode it simply carries over the old limitations.

 33s ProcessorMessage #25 Posted by bill platt on 29 July 2004, 9:42 a.m.,in response to message #24 by DavidY Hi David, That is a good expmanation for the 255 character business. however, I do believe that the 33s is *not* an ARM CPU--rather, it is some other, older CPU--there is a thread in the archive, and in C.S.hp48 about this. Regards, Bill

 Re: 33s ProcessorMessage #26 Posted by John Limpert on 29 July 2004, 10:49 a.m.,in response to message #25 by bill platt I was just looking for that information yesterday. It uses a SunPlus SPLB31A. The manufacturer's web site wouldn't let me download the spec sheet, but it did say that it was an 8-bit CPU with 256KB ROM and 4288 bytes of SRAM. It also has an integrated LCD controller.

 Re: 33s ProcessorMessage #27 Posted by Norris on 29 July 2004, 4:15 p.m.,in response to message #26 by John Limpert CPU is shown as an "8502" at: http://www.hp.com/calculators/scientific/33s/specs.html

 Re: 33s ProcessorMessage #28 Posted by John Limpert on 29 July 2004, 5:54 p.m.,in response to message #27 by Norris That's interesting. The 8502 is listed as being an enhanced version of the extremely popular MOS Technologies 6502, used in the Apple II and many Commodore computers. It's also listed as the CPU in the HP-30S, a low-end algebraic scientific calculator. It's amazing how long some of these CPUs have been around. I can remember lusting after a 6502 based single board computer (KIM-1) when I was a teenager. It had a hex keypad and six 7-segment LEDS. It was a real computer, minus case and power supply, for less than \$300.

 Re: 33s ProcessorMessage #29 Posted by HrastProgrammer on 31 July 2004, 4:33 a.m.,in response to message #28 by John Limpert It's amazing how long some of these CPUs have been around. I can remember lusting after a 6502 based single board computer (KIM-1) when I was a teenager. What amazes me is that HP dropped further use of their excellent Saturn CPU (for this kind of applications, like calculators and BCD arithmetic) in favor of CPU that is basically 6502. It seems like Saturn is too old for their new calculators but, as far as I know, 6502 is much older and all this doesn't have much sense from my point of view. If they kept Saturn, they wouldn't have to rewrite everything and produce a lot of bugs and differences. Furthermore, Saturn has enough power for some HP-15C, HP-16C, HP-41C/CV/CX, HP-42S and HP-71B based calculators in the future.

 Re: 33s ProcessorMessage #30 Posted by . on 31 July 2004, 4:49 a.m.,in response to message #29 by HrastProgrammer A few people from HP have said in the past, that fabbing a new CPU would cost at least half a million dollars - too much of an investment. The 6502 is fine for a low end scientific, and ARM makes sense for the more powerful calculators. The ARM is fairly cheap, well supported and low power. It is also much faster then Saturn - The main preformance limitation of the Saturn is the 4 bit bus, while the 49g+ uses a 16 bit bus. Also, there are many more better development tools for chips like the ARM then the saturn. With an industry standard CPU, HP can easily get faster chips later without another huge investment in refabbing the Saturn yet again. 123 to delete

 Re: 33s ProcessorMessage #31 Posted by HrastProgrammer on 31 July 2004, 7:20 a.m.,in response to message #30 by . I haven't compared Saturn to ARM but to a 6502. And Saturn doesn't need to be developed (because it was developed about 20 years ago) but just to stay in production. Saturn is a good CPU and would serve future HP calculators very well. BTW, we all know the "quality" of HP's last experiment with ARM CPU. It is called HP-49G+ ... The problem with the latest HP calculators isn't 4-bit data bus but the lack of overall production quality.

 Re: 33s ProcessorMessage #32 Posted by John Limpert on 31 July 2004, 9:16 a.m.,in response to message #31 by HrastProgrammer One problem is that HP may not be able to make new Saturn chips without spending a lot of money. Integrated circuit production lines don't last forever. They become obsolete and are scrapped. Even if you have all the original masks and layouts, switching to a new production line, using a more modern process, may require expensive revisions to make the old design compatible with the new production line. The SunPlus chip that HP is using in the HP-33S is not just a 6502. It's an enhanced 6502 core with integrated LCD controller, ROM and RAM. That's a substantial gain in integration and functionality over the Saturn, at the expense of losing software compatibility. HP may have decided that it was better to rewrite the software for the 6502 if it meant that they could use an off-the-shelf, inexpensive, all-in-one chip for their calculator.

 Re: 33s ProcessorMessage #33 Posted by Garth Wilson on 1 Aug 2004, 2:26 a.m.,in response to message #32 by John Limpert The SunPlus chip that HP is using in the HP-33S is not just a 6502. It's an enhanced 6502 core with integrated LCD controller, ROM and RAM. That's a substantial gain in integration and functionality over the Saturn, at the expense of losing software compatibility. HP may have decided that it was better to rewrite the software for the 6502 if it meant that they could use an off-the-shelf, inexpensive, all-in-one chip for their calculator. AFAIK, none of the two hundred million 6502 cores being produced every year today are limited to the instruction set or slow speeds of 25 years ago. They all have an enhanced instruction set, and most of the cores are in microcontrollers that have varying amounts and types of RAM, ROM, uP support, timers, and I/O, all in one IC. Western Design Center licenses the IP. Edited: 1 Aug 2004, 2:31 a.m.

 Re: 33s ProcessorMessage #34 Posted by . on 31 July 2004, 10:01 a.m.,in response to message #31 by HrastProgrammer "And Saturn doesn't need to be developed (because it was developed about 20 years ago) but just to stay in production." HP no longer make the Saturn - it was made my NEC for many yearsm until the production line became obsolete. A process shrink isn't easy either - the saturn is integrated on a mixed signal IC, the yorke - the analog sections mean a process change is tricky. "Saturn is a good CPU and would serve future HP calculators very well." It is good because the software doesn't need to be changed, but I seriously think modern CPUs offer much better MIPS/Watt "BTW, we all know the "quality" of HP's last experiment with ARM CPU. It is called HP-49G+ ..." What does the choice of CPU have anything to do with the poor quality of the keyboard?

 Re: 33s ProcessorMessage #35 Posted by HrastProgrammer on 1 Aug 2004, 1:41 a.m.,in response to message #34 by . What does the choice of CPU have anything to do with the poor quality of the keyboard? Nothing, really ... except that we still aren't sure if the keyboard problem is due to a bad keyboard or a firmware/ARM/emulation problem (recently there was a discussion about this on comp.sys.hp48).

 Re: 33s ProcessorMessage #36 Posted by Eric Smith on 1 Aug 2004, 3:21 a.m.,in response to message #31 by HrastProgrammer Quote: And Saturn doesn't need to be developed (because it was developed about 20 years ago) but just to stay in production. ASICs can't just "stay in production". The volume is low enough that the foundry (NEC for the Saturn parts used in the HP 48 etc.) eventually discontinues the old process in favor of newer ones. Thus to "stay in production" you need to tapeout the chip again. Even if you're using logic synthesis from Verilog or VHDL, a tapeout still costs a *LARGE* amount of money. Thus it is unsurprising that HP would prefer to switch to commercially available parts from Sunplus and Samsung. About a decade ago I worked for a company that had a fairly successful product that had been on the market for about 7-8 years. It used an ASIC fabbed by Fujitsu. By that time, the process was so old and volumes were so low that Fujitsu only did a line start every few months. When you do a line start, it takes a while to get the process parameters right, so a lot of waste is produced before anything useful. Still, Fujitsu was willing to try to make our chip. But unfortunately things were so old that two consecutive attempts at a line start resulted in zero yield. We had to scramble to replace the ASIC with a daughterboard with an FPGA.

 "Word Size"---thanks Message #37 Posted by bill platt on 15 Aug 2004, 11:04 p.m.,in response to message #1 by Bill Platt Although quite some time has passed since I started this thread, I just wanted to let all those involved in its development know that I appreciated the answers--very interesting! Best regards, Bill

Go back to the main exhibit hall