Reference no: EM132385478

Application Binary Interfaces

Overview

The purpose of this unit to have you build on your existing work by implementing simple application binary interfaces that use System Calls to request services from the operating system.

Learning Outcomes

1. Experience implementing simple Application Binary Interfaces that use System Calls for their implementation.

2. Experience creating simple Application Programming Interfaces to mask hardware-specific details of Application Binary interfaces.

Body of work

1. Each student is required to individually complete each of the following checkpoints.

Checkpoint 4.1: Run code in the unprivileged processor mode, i.e., outside Hypervisor Mode

Begin by running the fetch command. This will, among other things, update the version of KickC to the latest. Then copy ${HOME}/repo/unit2/checkpoint2.3.kc file to ${HOME}/repo/unit4/checkpoint4.1.kc

Don’t forget to get the names exactly correct! You MUST have the .kc extension on the end, for example.

As usual, change the checkpoint number in the MESSAGE string.

Then create a function called start_simple_program() that copies a program from a special area of memory to a place where it can be run from. We will do this using the MEGA65’s DMA controller. For now, you don’t need to understand how the DMA controller works. Instead, you
just need to implement the following in your start_simple_program() function.

Write the following values into the following memory locations in exactly this order:

You do this by assigning to a pointer to type unsigned character. For example, to do the first of these, you would use something like:

*(unsigned char *)$0300 = $80;

For every line in the above table, you will need to include one line similar to this one in your

start_simple_program() function.

The program that is provided for you and that the above sequence will copy, starts at address $080D  in memory. Therefore you need to tell the MEGA65’s processor to set the program counter to $080D for the user-space (non-hypervisor mode) program. As documented in Appendix D of theMEGA65 User’s Guide, this is accomplished by writing the address into the two bytes starting at $D648. This can be done by creating a pointer to an unsigned short, and assigning to that. Thus adding a line like the following to your start_simple_program() function will accomplish this. You should add this to your start_simple_program() function.

*(unsigned short *)$D648 = $080D;

Finally, at the end of your start_simple_program() function, you need to tell the processor to exit Hypervisor Mode. This is done by calling the exit_hypervisor() function you wrote in an earlier work unit.

Finally, add a call to the start_simple_program() function in your reset() function, so that it gets run when you start the MEGA65 emulator.

Once you have done this, you can test your checkpoint with the command:

( cd ${HOME}/repo/unit4/ ; make test4.1 )

If it is successful, you will see that the user-space program that I have supplied will display an extra message on the screen, resulting in a display similar to the following:

Show this image, along with your checkpoint4.1.kc file to the demonstrator to receive checkpoint 4.1. The demonstrator will check to make sure that your checkpoint4.1.kc file is displaying the “user space program is running” message itself, and that it is really transferring control to the supplied user-space program.

Checkpoint 4.2: Write a simple SYSCALL handler

In this checkpoint you will implement two simple SYSCALL handlers in your toy operating system.

These SYSCALL handlers will simply print a message to the screen to say that they have been called.

Copy ${HOME}/repo/unit4/checkpoint4.1.kc file to

${HOME}/repo/unit4/checkpoint4.2.kc

Copy in the print_to_screen() and print_newline() functions you did last week into the checkpoint4.2.kc file to make this easier. Don’t forget to also copy in the definitions for current_screen_line and current_screen_x, but add the volatile keyword to them, so that the KickC
compiler knows that their values can change at any time. This is to stop the compiler from making bad assumptions about these variables (if you are curious, look at the produced assembly code, both with and without these keywords). So your declarations of these variable should look like:

volatile unsigned char *current_screen_line;

volatile unsigned char current_screen_x;

Now because the C compiler doesn’t really know what we are doing, we have to manually initialise these variables in your reset() function, with code like this:

current_screen_line = $0400;

current_screen_x = 0;

Modify your syscall00() function, so that it prints the message “syscall00 entered”, before calling the exit_hypervisor() function you wrote earlier.

Now do the same for syscall01(), so that it prints “syscall01 entered”.

Once you have done this, this is the operating-system side off the Application Binary Interface complete.

The user-space program that calls these system calls has been provided for you. All you have to do to get this checkpoint is to run the command:

( cd ${HOME}/repo/unit4/ ; make test4.2 )

and show the demonstrator your system call handlers and the other changes above. The output from your program when running should look like this:

Checkpoint 4.3: Implement a simple ABI + API for SYSCALLs

In the last checkpoint, the user program was supplied for you. In this checkpoint, you will implement that part yourself, i.e., the userspace4.3.kc file. The operating-system side remains unchanged, and the program will look very similar when running, as a result.

Create a file called ${HOME}/repo/unit4/myabi.kc.

In this file, create a function called enable_syscalls() that contains exactly the following two lines:

*(unsigned char *)$D02F = $47

*(unsigned char *)$D02F = $53

This tells the MEGA65 to allow system calls to be made.

Also in this file, create a function called call_syscall00(), that triggers SYSCALL $00 by first calling enable_syscalls(), and then writing any value $D640. You can do this with something like the following as the function body:

enable_syscalls();
*(unsigned char *)$D640 = $00
asm { nop }

