OSDev.org

Brendan wrote:You're conflating "writing a C compiler" with "using a C compiler".

The problem with Java is - there's no native compiler for it written in Java. So, I need to start somewhere. And the obvious starting point is the assembly translator. Next, there should be Java compiler. And both should be familiar for a person who writes low level things in Java. It's true for every language.

Next, as a starting point of the low level, the bootloader looks like the real root from which all branches can be grown. Now there's no Java compiler able to produce bootloader code from pure Java source (no assembly imitation). It means now it's still impossible to use Java without the assembly level. And as a result it is impossible to start using Java for low level without using some form of Java related assembly (or a smart compiler, which is still nonexistent). So, how to describe Java bare bone steps without describing the assembly approach applicable for the "pure Java" solution?

And if it's the contradictory question then I (and you and others) can leave some comments in the bare bones text. My comments are already there.

Brendan wrote:It's entirely possible to use C differently. For example, you could write an assembler in C that uses "assembly source code" embedded directly in the assembler's own C (e.g. as data and/or macros and/or functions, not as inline assembly); so that when you execute the compiled C program it assembles the assembly source code that was embedded into it.

Have you noticed some kind of "chicken and egg" problem here? And I think the resolution of such problem can be found on the way of describing things from low level and up. And it means the first step (bare bone) is (can be) the assembly.

Brendan wrote:but if someone did do this then the boot loader would be written in (an awkward/ugly dialect of) assembly and the boot loader wouldn't be written in C at all.

The syntax is defined by C. And everything else is still the C related stuff, even if it looks like assembly. The same is true for Java.

Brendan wrote:In the same way; you could write an assembler in Java that gets the assembly source code from separate file/s (and then write a boot loader in assembly);

Then there's another language and it's environment. In case of Java assembly there's no alien environment and there's just some similarity between the example and manual syntax and the actual Java code. It's similarity. It's not assembly. But I know, there could be different opinions.

Brendan wrote:or you could write an assembler in Java where the assembly source code is embedded directly into the assembler itself (and then write a boot loader in assembly).

In fact it's Java library, which imitates assembly syntax and produces machine code in raw binary form. What if there were things like "moveRegToReg(getFreeReg(),getFreeReg());" in a compiler code? Would it be the bootloader written in assembly after the program (the compiler) will be executed?

Brendan wrote:Basically; you're writing an assembler, and then writing a boot loader in assembly. You're not writing a boot loader in Java.

Basically, it's not as simple.

And a bit of english:

Brendan wrote:or you could write an assembler in Java where the assembly source code...

Can you clear the usage of the assembler and assembly words in different contexts? Is assembler a program? Is assembly the language? Or?

It was renamed again (after Combuster's attempt). Now it's Java For Starters.

I'm a bit worried by the large blocks of what is essentially inline assembly in the article. We wouldn't recommend this in C (but would rather link to an external assembly function) and shouldn't for any other language. In particular, the function 'writeBootCodeInitialization' is concerning as it seems to manipulate the stack segment and pointer from within a function. I don't know what calling convention you are using, but it seems destined for trouble.

I don't know much about java, but can you not use something like the members of sun.misc.Unsafe to, for example, provide code to say "Hello World!" from within a java function, and then use GRUB and assembly stubs like every other Bare Bones? This would presumably have the advantage of being portable to any other java compiler that can produce native code in ELF files?

Regards,
John.

Java for Starters... is that just to avoid a trademark on Java for Dummies? It surely doesn't do what the title suggests. Regardless, I had my chance of providing a better name, and you had yours. That means everyone else is free to pick another better title since it's a wiki. (*nudge nudge*)

embryo2 wrote:The problem with Java is - there's no native compiler for it written in Java.

Welcomed be all thy impure souls to the glorious scientologic church of self-hosting, where a certain absence of the code of faith is punishable by public shaming and a month in the moral dungeons. Woe thee, assembly developers, for thy assembler might not be written in assembly!

*ahem*


That said, javac is written in java, and thus formally self-hosting. Now add a chip with Jazelle support and the native part becomes flaky as well. Regardless, there are three known routes from Java to x86 Native: GCJ, ikvm+mono, and commercial solutions. The choice of setting up a beginner with unnecessary steps including dedicated embryo-vendor-lock-ins when these routes are much shorter but unexplored is a sure sign of a bad business case.

embryo2 wrote:The problem with Java is - there's no native compiler for it written in Java.

I think this is the point that we have been trying to make.

In reality, I think you could make the argument that x86 Assembly Language is the only (well-known) language that was specifically designed to generate pure x86 byte code, which is why it is the only language that can reasonably be used to create a boot loader (again, using well-known tools). All other common languages were designed to generate code to be run with the help of an existing Operating System to manage memory, resources, security, etc.

To put it another way, if you write Java code that won't compile with javac.exe, then I don't think you can really say that it's Java code. You would really need to tell people that this approach only works with your "custom" java compiler. (Which just happens to be written in Java, and which can be compiled with javac.exe).

We're just trying to keep from giving people the wrong impression. The wiki page on Languages does a good job of explaining all of this, so you may just want to add a link to this page at the top of your page.

I've actually got the exact same problem. My OS only "compiles" if you use my custom compiler, which I wrote in C#. (Or if you wrote one just like it).

In my case, my "compiler" is extremely small and straightforward -- it probably only contains 200 lines of C# code, because most of the work is handled by XSLT transforms, which .NET gives you for free. But the fact remains that you won't find any "other" compilers that will work with my OS source code.

If you write your OS in Assembly, C, C++ or Pascal, there are plenty of compilers that you can use. But this isn't the case for Java, C#, Basic (except perhaps for FreeBasic... see below), JavaScript, Ruby or XML. You would have to write your own compiler to use any of these languages. This just needs to be made clear to anyone who finds this site that wants to write an OS in Java.

EDIT: There is a wiki page for FreeBasic Bare Bones, which discusses using FreeBasic to write an OS. You may want to consider taking this same approach, by separating the Java x86 compiler from the rest of the OS, and giving it is own name, and documenting it separately...

@Embryo: Is the goal to write everything in Java without leaving the language at all (thus necessitating the opcode-emitting functions you are using to produce x86 code blocks), or to avoid dependency on an assembler written in something other than Java?

If the latter, I would expect it would make more sense to simply write an assembler in Java and use that for the assembly code. Note that the assembler doesn't have to use conventional assembly syntax (mine won't, though in that case the unconventional syntax is itself the goal, as I have explained elsewhere), and a (somewhat) Java flavored assembly syntax is entirely possible (though I am not sure it would have any specific advantages, it would depend on what you needed out of it).

