Object Oriented OS

[embryo]

The copy register/operand stuff is a little complicated, but it matches the encoding of the instructions, byte-for-byte. You can see that, since I have autocomplete for free (thanks to the XSD files), I can make my instruction elements much more descriptive than just MOV, INC, JMP, etc.

Here is some inconvenience. If you create your library from the ground, then you should invent some names for mov, jmp, etc. But if you have invented your names, then all developers with assembly knowledge will need to learn your names in addition to the standard assembly syntax. But all xml developers will need to learn your names also. It means ALL people must learn your names. But if you name your instructions in somewhat more useful (for assembly developers) manner, then more experienced part of potentially interested people will have no need to learn more than they already have.

[embryo]

in order to call the GetDate method above, the shell has to find the method by name using reflection (late binding...), and call an "ExecuteMethod" function that gets the method's entry point and jumps to it.

This is where things start looking more like Java (and .NET).

It looks like Java from more than 10 years ago. Now Java has just in time compiler. It speeds things at the level of 2 orders of magnitude.

If you already have method address then I suppose you already have compiled method. But you still use reflection instead of calling code at existing address directly. It's not very efficient.

[embryo]

I uploaded my project to CodePlex, and posted a bootable ISO image, if you guys want to take a look.

http://ozone.codeplex.com

Interesting. But there's a lot of C# code files. Is it an XML OS?

[SpyderTL]

The C# code is responsible for actually writing the binary files to disk at build time. Everything else is in XML, XSD and XSLT files.

Most of the XML can be found in the OZone folder:

OZone/Platforms contains the platform specific enumerations that allow you to transform instruction names into byte codes and memory addresses.
OZone/Functions contains platform specific XSD/XSLT pairs that perform transformations from function names to inline instructions.
OZone/Classes contains platform specific XML classes that can be used by the Operating System to do reflection and execution of methods, etc.

Also, look at x86Console32, which is the source for the ISO that I posted.

x86Console32/BootLoaders contains separate boot loaders for each media type (CD, Floppy, Hard Disk, etc.)
x86Console32/Events contains interrupt handlers.
x86Console32/Programs contains the code for the console shell application.

[SpyderTL]

It looks like Java from more than 10 years ago. Now Java has just in time compiler. It speeds things at the level of 2 orders of magnitude.

If you already have method address then I suppose you already have compiled method. But you still use reflection instead of calling code at existing address directly. It's not very efficient.

I was talking about the command line shell application.

If you are compiling an application, then yes, you probably wouldn't want to use reflection.

[SpyderTL]

Here is some inconvenience. If you create your library from the ground, then you should invent some names for mov, jmp, etc. But if you have invented your names, then all developers with assembly knowledge will need to learn your names in addition to the standard assembly syntax. But all xml developers will need to learn your names also. It means ALL people must learn your names. But if you name your instructions in somewhat more useful (for assembly developers) manner, then more experienced part of potentially interested people will have no need to learn more than they already have.

The problem is that there is more than one MOV instruction.

MOV AX, 1

is a completely different CPU instruction than

MOV AX, [1]

And, in some cases, there is more than one way to encode a single ASM instruction. The compiler chooses which encoding is appropriate for the situation. In my case, at least at the level I'm working at, the coder decides which encoding to use.

[embryo]

OZone/Platforms contains the platform specific enumerations that allow you to transform instruction names into byte codes and memory addresses.

I've looked at it. There is something really interesting in such declarative description of things. But it seems that just a description is not enough. You have powerful set of tools and the language with a good descriptive power, but all the power seems has been thrown on making something like a table with one column of names.

You declare in your XSD an element, like AddRegisterToOperand8 for example, next you write this element in XML:

Code: Select all

<operation name="AddRegisterToOperand8" value="00"/>

And after it you write an XSLT like this:

Code: Select all

<xsl:template match="cpu:AddRegisterToOperand8">
		<xsl:element name="hex">00</xsl:element>
</xsl:template>

Here we have a name and a transform of the name into a hex number. In case of simple table we would see something like this:

Code: Select all

--------------------------------------
|  AddRegisterToOperand8  |  00 |
--------------------------------------

It looks like your XML, but a bit shorter. And actually the attribute "value" is not used anywhere in your program. It leaves us with the one column table. But there are two more files - XSD and XSLT. First is here just to have auto-completion and "onhover" description overlay from your IDE. The last is here to map element name to hex-formatted number. And mapping doesn't use the "value" attribute, but duplicates the actual value for some unclear reason.

Now the problem - having declarative description is not enough. If we need to look through three files and search for a particular name in two of them just to understand, that AddRegisterToOperand8 is mapped to zero - it is too tedious and time consuming. And you can compare such approach with the table above.

But the real power of declarative approach was shown in many examples of Prolog programs, for example. It would be great to see something close to such power in XML-based OS with it's declarative potential. But for now it isn't seems such great.

