Little and Big Endian - endianness

Suppose the number Ox12345678 is stored at memory location 1000 in Big
Endian format. If the processor now assumes the data to be in Little Endian
format, what will it get if it reads (i) a byte, (ii) a half-word, (iii) a word from
the location 1000?
This is in relation to the ARM processor

If the number Ox12345678 in your question is given in Little Endian format and you store it in Big Endian format at address 1000, then the memory image at that address will be:
1000 - 0x78
1001 - 0x56
1002 - 0x34
1003 - 0x12
Now, using a Little-Endian processor:
If you read a byte from address 1000 then you'll get 0x78.
If you read a half-word from address 1000 then you'll get 0x7856.
If you read a word from address 1000 then you'll get 0x78563412.
If the number Ox12345678 in your question is given in Big Endian format and you store it in Big Endian format at address 1000, then the memory image at that address will be:
1000 - 0x12
1001 - 0x34
1002 - 0x56
1003 - 0x78
Now, using a Little-Endian processor:
If you read a byte from address 1000 then you'll get 0x12.
If you read a half-word from address 1000 then you'll get 0x1234.
If you read a word from address 1000 then you'll get 0x12345678.

Related

How to calculate number of virtual pages

virtual adress size: 32 bits
page size = 4K =2^12 bytes
what is the number of pages?
i know the answer is (2^32)/(2^12) = 2^20 but why?
i think it should be (2^32)/(2^15) because of the byte bit conversion (2^12)*(8)=2^15
Every byte in memory has a numeric address starting from 0. The CPU has one or more registers which hold the address of that one byte which is being worked upon. A register is a physical device and has limits to how large a number it can store.
virtual address size: 32 bits
This means the address register can store one address (number) which could be anything between 0 and 2^32 -1.
As the largest address that the address register can store is 2^32 -1 there is no point in having more memory bytes. Because the CPU will never be able to work with them. So in general we assume the total memory to be 2^32 bytes.
page size = 4K =2^12 bytes
The total memory of millions of bytes is actually organized in chunks called pages. Here total memory of 2^32 bytes is chunked into pages of 2^12 bytes.
what is the number of pages?
the answer is (2^32)/(2^12) = 2^20. Good job!
but why? i think it should be (2^32)/(2^15) because of the byte bit conversion (2^12)*(8)=2^15
Here 2^32 is the total number of bytes in memory. 2^12 is total number of bytes in a page. Both numerator and denominator should be in same units - bytes. So you need not convert the denominator to bits.
Note:
I have used over simplification of terms like memory, address, register etc. Many of the statements made above are not valid for a real laptop - but useful for initial learning.

Understanding flash composition of Arduino bootloader

I'm trying to understand the Arduino bootloader. I've found some intro here: Arduino Bootloader, but I need more details and because of it I'm asking for help.
During my research i found a start point: OK, Arduino (atmega family) has a specific block of flash dedicated to bootloader. Once the mcu has a bootloader, it can download the new program via serial and store it on flash, at address 0x00.
Let's asign the atmega328p for this question.
#1 - If you take a look at datasheet page 343, you will see a table, showing some info about the bootloader size:
By this table I understood: if i set BOOTSZ1/0 to 0/0, I can have a 2K bootloader and it will be stored in flash stack: 0x3800 ~ 0x3FFF.
#2 - If you open the hex file of ATMEGA328_BOOTLOADER generated by Arduino, you will see the bootloader stored at:
:10**7800**000C94343C0C94513C0C94513C0C94513CE1
to
:10**7FF0**00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF91
If you consider 7FF0 - 7800 you will get 7F0 (2K bytes of program)
#3 - If you open the makefile (C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\atmega) you will see this argument for atmega328:
atmega328: LDSECTION = --section-start=.text=0x7800
Where 0x7800 matches the hexa file from bootloader.
Questions:
1- Why the datasheet tells me that I have an special place for bootloader and the makefile of Arduino force it to be stored in a different place?
2- What means the line of an hexa file?
:10E000000D9489F10D94B2F10D94B2F10D94B2F129
:10 : (?)
E000 : Address
00 : (?)
0D9489F10D94B2F10D94B2F10D94B2F1 : data (?)
29 : CRC (?)
First of all, I'm not sure we have the same atmel datasheet; your table was 27-7 on my one, but anyway the data is the same.
Disclaimer: I'm not 100% sure about this, but I'm pretty confident.
I think that the "problem" here is that "words". Reading in the overview of the core they wrote
Most AVR instructions have a single 16-bit word format. Every program memory address contains a 16- or 32-bit instruction
This means that instructions are 2 byte wide. So your address 0x3800 corresponds to 0x7000 byte from the start of the memory, while the end of the bootloader 0x3FFF corresponds to the bytes 0x7FFE and 0x7FFF.
This is confirmed by the memory size: 0x7FFF corresponds to 32k, which is the available flash. Since the bootloader is at the end of the memory (as the pictures from the DS imply), this means that 0x3FFF should be the last memory cell.
EDIT:
When I answered, I did not read the second part of the question. The format is the so-called Intel Binary format. See Wikipedia for the detailed information. Here is a brief summary.
You correctly identified the field division:
: : Start code
10 : Number of data bytes (in this case: 16)
E000 : Starting address of the data bytes
00 : Record type (in this case: data)
0D9489F10D94B2F10D94B2F10D94B2F1 : data payload (in this case: 16 bytes)
29 : CRC
The record type can be
00: data
01: end of file
02: extended segment address
03: start segment address
04: extended linear address
05: start linear address
The CRC is obtained summing all the bytes (starting from the length one, so the very beginning), then getting the LSB and finally making the 2 complement. In this case the sum is 2519, which is 0x9D7 in hex. The lower byte, D7, corresponds to 215. Its 2 complement can be calculated as 256 - x, so 41, which means 0x29 in hex.

