How does assembly relate to machine/binary code. For example here is how to prin

Question

How does assembly relate to machine/binary code.

For example here is how to print to the screen in mikeOS(a small pure assembly OS), mikeOS it uses NASM to assemble.

BITS 16
    ORG 32768
    %INCLUDE 'mikedev.inc'

start:
    mov si, mystring
    call os_print_string

    call os_wait_for_key

    ret

    mystring db 'My first MikeOS program!', 0
Where os_print_string and os_wait_for_key are defined as

os_print_string     equ 0003h   ; SI = zero-terminated string
and

os_wait_for_key     equ 0012h   ; Returns AL = key pressed
in mikedev.inc respectively and defined as

os_call_vectors:
    jmp os_print_string     ; 0003h
in kernal.asm

Now nasm must do a lot more work under the scene when assembling, I have no idea what.

In other words assembly language is a wrapper to some degree to machine code just as say C is a wrapper to assembly. If I said cout >> "Hello World" for example in C++, this is then compiled into it's assembly equivalent and them assembled into machine code.

So I am trying to understand out how 0003h and 0012h seem to dictate everything that is going on when printing to the screen. How do these two values,

a) Tell the CPU/PC system which bus to send the corresponding bytes that represent the required string to the monitor bus and not say to the sound card.

b) In this case the string is sent to the monitor, obviously, now my understanding is that you have a frame buffer that can store a maximum number of bytes. So say the resolution of your screen is set at 1024 x 768 which is 786432 pixels and a refresh rate of 60hz on the screen, therefore the FB will contain this number of byte values and hence will be sending this many bytes to the monitor every 1/60 sec. The first byte in the FB corresponding to the first pixel on the screen and the last to the last on the screen etc.

So how does the CPU/GPU know which byte to put in which position in the FB. It's like saying to the GPU 'ok I need this pixel at coord (245,232) green so I will leave it to you to put this pixels value in the correct position in the FB' etc.

How does this work.

Explanation / Answer

In respect to what those os_print_string = 0003h and other "magic numbers" are, they're entry point addresses, not to the actual subroutine, but to a jump table which in turn jumps to the actual location of the OS subroutine.

When I first started learning assembly language it was on a system which did not have much organization in the ROM layout. If you wanted to make use of the ROM routines you had to set up the CPU registers and directly CALL the address of the routine.

All well and good until the ROM is updated and all the addresses change...luckily, the ROM in question never did get any updates which would break those calls. If it had, a great many software titles would have stopped working.

Jump tables solve this problem by ensuring that the published entry point for an OS routine never changes, even if the machine code itself moves around between different OS versions. In this case the jump table entries are at 3 byte increments so the table will look a lot like:

0000h JP someaddr C3 LL HH
0003h JP print_string C3 LL HH
0006h JP yetanotheraddr C3 LL HH
0009h JP yetanotheraddr C3 LL HH
000Ch JP yetanotheraddr C3 LL HH
000Fh JP yetanotheraddr C3 LL HH
0012h JP wait_key C3 LL HH
...
...
LL and HH may be switched depending on the endian-ness of the CPU, C3 happens to be the opcode for JP on a Z80.

No RET is needed between these because the JP does NOT save the current execution address on a stack (whereas the CALL which got you there does) so the last RET in the OS routine will cause execution to continue right after your call to the jump table.

As to how the system knows which addresses in the framebuffer to manipulate, that's all taken care of by os_print_string (and whatever other display related OS routines are available to you; there may well be something like os_set_point). The framebuffer address, hardware, implementation etc can all change, but your code only cares that there is an OS routine which prints characters to the display (or sets points, or draws lines, or...)

Related Questions

Navigate

• Browse (All)
• Browse H
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.