Why did IBM System /360 have byte addressable RAM, but didn't have 8 bits registers
These issues are unrelated.
Registers are about addressing, so they need to hold an address word. Byte addressable RAM in turn is needed to handle bytewide data - most notable characters and strings. There is no inherent need that a CPU must have byte sized registers as well.
According to wiki IBM System / 360 had only 32 and 64-bits registers for data.
(Except, the /360 had only one size, 32 bit. 64 was when combining two for a few (essentially two) instructions)
I'm wondering if they used 8-bits symbol it means that they stored it in a 32-bits register.
Well, yes, getting an 8 bit value into a register was a pain in the ass (*1)
Did they have any performance improvements for such decision?
No, as one rarely had to load/store an 8 bit value to/from a register. Registers of a /360 are meant mainly for address handling/calculation plus integer arithmetic which essentially is the same. All register to register instructions (Like
AR for adding two registers) are 32 bit only. Memory structures to interact with registers are words (32 bit) and halfwords (16 bit), the later always extended to 32 Bit when fetched (usually sign extended). Yielding for example two add instructions,
A to add a word and
AHto add a (sign extended) halfword.
Registers were (usually) never used to handle character data, as the /360 wasn't a strict accumulator (set) machine, but as well a memory to memory architecture (*2). A string would be transfered with a single
MVC dest,src instruction (*3). There was no need running a loop to fetch and transfer single bytes. Similar a string compare was done by a
CLC. This of course included logic operations as well, two strings could be ANDed, ORed or XORed. Nifty, isn't it?
It can to some degree compared with the x86's string instructions, just sans the cumbersome setup.
In fact, this approach does impact performance in a positive way. String instructions formulate a task on higher level than byte access, allowing hardware to handle these strings in bigger chunks than single bytes. After all, already back then memory interface was not only independent of word size, but as well much wider. Were low end machines used a 16 bit memory interfece, high end had already in the 1970s up to 256 bit wide memory access (*4). That's 32 bytes per fetch much like modern GPU's isn't it? To transfer a 20 byte string only 2 to 4 fetches had to be made, which is way better than doing 40, isn't it (*5)?
All this came due the natural benefit of string orientated instructions, speeding up operations way before adding caches and alike. Intel's (and many modern ISA) never had that advantage and needed to invest way more into fetch/write access bundling strategies and, above all, multi level cache.
If so, why do we have 8-bits registers today?
I assume you're talking about intel x86, right?
Sorry to disappoint you, but there are none. The registers are 64 bit and so called 8 bit registers are only aliases to address part of one. These aliases are needed still needed to handle any kind of byte stream - like this web page.
In some way they can be seen as left over from history. Keep in mind, Assembler is an abstract way to look at/describe a CPU's working, in some cases representing how the underlaying hardware works, but more often it is not. Of course, one could simply make up a 'new' Assembler syntax (*6) eliminating them. Maybe like Motorola's modifiers
.b or alike. It's always good to not confuse the logic model presented by books and Assemblers with implementation.
Moreover, do we have any performance improvements if we store ASCII symbol in 8-bits register vs 32-bits register?
As said, there are none, the 8 bit values get always promoted into the 32 (64) bit registers. But there is an advantage not visible from the ISA/Assembler level: Designers may give certain instructions a shorter encoding. So for example Adding an immediate to a register will take 2 bytes opcode plus the value, while doing so with AL/AX only takes 1 byte plus value.
Up to the 80286 there were only two basic data types, 8 and 16 bit. When the 386 was to be made they had the need to introduce another basic data type for 32 Bit. But there was not way to squeeze it into the encoding, except adding a prefix byte for it. Not really cool, as it would bloat 32 bit code with next to all register instructions needing another byte for encoding. So they settled to a mode were all previous 16 bit encodings now meant 32 bit (*7), while keeping 8 bit as first class member for character handling (*8).
So there is the advantage: In addition of lower amount of data to be moved, the instruction doing so are shorter as well, resulting in less code fetch and thus higher thruput. Which of course still does not make up the penalty of not having simple to use high level string instructions.
*1 - Ok, not really, but it (usually) took two instructions for clearing and inserting the character:
XR Rx,Rx and
*2 - The /360 is essential a unification of the three prior CPU families (1401, 1620 and 7090) with different structures (decimal character, decimal numeric and FP/integer word orientated). Yielding a machine which is less of a one size fits all, but a toolset covering all. One could see it as unifying five ISA approaches:
- Floating point
- Decimal (character-oriented)
- Decimal BCD
- String processing
*3 - Well, up to 256 bytes that is. for more than 256, a
MVCL had to be set up, able to handle up to 16 Magebytes in a single instruction - including fillup mechanic :)
*4 - Today one might call it the memory bus, except, it was't a bus, but the interface between memory and CPU, handled by a dedicated unit on each side.
*5 - Due the way the micro program was structured, the average number of fetches was only slightly above 2. close to optimum.
*6 - Like NEC did for their V-series 8086 compatible CPU's. Here the registers were named AW...DW instead of AX..DX, IX/IY instead of SI/DI, DS0/DS1 instead of DS/ES.
*7 - It's WAY more complicated than that, but that's material for a question of its own (at least one).
*8 - Noone back then would have thought we could settle so soon for UCS2 or UCS4