# Why was the maximum byte size of 8 bits on IBM 7030?

As far as I know, IBM 7030 used term byte. But this byte was just an imaginary term to make easier for our brain to work with bits. So it had nothing in common with a physical realization of the CPU.

Facts:

1. According to assembler manual byte had size from 1 to 8 bits and we could specify this size in the code.
2. CPU had max register size and word size 64 bits
3. Memory size was 2^18 words, so it was enough 18 bits to navigate through all the words in the RAM

Now my guesses:

1. By using asm code we could navigate to any byte inside the word, and specify byte size from 1 to 8 bits
2. Therefore, to do that we need to use 3 bits to specify byte size (form 1 to 8). Also we need 6 bits to specify byte address inside the word, since if byte size is 1 bit, then it can be in any of 64 positions inside the word

Therefore, to navigate to the particular byte we need 18+3+6=30 bits, and therefore we have 64-30=34 unused bits.

My question is:

If all my guesses are correct, why did byte has size maximum 8 bits? IBM could make it much larger. Maybe it was just a magic number?

This is kind of an extension to a [previous question]

## TL;DR:

The 7030 addressing, works for many instructions, on bit level, not words. Next to all data structures, including bytes, could be located at any bit address. All addressing was always done using 24 bit.

Byte is not a hard defined entity like today, but simply a name for a repeated bit-group (i.e. 1 or more) that is stored consecutive in memory, position and element size (and element number) is part of instructions that handle such groups.

Description of the term byte from the reference manual p.11.

From today's viewpoint these groups could be seen as a variable sized array of integers of arbitrary (but all the same) size. Something usually called a vector. And instructions working thereon are vector operations(*1). After all, a decimal number is nothing else than a vector of digits, isn't it? Likewise a string being a vector of characters. Some languages even call strings that, a vector of integers/chars/ordinals.

You need to get rid of bytes and words. Words have only a meaning for the memory interface. And bytes (on 7030) are only really meaningful when it's about BCD (well, and a few abuses thereof to do text ... and to mark sign handling in integers ...).

## Time for a Rant

(Caveat, @NoNameQA, this is not personal in any way, just a generic observation which fits here)

CPU's aren't by default the primitive cogwheel constructions as told today. Something that takes a byte, does an integer operations thereon and stores it again. Anything else are bells and whistles and FP being something like a necessary rucksack to schlepp. They can be a lot more. Anything you want them to be and the 7030 is a great example what could have been, if it weren't for the /360 normalizing all of that into a consisted and simple framework and the dreaded C to turn that in to an even more primitive pile of bytes and nothing else.

All since then was primitivizing CPUs to fit that concept of the bare minimum, just to later on throw billions and ever billions of transistors onto the resulting primitive code to make some sense of it. The same stupidity that got us RISC - don't let me start on that.

And it's the same run to stupidity that made cohorts of programmers stroke the poor little 8088 against the grain by calculating 'far' pointers. It's a frickin' 16 bit CPU, not 20 or whatsoever.

If one wants to learn about a new CPU, it might not be necessary has to drop every previous knowledge, but it helps a lot to be flexible in redefining everything. While it's thus useful to compare with previous learned concepts, there is no sense in trying to project it back. Especially not based on words. Different CPUs use different languages, and much like human languages, words can be false friends, meaning the same word (spelling/pronounciation) used in two both languages has different meaning in either. Eventually complete opposite ... a sentence already an example, as in German 'Eventuell' has a meaning of 'under certain conditions' so rather like 'maybe'. Both are based on the same Latin 'eventualis' covering somehow both meanings. And the 7030's use of byte is like a prime example of this in the computer world: It's byte is a pice of a word, and it can describe some kind of character or digit, but that's it.

So, again, DO NOT try to press new knowledge into existing. It exists in parallel and in relation, but it's almost never a sub- or super-set. And most of all, each CPU is special on it's own.

## The Details

According to assembler manual byte had size from 1 to 8 bits and we could specify this size in the code.

Using bytes was only a thing when doing operations on a set of them. Like when doing BCD calculation, a byte size of 4 would be nice, but the machine could as well operate with 6 bit BCD or 5 bit.

By using asm

Or any other language.

Therefore, to do that we need to use 3 bits to specify byte size (form 1 to 8). Also we need 6 bits to specify byte address inside the word, since if byte size is 1 bit, then it can be in any of 64 positions inside the word

You seam to be stuck by an implied byte position within a word. That is a feature (*2) of modern, canonical CPUs, but the 7030 isn't one of those. A byte (group) can start at any position regardless of the byte size.

It uses bit addressing with 24 bit.

You need to get rid of bytes and words. Words have only a meaning for the memory interface. And bytes are only really meaningful when it's about BCD (well, and a few abuses thereof to do text). The 7030 operates on a memory of bits ... 16 megabits of continuous memory. And the memory interface is made up of two 64 bit 'look ahead' registers for each access, so any data item used can spread across memory words. This hides the word structure from any data access.

Example for memory organisation from the reference manual p.17.

Only instructions are to be aligned on 32 bit boundaries. That's why the address field in branch and indexing instruction is 19 bit. This is simply done to improve performance.

Therefore, to navigate to the particular byte we need 18+3+6=30 bits,

and therefore we have 64-30=34 unused bits.

Unused by what and why?