As for terminology: an assembler is a program to translate a program in an assembly language (a human-readable analog of the machine code of a specific CPU type) into a stream of opcodes in a form that can be linked to other code and/or loaded into memory for execution.

I have updated the text and added the problem with Java section in the top of the article. The ambiguity issue was addressed and (may be) some better description is found.

jnc100 wrote:I'm a bit worried by the large blocks of what is essentially inline assembly in the article. We wouldn't recommend this in C (but would rather link to an external assembly function) and shouldn't for any other language. In particular, the function 'writeBootCodeInitialization' is concerning as it seems to manipulate the stack segment and pointer from within a function. I don't know what calling convention you are using, but it seems destined for trouble.

Yes, the ambiguity is here. But I stressed a bit in the updated version of the article the distinction between the inline and the for binary translation only versions of assembly. Actually there are both ways available using the proposed tools, but in case of the bootloader it seems practical to use just the binary translation without any connection with the pure Java code.

jnc100 wrote:I don't know much about java, but can you not use something like the members of sun.misc.Unsafe to, for example, provide code to say "Hello World!" from within a java function, and then use GRUB and assembly stubs like every other Bare Bones?

In fact I wasn't using the Unsafe class. The point was to make it possible to write as much in Java as it is possible for other languages. And the "Hello World!" with Java code only (no assembly emulation) is the second step after the bootloader (in Java) actually can load the "Hello World!" code into the memory. That's why there's no pure Java "Hello World!" yet.

jnc100 wrote:This would presumably have the advantage of being portable to any other java compiler that can produce native code in ELF files?

The portability is the special issue and it is discussed in the article. I prefer to have full freedom, it means there should be no C-world related dependence. It is possible to make some code for interaction of Java program and a C-based program, but it's a separate issue. And if somebody prefers to use some portable code then it's absolutely possible and such way is outlined in the article, but it's not pure Java way, so, the article concentrates on the 100% Java solution.

Combuster wrote:That said, javac is written in java, and thus formally self-hosting.

No. The javac.exe, obviously, is a Windows program. And some compilers, written in Java and with the name "javac" (just short form for Java compiler), compile Java code into the bytecode representation only.

Combuster wrote:Now add a chip with Jazelle support and the native part becomes flaky as well.

Jazelle executes Java bytecode.

Combuster wrote:Regardless, there are three known routes from Java to x86 Native: GCJ, ikvm+mono, and commercial solutions.

Yes, there are some tools, written in other languages. And I described the way of using them in the article.

Combuster wrote:The choice of setting up a beginner with unnecessary steps including dedicated embryo-vendor-lock-ins when these routes are much shorter but unexplored is a sure sign of a bad business case.

May be. But there's still no 100% Java solution available except the discussed one. So, you can name it "vendor lock", but actually what are the alternatives (except much less than 100% Java)?

SpyderTL wrote:In reality, I think you could make the argument that x86 Assembly Language is the only (well-known) language that was specifically designed to generate pure x86 byte code, which is why it is the only language that can reasonably be used to create a boot loader (again, using well-known tools). All other common languages were designed to generate code to be run with the help of an existing Operating System to manage memory, resources, security, etc.

Hopefully, something like this was added to the article. But it's not the case when everybody will agree after reading the article.

SpyderTL wrote:You would really need to tell people that this approach only works with your "custom" java compiler. (Which just happens to be written in Java, and which can be compiled with javac.exe).

