OSDev.org

GhostlyDeath wrote:It is very important to comment your code as you write it, at least a description of what each method does, what the purpose of a class is, why a field exists.

Generally - yes, I agree. However, some methods like setters or getters are so obvious that it is just a waste of screen space to comment them. But it doesn't mean I refuse to comment. I will, but not as fast as may be you can expect.

GhostlyDeath wrote:Then once your code does compile or is mature enough you can just run javadoc on it.

I know this.

GhostlyDeath wrote:After glancing over the source files you eventually see that there are virtually no comments, then once some commented things start to appear out of nowhere, there is a stylistic clash.

As it was said - not all files are commented. But I can understand your 'stylistic clash'

GhostlyDeath wrote:Java has the notion of packages, similar to namespaces in C++. Rather than having a directory tree of:

Code: Select all

foo/bar/assembler
foo/bar/compiler
foo/bar/bootloader

You instead have:

Code: Select all

FooBarAssembler/src/foo/bar/assembler
FooBarCompiler/src/foo/bar/compiler
FooBarBootLoader/src/foo/bar/bootloader

Modularization is fine but having 12 directories (which will soon turn into 20+ directories) may become less maintainable. Although you seem to be using Eclipse with tons of different projects separate than combined.

It's all about project organization by the IDE. The Eclipse has defined a notion of project. It is not a directory (even if the directory with such name really exists). The project consists not only of the directory, but of many files and directories. To have some manageable piece on the disk all project's files are placed in the project's directory. And within the project directory there is some predefined structure to help manage everything else. For Eclipse it is a standard solution to have the src directory within the project's directory. The src directory separates source code from everything else in the project (like compiled code and project settings). And within the src directory the packages are placed. If the packages would be placed somewhere outside the project and src directories then it becomes separated from the whole project and less manageable.

GhostlyDeath wrote:And each package can have a file called package-info.java which describes the actual package.

Yes, it can. I hope there will be such files in the future, but currently the class sources commenting is a more actual task.

GhostlyDeath wrote:Unified directories also helps on having a single class path rather than it being specified multiple times.

Yes, it is the issue of a plain Java compiler usage without the help from IDE. But an IDE really can help. You can try one of them.

GhostlyDeath wrote:But with extremely long names, it takes up more space on the screen, in memory, and on the disk.

Yes, you are right. But when looking at the code the developer can see all information required without any extra movement. This is the reason for long method names. It requires to hover mouse pointer over the method name and wait until the JavaDocs will be displayed in a small hint overlay - it's a bit more irritating than having long names occupy some part of the screen. And, of course, there is no ideal solution, so it is absolutely possible to cut those long names. But I hope you agree that there are just a few such long names.

GhostlyDeath wrote:Personally, I would just replace the "ldc #?; ldc #?; invokestatic (Ljava/lang/String;Ljava/lang/String;)V foo/bar/Assembly.asm" with inline assembly

It's already inline. The goal was 100% Java and having external files with assembly code will cut many Java developers from using the system. And experienced assembler users can easily understand the Java Assembler code because it is very close to the Assembler language.

GhostlyDeath wrote:Said static method would be:

Code: Select all

package foo.bar;

/**
 * This is a special class which contains a static method for encoding assembly
 * instructions for use in the recompiler pass.
 */
public final class Assembly
{
	/**
	 * Encodes an assembly instruction from the specified string.
	 *
	 * @param is The target instruction set to use for the statement.
	 * @param whatever Whatever assembly statement you want to encode.
	 * @see InstructionSet
	 */
	@AOTSpecialMethod
	public static void asm(String is, String whatever)
	{
		throw new Error("This is an AOT special method, it cannot be invoked.");
	}
}

You have described the heavy commandliner coding approach. But Java programmers much more often are IDE users. And the IDE helps them with the lists of method names and argument descriptions. Then for IDE-developers it seems much more convenient to use a habitual style of coding when after pressing the point they have all the help required. And beside of the help there is Java type checking for the assembly instructions. It is impossible to compile a program with 8-bit register replaced with 32-bit, for example - Java compiler will notify you about compile time error.

Ghostly, I take you joined just to be a language troll?

Combuster wrote:Ghostly, I take you joined just to be a language troll?

No, I did not have any intention to troll nor to cause emotional distress for my personal pleasure.

I like to see it, I know Java CAN make OS, because JNode.org is already there.

Do you have some tutorials on how to run your OS, and some screenshot could be better.