Then create a second function, call_syscall01() that triggers SYSCALL $01, by writing any value to $D641, similar to the first function.

This creates your API that wraps the SYSCALL ABI for these calls. They are now ready to use from a program.

Create a file ${HOME}/repo/unit4/userspace4.3.kc

In userspace4.3.kc, begin by importing your abi with the following line at the start of the file: import “myabi”

Then create a main() function that calls the call_syscall00() and call_syscall01() functions from your API. This function should end with an infinite loop, so that nothing strange happens. You can do this by having a line like the following as the last in your main() function:
while(true) continue;

At this point, you now have a test program that calls your API, and we are getting close to testing it.

Copy ${HOME}/repo/unit4/checkpoint4.2.kc file to ${HOME}/repo/unit4/checkpoint4.3.kc

Change the “checkpoint 4.2” message to “checkpoint 4.3” in checkpoint4.3.kc

To test your program, run the following command:

( cd ${HOME}/repo/unit4/ ; make test4.3 )

The output from your program when running should look like this:

To get this checkpoint, show the demonstrator your system call handlers and the other changes above, as well as the output from your programs running.

Checkpoint 4.4: Implement a SYSCALL that sencds data to the operating-system

As usual, these fourth and fifth checkpoints are extension checkpoints. You can pass the topic without completing them, if you do well in all the other parts of the topic. However, if you are aiming for a distinction or high-distinction grade, you will need to complete most of them.

Remember also, that you have four weeks to complete each work unit, so don’t get too hung up if you can’t complete these checkpoints immediately. It is certainly better to make sure you get the first three checkpoints each week, than to get stuck for days on getting a single checkpoint (remember that each individual checkpoint is <2% of the total topic grade).

In the previous two checkpoints you implemented system calls that did not exchange any data with the operating system. In this checkpoint you will implement a system call that passes data to the operating system, and then has the operating system use that data.

You will implement an API with a function print_string(char *string) that calls SYSCALL $02 so that it allows a user program to print a string to the screen. This will use the functions you have already made to print a string to the screen.

Because of how the Hypervisor Mode on the MEGA65 works, any data transferred to or from the operating system must be in the first 32KB of RAM, i.e., located somewhere in the range $0000 – $7FFF. You can choose a fixed area of memory for this. I recommend you put the string at $0300 – $03FF, as nothing else uses this space.

In the user-space side of the ABI, you will thus have to copy the string passed into the print_string() function to this area, and then trigger the system call. Then from the operating system side, you will need to print the string. You don’t need to copy it again, as the Hypervisor

Mode memory map has the area at $0300 – $03FF visible. So you can just call your print_to_screen() routine with the argument $0300 as the argument, typecast to type (char *).

You can simply add your new print_string() API into myabi.kc, and add the necessary implementation into syscall02() in checkpoint4.4.kc (which you can otherwise copy from checkpoint4.3.kc, and update the message to indicate checkpoint 4.4 when it runs).

Then create a file called userspace4.4.kc, and write a main() function that calls your new print_string() api with a string that says “printed via print string api”.

As usual, you can test your program, run the following command:

( cd ${HOME}/repo/unit4/ ; make test4.4 )

One problem you might bump into, is if your string copy routine doesn’t copy the null character at the end of the string, in which case it might print strange things. Also, because there is no standard C library available to you, you will have to copy the string manually using a for(), do or while() loop. There are plenty of example of how to do this on the internet if you need ideas.

To get this checkpoint, you need to show your programme running, and show the demonstrator your myabi.kc with the print_string() function, as well as your syscall02() implementation and the contents of your userspace4.4.kc file, so that they can see that the  printing really is happening via the system call. See below for an example of a successfully running implementation.

Checkpoint 4.5: Implement a SYSCALL that receives data from the operating-system

To receive this checkpoint you must extend your work from checkpoint 4.4, so that you implement SYSCALL $03 so that the API function returns the operating system version as a string. You should call this char *get_os_version(). As usual, copy your previous checkpoint4.4.kc to checkpoint4.5.kc, and add the new API definition to your myabi.kc file.

To do this, you will need to have the operating system receive copy the string to a transfer area (you can use $0300 – $03FF again), and then for the ABI wrapper to return that address to the caller. It should not, however, directly return the address of the transfer area, but first copy it to a buffer. This buffer can just be a global variable declared as char[256] os_version_return. You will then return this variable as the return value of your function. You will again need to type-cast the address to (char *) to effect the string copy, but this time also on the user-space side. It is up to you what you want to have in your OS version string.

You should then create your userspace4.5.kc file, in which you should call this new get_os_version() function to get the operating system version, and then use the print_string() API you created in the last checkpoint to display a message like: “os version is <operating system version>”, where <operating system version> is the operating system version returned by get_os_version().

As usual, you can test your program, run the following command:

( cd ${HOME}/repo/unit4/ ; make test4.5 )

It should display something like the following, but obviously with whatever you chose as your operating system version string:

To get this checkpoint, show your output, together with your changes to myabi.kc and checkpoint4.5.kc, as well as the contents of userspace4.5.kc, to show that you are obtaining the OS version string via the SYSCALL, and then printing the messages out using the
SYSCALLs you implemented previously.

Attachment:- Application Binary Interfaces.rar