OSDev.org

You have done a great job, of course, but it can be a bit better

Let it be a really good object oriented OS in XML

Actually it looks like this:

Where x8 is a method, 8 is number of bits consumed by the instruction, mov, AL and EBX are fields, the i is another method and returns an indirect addressing data structure.

In assembly it looks like this:

It looks like a parsing "on the fly" and looking for a set of predefined words to create some internal representation. But there already are many tools with such capabilities. There is customizable coloring of entered text, custom fonts and even some custom cursor behavior. The only problem here is - how to use the structure information about the user input. And it is mostly the problem of visualization. Efficiency is not a problem, considering your close attention to it. But what will be an efficient structure used for? It is a problem. Because user interaction domain is complex and very large. May be you need to read something about it? Just to get used to the well defined terms of the domain, to get acknowledged with ideas from the domain and so on.

But what is the goal of such manipulation? If you state it then you can divide it in some implementation steps. But more probably - you will find that it should be divided in a lot of subgoals.

Hi,



If we're only recycling the status quo and not doing anything different (because that's harder and takes longer); then it's a waste of time bothering to write software in the first place (note: this includes writing software for the purpose of gaining knowledge, as the knowledge gained would have no practical use). We must do something different or there's no point. "Different" can mean better or worse, but making things worse than pre-existing stuff isn't an attractive goal.

With this in mind, let's define 2 important words:

Success: Producing something that is better than existing stuff for at least one purpose (not necessarily "better for all purposes")
Failure: Failing to producing something that is "better for any purpose"; including:
• Failing to produce something that works
  
• Producing something that does work, but is not better than existing stuff

Note that my definition of success (above) does not in any way depend on adoption - adoption is just a side-effect of success and there are no guarantees. However, if something works and is better then it's more likely that people will adopt it, and if something either doesn't work or isn't better then there's no reason for people to adopt it.



Yes, but that only leads to failure.


Cheers,

Brendan

(I'm actually really enjoying this conversation...)

I actually am working in the opposite direction (basically, one XML tag per opcode byte). At this level, I'm creating identifiers for each of the platform specific opcodes. Taking my identifiers and turning them back into numbers would be redundant.

Now, with that being said, something that I could do, and have considered doing, is to write a new layer on top of this layer that is platform specific, but easeir to use (one tag per instruction). I would need to find a balance between verbosity/readability and complexity/functionality.

Readable (simple to write code, difficult to implement in XSLT):

Functional (simple to implement compiler in XSLT, but would require lots of tags):

Compatible (cross-platform, but would require converting in your head)

I guess, technically, I could do all three of these and let the user choose, since they would all eventually end up compiled down to the opcode specific version above.

Hi,



Yes, the traditional approach is for the IDE to parse text when it enters the IDE (either typed by the user or loaded from file system) so that the IDE can do "fancy features"; and then that work is discarded so that the same text has to be "re-parsed" every single time the file is loaded (by the IDE or a compiler or anything else). Mostly all I'm doing is reducing "work done then discarded" - changing the file format used for source code (from plain text to tokens) doesn't change anything other than efficiency.



I refuse to believe that text is the most ideal user interface for programming possible. Let's look at a few other fields. For electronics, circuits are described via. diagrams and not plain text. For architecture, CAD/CAM, mechanics it's the same - a graphical representation not text. For statistics we have charts and graphs. For geography we use diagrams/maps. Even for software there's been many attempts at representing code in a graphical way (UML diagrams, flow charts, Nassi–Shneiderman diagrams, etc). The reason for all of this is obvious - humans understand information easier when it's presented in graphical form.

This makes me "strongly suspect" that there's a better way of representing and interacting with (writing) code than the text-based editors we're all familiar with. The only problem I see is that the ideal user interface for programming hasn't been discovered yet.

Basically; I don't know what ideal user interface for programming is, I only know it hasn't been discovered yet and it's not text.

One part of my project's goals is to make it easier for someone (maybe a future me) to discover the ideal user interface for programming.

The largest thing preventing the discovery of the ideal user interface for programming is people's imagination. It's extremely difficult for people (including me) to imagine anything that they haven't seen before; and when an IDE reads text and writes text it's natural to assume the IDE is a glorified editor of text so most people don't even try to imagine anything better. Storing source code as "not text" helps to break the "IDE is a glorified text editor" assumption; and may be a significant step towards enabling the discovery of the ideal user interface for programming. The idea of a 3D environment where CPU/s are represented as machines that follow a track might sound awkward (and to be honest, to me it sounds more like a children's game than something a professional programmer would want); but that's just a way to encourage people to try to imagine something they haven't seen before (another potentially significant step towards enabling the discovery of the ideal user interface for programming).


Cheers,

Brendan

Hi,



You're letting "the tail wag the dog", if that makes sense.

Instead of designing a good programming language syntax (and then finding a way to implement tools that support the programming language syntax) you are doing the opposite - selecting the way you want to implement it, and letting the severe limitations of that "way you want to implement it" destroy the design of the programming language syntax.