neoe wrote:I like to see it, I know Java CAN make OS, because JNode.org is already there.

Do you have some tutorials on how to run your OS, and some screenshot could be better.

emrbyos attempt differs from the one of JNode, he is actually compiling Java bytecode to platform-specific binaries, while JNode is running a JVM.

Some questions,
- Java's bytecode is meant to be executed by a register-less stack machine, are you optimizing the bytecode before translating it?
- how are you dealing with garbage collection?
- who is keeping track of types and stuff, like when using instanceof?

Great work so far!

neoe wrote:Do you have some tutorials on how to run your OS, and some screenshot could be better.

I have two parts of documentation page closely related to the question:

• System installation
• Console application usage

In short all you need to do is to write system image on a flash and setup your computer to boot from it. Next the command line appears (but I have tested it on just a few computers). In command line you can type question sign (?) or "help" and hit enter - the command list will be shown to you.

And yes, screens are better than words, but it's still just the same command line that we have seen a lot of times - what new can such screen show? However, screens are introducing some diversity to the plain text. Yes, they should be added.

max wrote:he is actually compiling Java bytecode to platform-specific binaries, while JNode is running a JVM.

jNode actually also compiles bytecode to the machine code. I haven't understood the picture in details but it is similar to my OS (or my OS is similar to jNode). The difference is in separation of the Assembler project. The jNode uses a few asm files to accomplish some low level tasks and it has no it's personal bootloader (it uses GRUB). My way is about using my own assembler and my assembler is used directly from Java code (actually the assembler code is Java code). So I just write any low level things (including bootloader) in my assembler and, because it's Java, I have no need in anything else except Java IDE. And as a result - my code is 100% Java.

max wrote:are you optimizing the bytecode before translating it?

No, there is no optimizing compiler yet.

max wrote:how are you dealing with garbage collection?

In short - I use mark and sweep garbage collectors. Here is a bit longer story.

max wrote:who is keeping track of types and stuff, like when using instanceof?

The instanceof operator is implemented as one of the bytecodes the JVM uses. The instanceof bytecode is part of JVM specification. But I have divided bytecodes in two parts - assembly only and Java aware. The second part is small and includes the instanceof bytecode. Bytecodes from second part use internal call convention to reach the Java.

max wrote:Great work so far!

Thanks

A bit unrelated update has happened. Part of my OS (the Assembler project) is now used for things, similar to inline assembly in C. The assembly is written in Java class and called directly from a Java code. As usual, it is 100% Java and there is no need for anything except a Java IDE. But IDE and the Machine Level Java together offer a very nice solution with intellisense, tooltips, argument type checking from IDE and assembly level speed increase from Machine Level Java.

Also there is a performance test with a few approaches to the same algorithm. Unfortunately, there are no C-compilers involved and hence no way to compare Java vs C performance.

Looks good! This little "feature" may take off on its own in the Java community if you can get the word out to the right people...

Of course, I would have preferred more descriptive names in your methods and enumerations.

Also, it's not clear from the overview documentation on your web site, but is there any way to specify that the machine level java code class that you are writing should only be used for a specific platform (i.e. x86 32-bit), but a different, non-machine level class should be used for other platforms? This would allow you to write Java code that would run on all platforms, and then write X86 assembly code that would only run on x86 platforms.

This may already exist, or it may already be part of JNI, but if not, I would highly recommend implementing this, somehow.

Great work, though!

SpyderTL wrote:Looks good!

Thanks

SpyderTL wrote:This little "feature" may take off on its own in the Java community if you can get the word out to the right people...

I'll try, but I still have some doubts about the real need for it. Heavily optimized computation is relatively rare area for Java community.

SpyderTL wrote:Of course, I would have preferred more descriptive names in your methods and enumerations.

Here I still at a position of a tooltip provided documentation. Or else it is possible just to jump to source code (using IDE's help) and to read code comments or the actual code.

SpyderTL wrote:Also, it's not clear from the overview documentation on your web site, but is there any way to specify that the machine level java code class that you are writing should only be used for a specific platform (i.e. x86 32-bit), but a different, non-machine level class should be used for other platforms?

There is a check, that looks at provided architecture and OS constants (as constructor parameters). If architecture or OS is not supported, then an exception is thrown.

But the idea of invisible substitution of a low level code with some Java code is really interesting! I think I should make some wrapper that should be able to call Java variant instead of throwing an exception. It seems that I should make it