Yes, it was mentioned in the article. And if there were Java only alternatives - yes, I'm ready to add links and to describe them also.

SpyderTL wrote:We're just trying to keep from giving people the wrong impression. The wiki page on Languages does a good job of explaining all of this, so you may just want to add a link to this page at the top of your page.

Added.

SpyderTL wrote:I've actually got the exact same problem. My OS only "compiles" if you use my custom compiler, which I wrote in C#. (Or if you wrote one just like it).

Yes, it's the common problem for all non standard solutions. That's why we have to do something better in the area of OS development in other languages (not C or assembly) description.

SpyderTL wrote:In my case, my "compiler" is extremely small and straightforward -- it probably only contains 200 lines of C# code, because most of the work is handled by XSLT transforms, which .NET gives you for free. But the fact remains that you won't find any "other" compilers that will work with my OS source code.

I have employed the "translation first" approach. Next step can describe the connection between the pure Java code and the binary world. It is the compiler's land.

SpyderTL wrote:There is a wiki page for FreeBasic Bare Bones, which discusses using FreeBasic to write an OS. You may want to consider taking this same approach, by separating the Java x86 compiler from the rest of the OS, and giving it is own name, and documenting it separately...

In fact the FreeBasic solution just uses some crosscompier instead of a compiler, targeted for a specific OS. It's like using GCJ with crosscompiler options.

Schol-R-LEA wrote:Is the goal to write everything in Java without leaving the language at all (thus necessitating the opcode-emitting functions you are using to produce x86 code blocks), or to avoid dependency on an assembler written in something other than Java?

The goal is to allow a developer to have tools. The tools, in turn, allow the developer to select a strategy, would it be the 100% Java or only 1% Java.

Schol-R-LEA wrote:If the latter, I would expect it would make more sense to simply write an assembler in Java and use that for the assembly code.

There is such option, but complemented with the inline assembly, invoked from Java. And even the "assembler in Java" is implemented in an extensible and flexible manner, so a developer can use it more freely for more goals.

I'm a little confused by this thread, and by the article (now titled "Macro Assembly Using Java"). If I were to use your platform, am I writing an x86 application in Java? Or am I writing Java that, when compiled and run, will emit an x86 application? For example: When I compile this Java source code, do I get object code/assembly code equivalent to this: Or do I compile the Java source code, run the resulting program on my PC inside Windows or Linux, and it produces object code/assembly code equivalent to this: Both are interesting and useful, I think, but very different. The former is a Java-to-x86 compiler that could be used to write an x86 program in Java. The latter is a Java-based macro toolkit, that could be used as a powerful preprocessor for an assembler (i.e. nasm with embedded, preprocessed Java).

Kind of related, I have a pet project where I use C# to build FPGA cores. Rather than write a core in Verilog or VHDL (which is translated into slice configurations), I write C# which, when executed under Windows, emits slice configurations like a macro (poor terminology!) processor. This has two benefits: (1) Verilog/VHDL preprocessors are very weak and lack basic expressiveness often required when duplicating modules/connections and (2) By emitting primitives directly you can produce cores vastly faster than Xilinx's compilers will produce on the corresponding HDL, but still let Xilinx optimize placement and routing.

It would be quite misleading to say that I'm writing FPGA cores in C#, however!

embryo2 wrote:

Combuster wrote:That said, javac is written in java, and thus formally self-hosting.

No.

Your seemingly infinite ability to delude yourself is truly amazing.

intx13 wrote:I'm a little confused by this thread, and by the article (now titled "Macro Assembly Using Java").

It was it's name, but it seems after second name change there were no more changes. And of course, if anybody want to change the name again it would be great to announce the change here (I mean it's bad idea to do it in somewhat sneaky manner).

intx13 wrote:If I were to use your platform, am I writing an x86 application in Java?

There are two ways. First - just x86 binary code emission. Second - it is possible to write Java native methods using the library. Second option requires compiler support. There again are two options. Option 2.1 creates DLL behind the scene and organizes corresponding native method call from Java application. Option 2.2 allows the compiler to embed native method calls in x86 version of pure Java application. All three options, of course, require some additional knowledge. The first option is described in the wiki article and may be it is possible to implement it without additional information, but I have no feedback about it.

intx13 wrote:The former is a Java-to-x86 compiler that could be used to write an x86 program in Java. The latter is a Java-based macro toolkit, that could be used as a powerful preprocessor for an assembler (i.e. nasm with embedded, preprocessed Java).

I don't know which name is correct enough. There's the behavior of the library and I hope it tells for itself. But if you have any questions then I'm ready to answer.

intx13 wrote:It would be quite misleading to say that I'm writing FPGA cores in C#, however!

Well, may be there are some discrepancies in naming, but I wasn't using anything else, when I was writing my OS, except the Java IDE called Eclipse. And there were no line of code in any other language than Java. There also were some programs like file manager or NASM (for some decompilation), but it seems the usage of these programs doesn't prevent me from calling my OS 100% Java OS.