Does mips have 32 bit addresses AND 32 bit instructions? - memory

I know that 32-bit MIPS instruction and memory registers are... well 32 bits... and that the PC calculates the address for that instruction in the instruction register.
My question is this: Are the 32-bit address appended to a 32-bit instruction?
Ignoring the fact that these are all zeros...
Is 0x00000000 (address) concatenated with 0x00000000 (instruction)?
For example, R-Type is
OP(6) RS(5) RT(5) RD(5) SHIFTAMMT(5) FUNCT(6)
=> 32 bit instruction
=> 000000_00000_00000_00000_00000_000000
where the address for the above is
000000_00000_00000_00000_00000_000000
Are the two 32-bit numbers concatenated together so that PC spits out 32 bits which correspond to the upper half of a 64-bit value? I often see tables that have
Address Instruction
0x00000000 0x00000000
Any help would be appreciated.

The tables you often see show the address of the instruction and the instruction itself. In memory, every word (byte) has an address that never changes. The address (the location the processor uses) and instruction (what's stored at the location) are independent.

As far as what you are asking, the instruction set is fixed length no more no less.
For some instructions addresses are contained in registers and it only takes a few bits of the 32 bit instruction to define that register.
If a register is not used as the source of an address, then a percentage of the bits in the instruction typically contain an offset, since all instructions are 32 bits the offset is most likely in units of instructions not in bytes, no point wasting those two bits. I dont remember if mips has any other encoding, if they do then it can only be a fraction of the address.
Some percentage of the bits of an instruction have to be reserved to define that instruction, based on that encoding the rest of the bits define the parameters for that instruction. There are numerous sources for these instruction encodings, in particular mips website.
(there is an exception to the 32 bit fixed length rule, they have a 16 bit instruction set, but that doesnt change how addresses are encoded, mips is not variable length like x86 or other cisc where you tack on many bytes as parameters)

Related

How byte addressing works?

I am new to computer architecture. So correct me if I am wrong.
If a memory module consists of 8 memory chips and if each chip stores 4bits per address then by applying an address to the address pin of the module I can get (8 x 4=) 32 bit from that address in the module. But byte addressing tells that every byte has an address. But here I am accessing 32bits using an address. So how is it possible?
I think if each chip stores 1bit per address then by applying an address to the module I can access 8bit or one byte.
You say each chip stores 4bits per address and you have 8 on the same address bus. It is the address bus that is the limiting factor. The address bus must have 32 lines for each byte in a 32 bit architecture to be addressable. If you have 8 chips each producing 4 bits in response to the same address, then you have 32bits per address. The advantage of such an arrangement would be the address bus lines could be reduced by 2 without decreasing the addressable range (only the resolution).
You are correct in thinking that each chip would need to produce 1 bit per address to allow byte addressing.
That's the theory, in practice I would suspect a solution could be architected where the 4 bits could be time division multiplexed making each individually accessible.
I have heard for a long time not to address less than 32 bits at a time, as that may be the smallest unit addressable. Certainly it would make sense when 2Gb-4Gb was the physical limit of 32 bit byte addressing.

How many bytes can be stored in a memory unit that uses 8 address bits and a 16 bit architecture?

I need help understanding memory. How many bytes can be stored in a memory unit that uses 8 address bits and a 16 bit architecture?
I think it's 2^8 = 256. Is this correct?
Edit: I mean 256
It depends.
Firstly "16 bit architecture" is too vague to be a helpful characterization for this problem. A characterization like that generally refers to the width of registers and data paths (e.g. in the ALU), not how memory is addressed.
Secondly, the answer actually depends on whether the addresses are byte addresses or "word" addresses. AFAIK "almost all" new processor / instruction set architectures designed since the 1980's have used byte addresses. But prior to that it was common for addresses to address words of up to 60 bits (or possibly more).
But assuming byte addressing, then an 8 bit address allows you to address 2^8 bytes; i.e. 256 bytes.
On the other hand, if we assume word addressing with a 16 bit word, then 8 bit addresses will address 256 words ... which is 512 bytes.
The base answer is the 2^number of bits. However,long ago sixteen bit systems came up with means for accessing more than 2^16 memory though segments. While an application can only access 2^16 bytes at a time, changing the values in hardware registers allows the application to change which 2^16 bytes of a larger address space are being accessed.
You typically do things like
Map buffer 1 to the address space.
Queue a read operation to the buffer.
Map another buffer 2 to the address space.
Read operation completes-map Buffer 1 back so that the data can be accessed.

how long is a memory address typically in bits

I am confused with so many terminologies that my instructor talks about such as word,byte addressing and memory location.
I was under the impression that for a 32-bit processor,
it can address upto 2^32 bits, which is 4.29 X 10^9 bits (NOT BYTES).
The way I think now is:
The memory is like an array of buckets each of 1 byte length.
when we say byte addressing (which I guess is the most common ones), each char is 1 byte and is retrieved from the first bucket (say for example).
for int the next 4 bytes are put together in little-endian ordering to compute the Integer value.
so each memory, I see it as, 8 bits or 1 byte, which can give upto 2^8 locations, this is far less than what cpu can address.
There is some very basic mis-understanding here on my part which if some experts can explain in simple terms that a prosepective CS-major student can it in once forever.
I have read various pages including this one on word and here the unit of address resolution is given as 8b for ARM, which adds more to my confusion.
The processor uses 32 bits to store an address. With 32 bits, you can store 2^32 distinct numbers, ranging from 0 to 2^32 - 1. "Byte addressing" means that each byte in memory is individually addressable, i.e. there is an address x which points to that specific byte. Since there are 2^32 different numbers you can put into a 32-bit address, we can address up to 2^32 bytes, or 4 GB.
It sounds like the key misconception is the meaning of "byte addressing." That only means that each individual byte has its own address. Addresses themselves are still composed of multiple bytes (4, in this case, since four 8-bit bytes are taken together and interpreted as a single 32-bit number).
I was under the impression that for a 32-bit processor, it can address upto 2^32 bits, which is 4.29 X 10^9 bits (NOT BYTES).
This is typically not the case -- bit-level addressing is quite rare. Byte addressing is far more common. You could design a CPU that worked this way, though. In that case as you said, you would be able to address up to 2^32 bits = 2^29 bytes (512 MiB).
For one bit, You would have 0 or 1 and For two bits, you would have 00, 01, 10, 11. For 8 bits, you would have 2^8 which is 256 address values. Address and Data are separate terms. Address is the location and Data is the content in that location. Data width(content) is how many bits you could store in one memory cell address.(Think like an apartment with bedrooms- each apartment in a building has two bedrooms)and Data depth(address) is how many addresses you would have(In a building how many apartments you would have #1 thru #1400 etc). One bit in the CPU register can reference an individual byte in memory like one number in apartment number can reference one apartment. SIMM module RAMs had 32 bit Data width and DIMM modules have 64 bit Data width. It means in one memory address in DIMM, It stores 64 bits data. How many addresses can be multiplexed by two wires (two bit processing), you could make 4 addresses. (Each of these addresses could hold 64 bits if it is DIMM module ). 32 bit processing means, 32 wires, 2^32 address options. Even though, 64 bit processing has 64 bit registers and internal bus (wires) as 64 bit, http://www.tech-faq.com/address-bus.html, address bus max is 44 bits. means 2^44 maximum addressing can be achieved by Intel Super Server CPU Itanium 2.

Endian-ness: Bits in a Byte vs. Bytes in Memory

When we say a specific architecture is either little-endian or big-endian, we are referring to the whether numerical significance is stored from left-to-right or right-to-left in memory. My question is: does this ordering refer to how bits or ordered in a byte, or how bytes are ordered in a memory?
For example, consider the number 6000=1770h=0001011101110000b. If both bits in a byte and byte in memory are little-endian, this would be stored as
00001110 11101000 = 0E E8,
if bits in a byte were big-endian, but bytes in memory were little-endian, this would be stored as (for what it's worth, this happens to be how Visual Studio seems to be telling me that memory is organized in x64 architecture)
01110000 00010111 = 70 17,
if bits were little-endian, but bytes were big-endian, this would be stored as
11101000 00001110 = 0E E8,
and finally, if bits were big-endian, but bytes were little-endian, this would be stored as
00010111 01110000 = 17 70
(Hopefully I did that right.)
So then, what do the terms "little-endian" and "big-endian" actually refer to? Do the terms refer to the ordering of bits in a byte, or the ordering of bytes in memory, or both? Furthermore, if VS tells me that, for example, 7C, is 'in' a given particular byte, do they mean that the bits that make up that byte in computer memory are literally 0111 1100, or do they just mean that the value stored in that byte is 7Ch=124, but or may not be actually represented as 7c=01111100 depending on whether or not the underlying architecture happens to be little-endian?
The ordering of bits in a byte is invisible. Since you can't address individual bits, there would be no difference between the two cases. However, you can address individual bytes, so there it does make a difference.
If we're expressing 6000 in byte-addressible memory, the high byte is 23 decimal (6000 divided by 256) and the low byte is 112 decimal (6000 mod 256). We could store this as 23,112 or 112,23. There are no other options. Only the ordering of bytes is an open choice, and this is what endianness refers to.
In memory, little-endian or big-endian is not so much left-to-right or right-to-left issue as one of addressing. In little endian, the least significant portion of data is stored in the lower addressed locations and the reverse with big endian.
The ordering occurs independently at 2 levels. As most machines address more than 1 bit at a time (recall some graphic CPUs that did have bit addresses), the address will locate a group of bits, typically 8 bits. So if the bits at address 10 are less significant than the bits at address 11, it is a little endian machine. This is generalized as byte endian-ness. The processor's characteristics define this.
The endian-ness of the group of bits, the bit endian-ness, is significant if there is a way to address them in some fashion. Some processors provide operations that use a bit level address within the byte (or word). If your programming language directly allows you to use that or hides that is another question.
In C there are bit fields such as
union u {
unsigned char uc;
struct s {
int a :1;
int b :7;
};
};
This code is non-portable because of bit endian-ness. u.uc = 7 may result in u.s.b also being 7 or something else. Typically the byte endian-ness and bit endian-ness are the same. But the compiler controls the above example.
Bit endian-ness is also significant in serial communication. As 1 bit is sent/received sequentially, its construction to/from memory needs endian-ness definition.
Conclude:
Big-endian and little endian most often refer to the "byte" level addressing. The endian-ness of the bit is typically either the same or of select importance to the programmer.
BTW, your example of "If both bits in a byte and byte in memory are little-endian, this would be stored as
00001110 11101000 = 0E E8
I would suggest is not correct as the left side and right side are using different endian-ness. Had you used the same endian-ness, you may conclude
00001110 11101000 = 07 71
For fun consider:
01000000 (big endian) has value "sixty-four" (A big endian word)
10110000 (little endian) has value "thirteen". (Thirteen is little endian word)

Understanding the memory layout of a 4-byte integer

I am working with the MIPS architecture (not sure if this is relevant since we are dealing with memory).
I am told that A 32-bit integer is in memory at physical address 0x00A0CE48.
I assume that number is 00000000111111110000000011111111.
The system is byte-addressable, what value would be at memory address 0x00A0?
I wasn't sure if the first 8 bits were at address 0x00, next 8 bits at 0x00A0, next 8 bits at 0x00A0CE, and the last 8 bits at 0x00A0CE48? I'm asking because I have to manipulate a value in 0x00A0, but im not sure what's there.
Part of the problem is to 1st assume big endian is used, then little endian.
A 32-bit integer resides in memory at physical address 0x00A0CE48. The bits within the 32-bit word are numbered 0 to 31 from least significant bit to most significant bit. The code below extracts a single bit from this 32 bit pattern and places the bit into $t4.
lui $t0,0x00A0
ori $t0,$t0,0xCE48
lbu $t4,2($t0)
srl $t4,$t4,5
andi $t4,$t4,1
The next question in my assignment is to indicate the number of the bit (0 through 31) within the 32-bit word that is left in $t4 if the memory order used is little-endian or big-endian.
On a big endian system, the most significant byte is stored first. So, assuming the value is 0x12345678, 0x12 will be stored at address 0x00A0CE48, 0x34 will be stored at address 0x00A0CE49, 0x56 will be stored at address 0x00A0CE4A, and 0x78 will be stored at address 0x00A0CE4B.
On the other hand, on a little endian system, the least significant byte will be stored first. So, 0x78 would be stored at 0x00A0CE48, and so on.
Note that if a 32-bit word is stored at address 0x00A0CE48, the next word will be four bytes later, at address 0x00A0CE4C. The arithmetic should be performed on the address as a whole. You cannot consider the bytes making up the address separately when reading from memory.
In the assembly you've posted, lui (which stands for "load upper immediate") will shift the immediate value 16 bits to the left and store it in $t0. After that instruction, the value in $t0 will be 0x00A00000. The next instruction will OR the contents of $t0 with 0xCE48 and store the results in $t0. After that, $t0 will contain your full address, 0x00A0CE48.

Resources