However, a first step can be small and complex. May be other steps will be great

[embryo]

The problem is that there is more than one MOV instruction.

MOV AX, 1

is a completely different CPU instruction than

MOV AX, [1]

And, in some cases, there is more than one way to encode a single ASM instruction. The compiler chooses which encoding is appropriate for the situation. In my case, at least at the level I'm working at, the coder decides which encoding to use.

The assembly syntax is not a mysterious thing that was fallen on us from Mars, but it is a result of a search for simple, clean and human readable representation of a machine code. And declarative power of XML can help you in creation of a simple and clean representation. But you have chosen way of separation of concerns. And now we need to declare many things in many files and all of this just to write MOV AX, BX. Many files instead of 10 signs. And even with all the auto-completion and the likes we have to describe our actions in really weird terms of 40 years old internal instruction representation of earliest processors. We have to write directly in machine code with all those instruction prefixes, opcodes, ModR/M, SIB, displacements, immediates and more. And we should learn the mapping from an opcode to a name you have invented. Is it anywhere that simple as writing MOV AX, BX?

[SpyderTL]

You declare in your XSD an element, like AddRegisterToOperand8 for example, next you write this element in XML:

Code: Select all

<operation name="AddRegisterToOperand8" value="00"/>

And after it you write an XSLT like this:

Code: Select all

<xsl:template match="cpu:AddRegisterToOperand8">
		<xsl:element name="hex">00</xsl:element>
</xsl:template>

Actually, I didn't write either of those by hand. I used XSLT to generate both of those from the XML file. Take a look at Platform/Platform.xsd, PlatformSchema.xslt, and PlatformTransform.xslt.

[SpyderTL]

It looks like your XML, but a bit shorter. And actually the attribute "value" is not used anywhere in your program. It leaves us with the one column table. But there are two more files - XSD and XSLT. First is here just to have auto-completion and "onhover" description overlay from your IDE. The last is here to map element name to hex-formatted number. And mapping doesn't use the "value" attribute, but duplicates the actual value for some unclear reason.

That's because it's not always a simple name to hex value translation. Sometimes there's more than one byte that is output, or there is some logic involved.

But in the case of the x86 CPU instructions, it just so happens that they are simple name to single byte hex value translations.

In order for the C# code to convert these files into a byte stream, everything must be converted into elements from the Programs/Program.xsd schema. Those are the only tags that the C# code understands.

[SpyderTL]

Now the problem - having declarative description is not enough. If we need to look through three files and search for a particular name in two of them just to understand, that AddRegisterToOperand8 is mapped to zero - it is too tedious and time consuming. And you can compare such approach with the table above.

If I'm writing a boot loader, or a console application, I don't really care that the instruction ends up being converted to a zero, just like I don't care if I write

Code: Select all

ADD AX, 1

that it ends up spitting out a zero. But it is nice to know that I can look it up, if needed.

[SpyderTL]

And we should learn the mapping from an opcode to a name you have invented. Is it anywhere that simple as writing MOV AX, BX?

That depends. Do you already know x86 Assembly?

Let me put it another way. Which is easier to understand?

Code: Select all

lodsb

or

Code: Select all

<cpu:CopySIAddressToAXAndIncrementSI/>

Also, keep in mind, that when you type <cpu:, you get intellisense listing every <cpu: instruction that there is, and you can type "CopySIA", and hit Tab to autocomplete. And you (could) get a pop-up balloon explaining what this instruction does, and that it can be used with a <cpu:Repeat/> prefix to copy a string of bytes CX characters long.

For learning purposes, I think the XML approach is much easier to understand. Plus, there's nothing keeping you from adding your own name-value pairs with names that make more sense to you. As long as you leave the old ones, everything will still compile.

[Brendan]

Hi,

For learning purposes, I think the XML approach is much easier to understand.

For learning purposes, you want the syntax accepted by the assembler to match the syntax used in the CPU's documentation (Intel's Manual).

Something like "<cpu:CopySIAddressToAXAndIncrementSI/>" is an extreme risk to human life - many people will die from the dehydration caused by uncontrollable vomiting.


Cheers,

Brendan

[Griwes]

lodsb, because I don't have to read a frakking sentence in code to recognise it. I don't have to read mnemonics (except thise crazy SIMD ones) - I remember how they look like. We are better at recognising known patterns than at reading long compilated bullshits. Stop this frakking madness and start using short, memorable (it's called a mnemonic, you know) and recognizable identifiers. Don't invent ridiculously long, not memorable and not easily recognisable ones just because you are too lazy to properly learn your tool before using it.

[embryo]

Actually, I didn't write either of those by hand. I used XSLT to generate both of those from the XML file. Take a look at Platform/Platform.xsd, PlatformSchema.xslt, and PlatformTransform.xslt.

It means you have an opportunity to regenerate such files in two ways - one, which would follow long command description pattern, and second, when a close to the standard assembly syntax is used.