Can't understand how virtual address was converted to binary form - binary

This is a question and answer from my operating system's textbook:
Question:
A certain computer provides its users with a virtual-memory space of 232 bytes.
The computer has 218 bytes of physical memory. The virtual memory is implemented by paging,
and the page size is 4096 bytes. A user process generates the virtual address 11123456.
Explain how the system establishes the corresponding physical location.
Distinguish between software and hardware operations.
Answer:
The virtual address in binary form is
0001 0001 0001 0010 0011 0100 0101 0110
When I plug "11123456" into a decimal to binary converter (like here: https://www.rapidtables.com/convert/number/decimal-to-binary.html), this is the result: 101010011011101100000000
which differs from the book answer.
Also, when I manually convert using a method like here: https://indepth.dev/the-simple-math-behind-decimal-binary-conversion-algorithms/
I still get something different.
I'm just confused how that virtual address was converted into binary form......
Thanks!

You think
11123456
is a decimal number but it isn't. The Computer representation of number is ever binary, octal or hexadecimal. In this case is Hexadecimal. If you convert the above number from hexadecimal to binary form you obtain the result:
0001 0001 0001 0010 0011 0100 0101 0110
Explanation:
Hexadecimal -> Binary
1 -> 0001
2 -> 0010
3 -> 0011
4 -> 0100
5 -> 0101
6 -> 0110
...

Related

Two's complement binary to decimal

I'm having trouble converting the following two’s complement binary number to decimal
01110000
Step 1: Invert the bits -> 10001111
Step 2: Add 1 to the bit -> 10010000
Therefore, the decimal value is 144
However, I used online converter and it says the decimal value is 112
The value of ...111 0111 0000 (padded with an infinite number of 1's) is -144. The value of ...000 0111 0000 (padded with an infinite number of 0's) is 112. Given the former, one could compute its additive inverse by inverting all the bits (yielding ...000 1000 1111) and adding 1 (yielding ...000 1001 0000, i.e. 144).

Possible register address error reading machine code to binary code?

I'm working on this disassembling assignment and a bit confused.
Disassemble the following machine code into operations and arguments,
e.g., ADD R1,R2,R3.Explain what the whole program does,either in plain
English or in C type of pseudo code Note: you need to make up unique
labels for your assembly code.
Add r: Code
0x00: 07 FF
0x02: 06 08
0x04: 28 08
0x06: 38 02
0x08: 02 47
0x0A: 3C 00
here's the simple processor
w - Write back ALU output to register file
src1 - Address for first ALU operand
src2 - Address for second ALU operand
dst - Address in where output is written
Here are the opcodes used in the assignment
ADD 0x0 R[src1] + R[src2]->R[dst]
SUB 0x1 R[src1] – R[src2]->R[dst]
BLEZ 0xA If R[src1] ≤ 0, branch to BAddr (The last 6 bits are the
address)
HALT 0xF
Here's what I got
0000 0111 1111 1111
0000 0110 0000 1000
0001 1000 0000 0008
0011 1000 0000 0001
0000 0001 0010 0111
0011 1110 0000 0000
I get confused here - 0000 0111 1111 1111 looking at the instruction table, it looks like the program is subtracting from the same register and placing the result in the same register. Am I right? I feel like it is wrong. Thanks in advance!
I did not check your opcodes but what you are describing is one way of reseting register to zero. Which makes sense as you do not know what that register contains. Other times XOR operation is used to get the same result.

Converting hex into two's complement 8 bit binary

I am in a CSCI class and we are just learning about program execution. I am running a program called "Brookshear machine simulator" which was written by the author of the class text book ( Computer Science 11th edition by J. Glenn Brookshear). The program is intended to add the contents of 11 and 0F, storing the result into F1. I have done everything necessary and produced the hex value in 11 which is 09. I am then asked to convert this into two's complement 8-bit binary, which is where I am having a problem. I will be needing to convert some hex values into two's compl 8-bit binary in the future for this lab but I cant figure out how to do it. Can someone please help me understand what twos comp is and how is it related or the same as 8-bit binary , so I can convert this to two's complement 8-bit binary?
Here is a picture of the machine simulator with the inputs as directed by the lab instructions. My task is to find the hex value in 11 (09) then convert it to twos complement 8-bit binary.
Each hexadecimal digit has a 4 bit binary equivalent:
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001
A 1010
B 1011
C 1100
D 1101
E 1110
F 1111
So if you have a two character hex value, like 09 then you can see that 0 = 0000 and 9 = 1001, so that would be:
00001001
which is an 8 bit value.
This works for any length of hex number of course, so for example 37FF in hex would be 0011011111111111 in binary.
Note that two's complement is irrelevant for your example as the number is positive.

Impossible to encode 32-bit binary opcode in machine instruction

I have been trying to format binary opcodes for Motorola 68000, but I keep finding that it's not possible to encode both the destination memory address, instruction designation and addressing mode/size, and data value to be copied to the address bus for memory-mapped I/O.
For the Sega Genesis' Video Display Processor I am attempting to write to the control port which is memory mapped at C00004 in the Genesis' memory map.
C0004 is 1100 0000 0000 0000 0000 0100 in binary, or three bytes. The value I'm writing is 87, which the VDP recognizes as 8787 in VDP register #7. The issue I'm having is figuring out how to encode 32-bits worth of data, e.g. the instruction prefix designation move.b, value 87, which is #$87, and the destination memory address C00004 for MMIO re-routing to the correct VDP port on the way to the VDP.
Altogether it looks like this:
move.b #$87, $00C00004,
which loosely translates into not four, but four bytes and a nibble(36-bits to be exact!)
0001 1000 0111 1100 0000 0000 0000 0000 0100
Since Motorola 68000 will only parse 32-bits when working down to microcode, how is it possible to encode the required information if there's not enough space(and within the same instruction)?
Perhaps I'm understanding this incorrectly?
I know this is beyond the level most programmers would anticipate, but I'm hoping someone around can break this down for me and explain how this encoding scheme would work.
Your instruction, move.b #$87, $$00C00004 ought to encode to
0001111001111100 0000000010000111 00000000110000000000000000000100
(or similar; I'm not sure about the order of the operands).
The first 16-bit word can be broken down thusly:
The first four bits say that this is a move.b instruction.
The next six bits say that the destination addressing mode is an absolute 32-bit address.
The last six bits say that the source operand is immediate.
After that follows instruction extension words with the operands. The first is 16 bits for the immediate data, and the last 32 bits are for the address. (Might be the other way around.)
For more information, see http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf

Smallest Two's Complement in Binary

I'm not sure if I can ask a binary question here but here goes..
We had this question on our midterm but our professor hasn't provided a correct answer for it. It's been driving me crazy and the final is coming soon so it might be a good idea to fill this gap. Thanks!
Find the smallest two's complement number that, when added to 0101 0101 would result in an overflow. Express your answer in binary.
My reasoning:
I found the range of the original binary 0101 0101 by converting it to an actual number and then added one to it. Then I converted the number that was 1 more than the range into 8-bit binary as my answer. However, this only earned me 3/6 marks. I have no idea what else I could've done. Any insights would be greatly appreciated!
The original binary is a positive number (0 sign bit). Overflow occurs when you add a positive number to it that changes the sign bit. It should be easy to see what the smallest number is using binary notation:
No overflow:
0101 0101
+ 0010 1010
---------
0111 1111
Overflow:
0101 0101
+ 0010 1011
---------
1000 0000
I have no idea if this is what your prof was looking for. (You can probably just subtract from 1000 0000 instead of looking at it as a pattern.)
EDIT Since you asked for an example (meaning something different from the above), here's how subtraction would work:
1000 0000 (the target overflow quantity)
- 0101 0101 (the original binary)
---------
0010 1011 (the smallest number that will overflow when added to original)
That number is 85 in decimal, so 128-85 is 43