Note that the most natural syntax for copying a register to another (for people who aren't assembly language programmers) is extremely obvious:



Cheers,

Brendan

Good guess.

Using ASM was my original plan. But I assumed that the "tools" that were available nowadays were more, um, mature than they were 20 years ago. That turned out to be wrong. Basically I would be developing in NotePad.

That's when I decided to go my own route.


Not for the "core" instructions, like MOV and LODSB, but there are a lot more instructions out there that could use some tooltips to help explain what it does and how it is used. Let's try an example... without google or intel manuals, can you tell me how to use the XLATB instruction? Or which instruction to use if I want to convert a short (16-bit) to an int (32-bit)? Or what happens if you set SP to 1 and then PUSHF?
Or how about writing ASM for an ARM9 without looking at the documentation? I can do that, and I have autocomplete, intellisense and tooltip documentation, and I didn't have to write my own IDE.

I would consider myself an expert C# developer. I've been using it as a business development language since 2002, and developed in Java before that. The naming conventions used in both C# and Java are well organized, and easily readable, at least for me. But I still use autocomplete, intellisense and I still read the tooltips that pop up as I'm searching for a specific method. That's because there are thousands of methods in the base libraries, and I couldn't possibly remember everything about all of them.

Autocomplete and Intellisense make less sense if you are programming in ASM, but I consider that a disadvantage to using ASM, and not an advantage.


(I thought that's what this whole thread was about... )

The same reason that I don't post ASM code and ask C# developers what they think. Bias.

All of the code is up on http://ozone.codeplex.com. Feel free to take a look and make any (positive) suggestions you want. Just saying it's "stupid" or "will never work" will be ignored.


Go ahead and give it a try. Download MESS, and write a non-text editor IDE for an Altair 8800. (Intel processor, up to 8KB of memory!)
Unless you are "too lazy"


Yeah, like loading an IDE into memory. Writing keystrokes to a file takes a lot less memory than a program that converts text to bytecodes in real time.


Awesome. Let me know when it's done.

In the meantime, I'll be working on my OS.

I know that sounded snarky, but, seriously, that would be awesome. There was a PSOne game called Carnage Heart. http://en.wikipedia.org/wiki/Carnage_Heart

In it, you built your robot, and programmed it using a visual programming language where you plugged in different "chips" into a giant grid of slots. The "processor" would start at the top left slot on the grid (0,0), and each chip would do it's function, and then it would redirect the cpu next instruction either to the chip directly to the right, or to the chip directly beneath it, based on some logic (if statement branch). As the cpu ran, you could see the processor "move" from chip to chip. I've always remembered that, because it's one of the first true visual programming languages that I'd ever seen.


And how many times, per second, do you build?

Same here. Eventually, I would like to be able to be able to run my own OS, and compile my own C#/Java-like code.

Ironically, I think you and I and embryo are all going to end up with exactly the same end result. We just took 3 completely different paths to get there. (And I fully expect to be the last to arrive...)

I would suggest that we all work together, on one project, but something tells me that would be a disaster!

So Visual Studio is irrelevant for writing C#? Should I just be using Notepad.exe, and calling CSC.exe to compile?


I... did not know that.

Basically, yes. (mov al, 'c', actually).

But I'm bypassing the ASM step. The xml above is recursively converted into "simpler", lower-level xml tags, until finally it's nothing but:
Luckily, all of this happens in the background, so you don't actually see any of this XML, unless you look at the temp files that are produced.

Once the code is "converted" down to this level, the compiler simply reads the <hex> tags, and writes them out to a file.

I'd just like to point out, XML syntax is pretty simple. Only 6 symbols (<:="/>), and one keyword (xmlns).

Once you've mastered those, you can use namespaces to organize all of your instructions, commands, functions, data, and constants that you need.

Tack on another 20 or so "keywords" for your base XML to Binary language (byte, short, int, label, etc).

Then all you need is a few thousand "keywords" for your CPU instruction set...

See? It's simple!

In order to cover all of the bases, I need several "layers" of code, each with its own language. The bottom layer is a direct one-to-one mapping from cpu instructions to xml elements. Above that, you get functions and variables, and above that you get classes and methods. (A little something for everyone).

I think the XML works well, by itself, for the low level stuff, but for the high level stuff, I think I'm going to need something that's easier to code. I haven't really gotten that far, yet.

Maybe I can clarify what I actually did in a way that focuses on the advantages of this approach... and separates it from the traditional approaches you would normally use.

There are a few developers (maniacs) out there who believe that Assembly is too high level. There are a lot of developers who think that Assembly is too low level, takes too long to code, requires a significant amount of reference documentation, and lacks any modern tools to provide assistance to new developers.

But if you want to write a boot loader, or if you want the absolute smallest and fastest program (at run time), you really have no alternative. Assembly has no competition at this level.

But it definitely has its faults. Each platform has its own "flavor" of assembler, meaning an expert in x86 assembly could be a beginner in ARM assembly. There is no inherent concept of functions, code blocks, namespaces (to resolve naming conflicts), scope (also to resolve naming conflicts) or variables.

Since it has no real competition, none of this really matters. But what if it did? What if there were a modern alternative to Assembler, that had some (or ideally, all) of these features, generated the same small, fast results as Assembly does, and could be used to write an Operating System from scratch, and could cross-compile to any platform, from any platform? (including VMs like Java and .NET)

It's a lofty goal, but I think that I have, at least partially, achieved it. Could it use some improvement? Definitely. Is it the "best" solution? Possibly not, but it does cover all of the bases above, and it uses tools that already exist, and formats that are well-known and well supported.

I'm always looking for ideas for improvement, or even new approaches that I haven't thought of. But "just use ASM" isn't a new idea, so you guys are going to have to do better than that.

The C# code is there to do what I can't do easily in XSLT. Reading the XSLT files, transforming the XML files, and writing out the bytes to disk is obvious. Other things include calculating checksums for copy protection on game consoles and writing data intensive structures, like file system table entries for bootable CD images. (These are all things that have nothing to do with the actual OS code, itself, so I don't feel too bad about cheating and writing them in C#)


The tools only translate one file at a time, which would take forever if you made a change to one file that impacted 20 other files. The C# code detects which files have changed, and which files are impacted and need to be recompiled, and recompiles them all at once.