Word size in bits to bytes conversion confusion

I have a pretty elementary question which is somewhat confusing me. It will be great to get some refresher on this.
Every computer has a word size. The word size is the maximum size of the virtual address space. So if we have lets say a 32 bit word size, we have a virtual address space that ranges to a max of 2^32 values. In references it says 2^32 bytes? Why is the range in bytes.
Also, What I am failing to understand is how 2^32 possible values be a possible address range of 4GB? So, my confusion stems from the confusion of turning the 32 bit word size into 4 byte word size, and then how 4 bytes, multiplied 2^32 times result in 4GB.
One way I tried to rationalize it is as follows:
2^32 bits = 2^2(bytes) x 2^10(kilobytes) x 2^10(megabytes) x 2^10(gigabytes)
So successive division of 2^32 by 2^10 results in 2^2 GB or 4 GB.
Can somebody point out how the 32-bit word size go to a 4GB page range?
Thanks
The argument in my head goes like this: We have 32 bits available to us, each bit can be at most 1. So the largest number we can accommodate is when all 32 bits (the 0 bit to the 31 bit that is) are filled with 1s. So the trick is to find the largest number in decimal form, by converting from binary to decimal we get:
1111111111111111111111111111111 (binary) = 4294967295 (decimal)
But what is 4294967295? It's actually one less than 2^32. Now there's another important thing to keep in mind:
4GB = 4294967296 bytes
But why is it 1 greater than our result? Because our first byte is byte 0 while the last is byte 4294967295 for a total of 4294967296 bytes.
So now we're in a position where the smallest number that can exist in a 32-bit register is 0 and the largest number that can exist in a 32-bit register is 4294967295.
0 (binary) - 1111111111111111111111111111111 (binary)
0 (decimal) - 4294967295 (decimal)
0 (hex) - 0xFFFFFFFF (hex)
So there is 4GB of addressable space because anything above 4GB will have an address that is too big of a number to fit inside a 32-bit number and thus inside a 32-bit register.
I did all this stuff inside excel and seeing it helped me a lot.

I don't understand something in memory addressing

I have a very simple (n00b) question.
A 20-bit external address bus gave a 1 MB physical address space (2^20
= 1,048,576).(Wikipedia)
Why 1 MByte?
2^20 = 1,048,576 bit = 1Mbit = 128KByte not 1MB
I misunderstood something.
When you have 20 bits you can address up to 2^20. This is your range, not the number of bits.
I.e. if you have 8 bits your range is up to 255 (unsigned) not 2^8 bits.
So with 20 bits you can address up to 2^20 bytes i.e. 1MB
I.e. with 20 bits you can represent addresses from 0 up to 2^20 = 1,048,576. I.e. you can reference up to 1MB of memory.
1 << 20 addresses, that is 1,048,576 bytes addressable. Hence, 1 MB physical address space.
Because the smallest addressable unit of memory (in general - some architectures have small bit-addressable pieces of memory) is the byte, not the bit. That is, each address refers to a byte, rather than to a bit.
Why, you ask? Direct access to individual bits is almost never needed - and if you need it, you can still load the surrounding byte and get the bit with bit masks and shifts. Increasing the bits per address allows you to address more memory with the same address range.
Note that a byte doesn't have to be 8 bit, strictly speaking, though it's ubiquitous by now. But regardless of the byte size, you're grouping bits together to be able to handle larger quantities of them.

Why 16-bit address with 12-bit offset results in 4KB page size?

I'm reading the "Modern Operating System" book. And I'm confused about the "Page Size".
In the book, the author says,
The incoming 16-bit virtual address is
split into a 4-bit page number and
12-bit offset. With 4 bits for the
page number, we can have 16 pages, and
with 12 bits for the offset, we can
address all 4096 bytes within a
page.
Why 4096 bytes? With 12 bits, we can address 4096 entries within a page, correct. But, one entry is an address (in this case, address size = 16 bits). So I think we can address 4096(entry) * 16(bit) = 4096(entry) * 2(byte) = 8KB, but why the book says that we can address 4096 (bytes) ?
Thanks in advance! :)
This is assuming byte-addressed memory (which almost every machine made in the past 30 years uses), so each address refers to a byte, not an entry or address or any other larger value. To hold a 16-bit value, you'll need two consecutive addresses (two bytes).
More than 30 years ago, there used to be machines which were word addressed, which worked like you surmise. But such machines had a tough time dealing with byte-oriented data (such as ASCII characters), and so have fallen out of favor. Nowadays, things like byte addressability, 8-bit bytes and twos-complement integers are pretty much just assumed.
The 12 bits are an offset within a page. The offset is in bytes, not addresses. 2^12 is 4096.
Because with 12 bit, we can address 2^12=4096 slots. Each slot represents an address which size is 1 byte in byte-addressable memory. Hence the total size is 4096*1=4096 bytes = 4KB.
What you are calculating is the page size, i.e. the size of a page in the page table in the memory. As we use 12 bits for the offset, each frame in the physical memory is 2^12=4096K. However, each page in the page table occupies 2^12 entries x 2 bytes = 8K in the memory.
okay so you have 16 bit virtual address let see what does it mean .It means you have 2**16 =65536 bytes.
4 bit page number that means there are 16 pages as 2^4=16
Now You Name The Pages As page1,page2...page16.
Now We are left with 12bits let us see how many address can 12 bits represent 2**12=4096 bytes
65536 bytes could also be achieved by dividing it into 16 pages containing 4096 bytes each as 4096*16=65536

Resources