Java For Starters: Difference between revisions

 

 

Basically it is required to load an OS for it's code to be executed. Because we are talking about Java then it seems a good idea to understand first how Java can load itself (or an OS written in Java). There is a number of ways.

* Second, you can write a bootloader in another language, but not in Java, like assembly, for example.

* And third, you can write a bootloader in Java.

First we have to look in the depth of the software execution. For the software to be executed there should be a processor which is able to understand software's instructions. Usually the code you see in many languages is not understandable by the processor. So, there's a translation layer between the code and the executable software. But the translation can be implemented in many forms. First it was the assembly. People had written short textual commands and software was required to translate the commands in the form the processor understands. Next people understood it's very tedious and time consuming to write software in such a form of short textual commands, so the high level languages were born. And as we know, Java is the one. But the translation level between Java and the actually executed code hides a lot of details. It is done for a reason. It helps a developer to concentrate on the goal instead of gory details. And with the goal achieved faster we, unfortunately, lose some flexibility the low level commands have. And finally people managed to mix the high level with the low level in a consistent manner. It was called "inline assembly". It's not ideal and there's still a way for better compilers with the ability to understand such a mixture without requiring a programmer to jump between two languages. But unfortunately, such compilers are still far away from Java developers. However, the idea of inline assembly works perfectly even in Java.

 

 

And as we mentioned above there can be voices like "it's not Java!", we have to clear the subject a bit. If we remember the way a program goes along before being executed we can see some intermediary steps. It's the translation phase. The translation phase hides low level details and produces an executable file. But if we forget about the translation then it really can look like this - we write a program and (after some magic applied) it just runs. Yes, we can forget about translation and be happy with the actually running program. But the OS development is a thing that just requires us to go into the low level details. And if we go then it becomes obvious there's no more "the program" and there are just some bytes, produced by tools and executed by a processor. The actual execution details can be very different from what we expect while looking at the initial program. And the following information (hopefully) can show how things actually work between the layer of the programming language abstraction and the hardware layer. It's not Java or not Java talk, it's just way of doing things in Java. The same is true for every C or assembly program - there just must be some tools for the translation phase to work. And the tools can be written in C or assembly or (yes!) in Java.

First, it's still a Java program. So, the Java syntax should be respected. But Java syntax allows us a lot of flexibility. And the flexibility was used as such - every assembly instruction was defined in a Java class and instance of this class with the same name, as is used in assembly, is referenced from a successor of the AssemblerProgram class. As a result you can write a standard Java method and use assembly instructions in it.

 

mov.x32(EAX,EDX);

 

* Here the "mov" is the class's field name.

 

Next it is required to understand how the instruction above can be executed. For it to be possible the translation phase is required. But before the translation step it is usually a good idea to have the actual program. The program actually is just a number of text strings in the form described above. It can be good to separate code fragments intended for different purposes in separate methods like this:

protected void writeBootCodeInitialization(short stackAddress, short bootLoaderAddress)

{

mov.x16(SP,stackAddress);

}

And the class, where code fragments are supposed to be, can look like this:

public class AnAssemblyWriter extends AssemblerProgram

{

... // your code fragment methods

}

Here we see the class's constructor with two parameters, the mode parameter can be one of the following:

CODE16 // Generate 16-bit code

 

Next you can add a particular code to the bootloader for it to be able to actually load something. You can write a method like this:

protected void loadImageUsingInt13x42(String problemLabel, String diskAddressPacketLabel, int imageSizeInDiskSectors)

{

}

}

The the final program (it's main method) can look like this:

private void createBootCode(int imageStartAbsoluteBlockNumber, int imageSizeInDiskSectors,

short memoryAddressToPlaceBootstrapImageAt, short bootLoaderNewAddress,

imageSizeInDiskSectors,imageStartAbsoluteBlockNumber,memoryAddressToPlaceBootstrapImageAt);

}

And here you can see how helper procedures and data structures are written together with the actual bootloader's code.

private void writeProceduresAndData(String diskReadProblemLabel, String diskAddressPacketLabel,

int imageSizeInDiskSectors, int imageStartAbsoluteBlockNumber, short memoryAddressToPlaceBootstrapImageAt)

writeBytes(bs); // now add the bs buffer to the actual program

}

After you have all inline assembly instructions in place you can first call the methods with the instructions for them to write their binary representation and next call AssemblerProgram's getProgram() method to get the actual machine code stored in the returned byte array. The resulting bytes can be written to the boot sector using appropriate tools.

 

 

[[Category:Bare bones tutorials]]