Java For Starters: Difference between revisions

==The problem with OS development in Java==

 

 

==How to run you without a car?==

Well, it's simple - you can use your legs. But yes, it's not very convenient. And it's better to have some kind of a vehicle to help you to get some speed. That's why it is important to understand what tools we have.

 

 

Second, it's possible to write absolutely everything in the preferred language. And of course, it means somebody should write the "everything". Because in case of many languages there's no native tools available, it's the OS developer who should write "everything".

==Here are some tools available for Java OS developers.==

 

 

The second option (everything in Java) is described below. But it introduces some tools, already written in Java. The tools here are used as an example and there's no attempt to enforce you to use them. Following article shows how to create a simple bootloader in Java. There is a jump in the end of the bootloader code and all your potential Java OS can start after the jump is performed. So, your OS in Java can start with this article and end in some very interesting form, unseen until you'll have it done.

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.

 

The collection of assembly instructions can look like this:

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]]