An address comes either from one of the 16 index registers, with only the lower 24 bit used, or from within the instruction, were it may be 18, 19, 24 (see p.18 of the reference manual).

An instruction has 32 or 64 bit and will of course contain more than just an address ... most likely opcode bits to identify the instruction and its length. For byte operations like integer arithmetic, as seen here:

This includes in detail:

• 4 bits identifying this as an arithmetic integer instruction
• 4 bits specifying an index register
• 3 bits spcifying the address mode
• 6 bits defining the operand and result length in total
• 3 bits for byte size if it's a byte type operation
• 7 bits of offset within the 128 bit accumulator the value/result is to be placed
• 2 bits modifier for sign handling for either operand
• 1 bit marker for using BCD or binary arithmetic
• 4 bits specifying an index register to be used to modify length, byte size and offset.

Together 64 bits, not a single bit wasted.

If all my guesses are correct, why did byte has size maximum 8 bits? IBM could make it much larger.

Or smaller. this is not a good question to be asked on RC.SE as it asks for motivation/reasoning which is usually not preserved in full detail. In this case the reference manual (again) offers a hint when discussing BCD arithmetic and zoning:

Again reference manual this time p.58.

So one reason might have been that with values between 4 and 6 being useful for BCD, 3 bits would be needed anyway, so anything up to 8 is possible without spending more bits. And belive me, zoning was an important issue back then at the boundry between punch card processing and computers. The /360, otherwise not really into much specialized handling has in addition to all BCD instructions three instruction to handle the zone part (upper 4 bits) of a byte: MVN, MVO and MVZ.

*1 - If someone now draws a line to vector CPUs (and ultimately GPUs), he's right. One reason why the 7030 is often called the first supercomputer.

*2 - Or better drawback of the byte/word relation the /360 planted and everyone took.

• There's nothing wrong with `far` pointers on the 8088. They represent the way the platform should be used. It's `huge` pointers that completely miss the boat. Commented Jun 25, 2020 at 19:15
• @supercat The CPU doesn't know 'huge' pointers. That's a pseudo type created by software. It's about calculating the segment part of a far pointer, which is as evil as it can get. Commented Jun 25, 2020 at 19:23
• From a language terminology standpoint, a "far" pointer is a 32-bit seg:ofs pointer to a region of up to 65,536 bytes of storage which can be accessed in linear fashion by using arithmetic on just the offset, while a "huge" pointer is a normalized seg:ofs pointer to an arbitrary quantity of storage which is indexed by performing computations with both the segment and offset. Doing arithmetic on segments within something like a memory allocator isn't evil, since that's the only practical way of smoothly managing a pool of over 64K, but routinely doing seg arithmetic as in "huge" pts is bad. Commented Jun 25, 2020 at 20:04
• @supercat The CPU doesn't know a huge pointer. It's a language construct. It may be a good idea to encapsulate segment calculation in a memory manager, still it's nothing an application should do at all. An OS has to provide it. There is simply no data object of more than 64 KiB possible in a 16 bit application. Everything bigger has to be handled as a series of 64 KiB object, each maintained separate without any knowledge of relation in memory. Trust me, it's very simple to program that way. The test for pointer overflow are exactly the same as when mangling segments, but without the risk. Commented Jun 25, 2020 at 22:50
• Should programs go to the OS for every separate allocation request? If not, how should a program avoid e.g. ending up with eight OS-allocated regions, each of which has 32,000 bytes that's are longer used, one byte that are still used, and another 32,000 bytes that are no longer used. Slightly over 512,000 bytes allocated from the OS, of which eight bytes are used in eight objects, and yet no room for a 32,001 byte object anywhere. Commented Jun 25, 2020 at 22:59

As per @Raffzahn's comment on his answer to Why did IBM 7030 or IBM 360 use byte and word addressing simultaneously, the 8 is an artefact of multi-byte instructions, where there was only 3 bits to specify the skip, making it trivial to have 1-8 bits.

@NoNameQA I added more to the answer. No, 8 was simply what could be put in a 3 bit field offered by instructions that handled more than a byte at once. Essetially all instructions when the machine had to handle the advancement of bit addresses for multiple elements. Other instructions allow sizes between 1 and 64. Check teh instruction encoding shown in the manual.

I'll leave it to @Raffzahn to make a more complete answer.

• It was my question, and i did not fully get explanation. Thats why I've created separate discussion here dedicated exclusively to this topic Commented Jun 25, 2020 at 9:42
• @NoNameQA I know it was your question. As far as I can tell, the question you are asking here was answered in full in the comment I quoted in this answer. It is not a limit for "how we can address a single byte", it is a limit for "how can we operate on multiple bytes", probably leading to "no more than 8" becoming a habit. Commented Jun 25, 2020 at 9:50
• I'm sorry i did not get your explanation from the last comment. Could you please provide more detailed explanation? Commented Jun 25, 2020 at 11:30
• @raffzahn Fancy writing a longer explanation, or are you OK with me extrapolating from your comment (and, optionally, correct me if I get it wrong)? Commented Jun 25, 2020 at 12:44
• @Vatine I did as well have the impression to have this answered already, but looking thru this new question I get an Idea where the issue is - way too much stuck in today's fixed structure of bytes and words, wearas the 7030 is rather a bit addressable variable length data machine. I'll try to focus on that. I'm just not sure if it's a good idea to make two questions, as it's rather a detail to the previous. Commented Jun 25, 2020 at 17:01