My 64 bit multiprocessor x86-native Operating System and related projects

then it is x = y + (++z) ;

And with 2 spaces:

x = y + + + z ;

it is now x = y + ( + ( +z) ) ;

So spaces in C can change the meaning.

============== 31th October 2007 ===============

Trying to complete off this first phase AFA reasonable. It involves very difficult design decisions.

The language is highly notational like C, but using completely different paradigms. Each potential feature has advantages and disadvantages, I think the most important thing is to achieve design harmony.

I need to be really sure of the decisions, because eventually I wont be able to change them. There are still things I am not sure about.

I am designing-in the language functionality my OS requires, I am also resolving many problems that I have observed over the years.

============== 29th October 2007 ===============

Although various things arent decided yet, I am almost ready to begin the next phase of my language. The trickiest things I will return to later.

I am making full use of the compiler projects I was working on some months ago, so this can be regarded as a direct continuation of those. When I began on C++ I thought that would be a direct continuation, nope!

I am doing a lot of things differently from other languages, some things better some things worse.

Why should some things be done worse?

design efficiency, if the advantages of a feature are marginal then I may omit the feature. Especially if the feature complicates use and or implementation.

eg for the moment at least there is no "const" attribute, that is because it complicates use too much.

Basically it is a 100 times less work to do const optimisations in software than to utilise the "const" attribute. If you know something will be const then cache the value to a local variable, but only do this in the few places you need speed.

Also I dont want too many features so the language is easy to learn.

If you look at say ANSI C they remove features in order to keep use and implementation under control. eg:

int f( struct a { int b ; } *c ) ;   // (A)

is disallowed in ANSI C, you arent allowed to define types in function args.

Instead you just do:

struct a { int b ; } ;

int f( struct a * c ) ;

// (B)

Although (A) looks clever, if you look at (B) its a LOT clearer. Implementing (A) isnt a problem but it just complicates the compiler because for each argument of each function there are many options:

the arg type may or may not be defined. eg int f( struct b * c ) ;

the arg type may or may not be named. eg int f(struct {int b ; } * c );

there may or may not be an argname. eg int f(int);

there may or may not be an arg type eg int f(x);

If each compiler feature has many options it will take 4 x as long to learn the language and 4 x as long to implement it. So instead of taking 3 months it takes 1 year! instead of taking 1 week to learn it takes 1 month.

The above is an ANSI C example, which I agree with. ANSI C and ANSI C++ disallow different things! you can write a program accepted by GNU C and rejected by GNU C++ and vice versa. eg ANSI C++ disallows int f(x); From this it is clear that language design is subjective.

Anyway I am making my own subjective decisions.

I am creating a lot of new ideas as well, in fact some new ideas have already been removed for not being good enough! Some ideas are impossible to decide on,

I like old C, that was an authentic language. I think when Dennis Ritchie invented old C it wasnt meant for general use but was just a practical idea for implementing Unix. My situation is similar, I need to manufacture a language in order to implement my OS. I mustnt spend too long on it. Old C and AmigaOS are similar phenomena. Both were practical methodologies with tight time constraints.

My own time constraint is to try and get most of my projects completed within 2008. That is why I switched from C++ to my own language as C++ is too time costly. It is like in an exam, you are answering the questions but eventually there is just 10 minutes left on the clock and you realise you have to cut across a lot of things. Just a sentence where you want a paragraph etc.

The original plan was to use C, and to implement C++, that plan was succeeding but I was starting to see how long it would take: TOO LONG. And I could see that going via my own language would drastically improve the timeline. BINGO!

I think in computing the people who get to the top are the people with political abilities. I want to change that and get to the top via computing abilities. I want to succeed by creating something which is good without cheating my way to the top.

============== 27th October 2007 ===============

I am making rapid progress working on my own language,

I will complete off the C++ work so far sometime soon, I decided to go directly to working on my own language.

When the current C++ work is complete I will shelve that project and will continue the C subset at some point. It is very tempting to work on C++ but looking at the future timeline it will just delay my OS project too much. So far I have had 2 projects which I realised were futile, one was ELF and the other was Java. Both of which CAN be continued but I see no point. ELF is only necessary if you go via gcc, so once I decided to do my own C compiler ELF became unnecessary. Java was an error, I thought I was implementing Javascript, when someone pointed out Java != Javascript, I quit that project immediately, also I really dont like the design of Java.

I am resolving all the endless design problems of C and C++ in my own language. In a few seconds I can avoid a week of coding! The entire language will have an orthogonal syntax.

That is the modern approach to languages. An orthogonal syntax is one where you can process the entire source file without interpreting any symbols. You then only interpret symbols in later phases. To see that C's syntax isnt orthogonal:

x = (y)&(z) ;

Is the & a binary bitwise & OR is it the unary address operator? We can only know by interpreting the symbol y, if y is a type then the & is the address operator, otherwise & is binary bitwise and. So we cannot know just from the syntax, we need to understand the program to know.

The problem with a nonorthogonal syntax is it is very complicated to both interpret AND process the syntax. I achieved that via C-, which you can even try out if you email me. C- essentially orthogonalises the syntax by figuring its way around such nonorthogonalities. If you look at the project updates you will see I have been working towards C and C++ since August 2007, ie 3 months. ALL THAT IS UNNECESSARY FOR A WELL DESIGNED LANGUAGE! eg its all unnecessary AFAIK for the Modula languages, and I think unnecessary for Basic. (I dont know that for sure but think it is)

Now that work towards C and C++ wasnt a waste of time as I will continue that work towards C and COULD implement C++ also anyway! But I can see that it is too inefficient to do that now.

More importantly that work towards C++ has given me very deep insights into the flaws of C++'s design which I will use to design my own language.

The biggest design flaw of all is the nonorthogonality of the syntax, but there are plenty of other flaws. Instead of complaining about them better to implement my criticisms.

Historically speaking I think the idea of orthogonal syntax was AFTER C. C was such a powerful language that people were able to write cleverer programs, they discovered ideas better than those used by C. eg Modula type of languages are usually written in C!

One of the things I will be doing is removing features, eg C++ allows variables to be declared anywhere eg:

void f(void)
{
int x = 1 ;

x++ ;

int y = 2 ;
}

is rejected by GNU C but accepted by GNU C++. The problem with this idea is it makes it more difficult to see whether all allocated things are freed. If all variables are at the start of a compound construct then you only need to look there:

{
// variable declarations

// code

// variable freeing.
}

Basically this is more structured than what C++ allows, it is much easier to check for correctness. Possibly C++ does this to deal with const inits which cannot be done till later. But I am thinking of doing away with the const declaration as it slows down development too much: the disadvantages outweigh the advantages. const certainly has advantages but those arent such a big deal now that CPUs have speculative execution. In the few parts of a program where speed matters you should optimise things in software.

A lot of C++ is workarounds to deal with consts, if you remove the const idea then you dont need those workarounds. Seems worth removing features if it makes life easier for the programmer and compiler. A lot of the brilliance of C was the removal of features of earlier languages. eg C removed call by reference, major C feature: all functions are call by value. But later people have reintroduced that. Call by reference leads to complicated bugs. eg:

void f( int &x, int &y )
{
x++ ;
}

The statement x++ CAN increase y also! eg:

int z ;

f(z,z) ;

Most programmers instinctively assume different names are orthogonal, if you see x and y in a program, then x++ wont affect y. But if you allow reference variables you lose orthogonality of names. So its a good idea to disallow reference variables. The original C idea was that if you want to reference you go via pointers. That way the * operator means other variables could be affected. Put it this way: I can implement C++ without any of these new ideas and without any problems. This may sound strange but I am saying that old C is a better language than C++.

The above ideas arent decisions, the fact is that it is much easier to code with C than C++. The biggest problem with C++ is that the usage is too complicated. There are too many rules, too much thinking to generate code. A subset of C++ is very good, but another subset isnt.

============== 26th October 2007 ===============

I am considering a TOTAL CHANGE OF PLAN! To abandon implementing C++ and instead to create my own answer to C++ instead.

The reason for this is various: I have no intention of using C++ and dont want anyone else to either so its a bit of a waste of time to implement it. I can design and implement something much better in much less time. To understand the HUGE difference this makes ALL the C++ work up to now is unnecessary if I do my own language and compiler.

All the work up to now has been firstly because C uses a pre-processor and secondly because C's syntax is nonorthogonal to its semantics. By working on my own language firstly there will be no preprocessor AND secondly the syntax will be orthogonal. That immediately saves several months of work!

I can then go directly and implement my own OS using my own language. This will save months of time for my project schema.

I think I can complete such at least 4 x as quickly as completing the C++ project. C++ and C are HUGELY inefficient from an implementation POV.

Now I still need to implement C at some point as that is the only way to build my own language above my own OS. Without my own C compiler I can only build my own language from say AmigaOS. But I can implement C later. Its also MUCH MORE INTERESTING to design and implement my own language.

What I am thinking of doing is completing off the current C++ phases of work as that is just a few more hours of work and then working on my own language which should implement lightning fast.

Later on then I will complete the C compiler.

I have begun today working on this and the progress is so rapid that I think I have to do this.

IMO at least 75% of the work of implementing C and C++ is because of the maldesign. There are so many ways to overtake C++ that it would fill a book. A lot of things in C++ are unnecessary, eg C++ allows you to define classes within classes, but I cannot see any use for that. Just move all your classes to the top level. C++ allows namespaces within namespaces, but there is no point to that. You only need top level namespaces. Other languages just use top level namespaces.

C++ is a case study in overgeneralisation and disregard for implementation. In computer science implementation is everything, disregard it at your peril. You can do much more than C++ with much less work than C. Also I want something geared differently from C++, the reason I wont ever use C++ is it is wrongly geared.

Why reimplement C++ when it is much less work to overtake it?

So just as I am attempting to overtake Unix I will now attempt to overtake C++.

To understand the change of direction: I can overtake where I reached with C++ in a matter of DAYS!

You have to remember that C is from around 1978 and C++ is from around 1985, both are dinosaurs.

My plan is to create something which matches all the good points of C and C++ without the bad points.

My earlier compiler projects were all geared to a well designed language, I didnt realise then how badly designed C and C++ were. Anyway now I can use the earlier compiler projects for what they were meant for namely a well designed language.

============== 25th October 2007 ===============

The first version of the current C++ phase is complete and built. However this first version cannot be used yet until I resolve several problems. One problem is that I need to implement some features in C- which this phase depends on. Another problem is that an even earlier phase of the project needs to be modified.

Some features are missing also with this current phase eg I havent dealt with C++'s redefinable operators. I'll probably work on those later.

The phases so far deal with the features I mentioned which possibly I wont implement. The switch construct is done the ordinary way which IMO is the right way. The guys who invented switch had the idea that you test a value and take different actions according to which const it matches.

ie you test a value x and if it is x0 you take action0, if it is x1 you take action1 etc. where x0, x1 are consts known at compile time.

That is what I will implement and that will deal with all situations.

I will implement what I want how I want when I want, its my compiler and I can do whatever I wish with it. I want to use the compiler for constructing my OS. And the OS will only use the C subset of the compiler.

============== 24th October 2007 ===============

I am progressing now with the current early phase of my C++ project. I am implementing my own interpretation of C++ and NOT the official version. My interpretation is how one actually programs with C++ eg it will deal with the code in the tutorial book I learnt C++ from.

Generally speaking it is better to program in C, if you do objects via C tricks you get much better code than using C++. No idea why C++ and Windows are so popular,

An example where my code is different from Stroustrup's definition of C++,

Stroustrup regards a switch statement as having the form:

switch( expression_list )any_statement

This means that he and therefore gcc accept:

switch( 1, 2, 3 );

which is a bit of a pointless liberty. In order to do this he has to regard cases as being normal statements. But they are disallowed outside of switches. So eg gcc rejects:

void f(void)
{
case 10 : ;
}

The only point I can see is that it allows you to bracket off a case:

switch( 1, 2, 3 )
	{
		{
		case 10 : ........
		}
	}

But this leads to problems such as:

switch( 1, 2, 3 )
	{
	while( y )
		{
		if( x > 10 ){ case 30 : t = 10 ; }
		else { case 20 : t = 11 ; }
		}
	}

It just complicates the compiler. In fact to my amazement gcc accepts the above, but that is bad code as you SHOULD NEVER jump into compound statements. You can jump out but not in.

So with my interpretation I only allow the normal form of switch:

switch( 1, 2, 3 )
	{
	case CONST_EXPRESSION1 : case CONST_EXPRESSION2 : ......
		any_statements
	........
	}

default: also allowed instead of a case. Case expressions arent allowed to be bracketed.

That removes a whole wad of work that noone uses!

One problem with bracketing off a case mentioned above is it violates the idea of never jumping INTO a compound construct. I had a look at some open source and found everyone does switch cases the way I do. I think with my compiler I will disallow all jumping into compound constructs. You can jump forwards or backwards but only at the same level or outwards relative to {} constructs. Some C programmers even never use goto's at all as they object to all jumping.

{
a:
   {
   b:
      {
      c: 
      }
   d:
      {
      e:
      }
   f:
   }
g:
   {
   h:
      {
      i:
         {
         j:
         }
      k:
      }
   l:
   }
m:
}

:from c: you can jump to a: b: d: f: g: and m: and not to any other label. Jumping is more complicated with C++ than with C as C++ has automatic freeing of classes when you leave a compound construct: if you jump from c: to a: the code has to free things from the 2 enclosing scopes. I personally NEVER use the automatic classes as I like to control everything at the source level not at the compiler level.

This is all about "structured programming", where you try to only use very regular constructs. C and C++ are very unstructured languages, but by avoiding all the bad stuff you can write structured programs.

The advantage of structured programming is that bugs are less likely and it is easier to write, read and understand code. Also its much easier to write a compiler for a structured language than an unstructured one.

I personally do use goto's but usually I only use gotos forwards and to the same or an outer point in the scoping. Also I dont allow goto's to cross. But sometimes you need crossing gotos eg for a Turing machine:

state1: 

switch( get_symbol() )
	{
	case 1 : action1_1() ; goto state20 ;
	case 2 : action1_2() ; goto state7 ;
	....
	}

state2:
....

You can do that without gotos but its not as fast, just a bit slower. Structured programmers avoid gotos like this:

if( x > 3 )goto xyz ;

........

xyz:

is redone as:

if( x <= 3 )
	{
	.......
	}

xyz:

The problem with that is it increases the nesting of the code, if there are many gotos you end up with excessive nesting eg:

if( x > 3 )goto xyz ;
....
if( y > 4 )goto xyz ;
....
if( z > 5 )goto xyz ;
....
xyz:

becomes:

if( x <= 3 )
	{
	....
	if( y <= 4 )
		{
		.....
		if( z <= 5 )
			{
			........
			}
		}
	}
xyz:

The code is moving rightwards too much and is much more complicated to read than the original goto version. gotos are alright just use them carefully.

I may even change the project to "structured C++" where I only implement the things I use or approve of. That will greatly speed up the development. eg to not implement automatic variables:

xyz  a( 1, 2, 3 ) ; // DISALLOW
xyz *a = new xyz( 1, 2, 3 ) ; // ALLOW

The problem with automatic variables is first they are on the stack which is VERY wasteful of the stack, and second you need invisible deallocation code, so eg if you jump out 2 levels of nesting the jump has to be via 2 lots of deallocations before you reach the label. I can implement such things but it will just delay progress.

Another thing I want to disallow is:

struct { int x, y , t ; } a, *b, c ;
struct z { int u , v ; } w ;

Instead:

struct abc { int x, y, t ; } ;
struct z { int u, v ; } ;

struct abc a, *b, c ;
struct z w ;

Here I am disallowing unnamed types, that is rarely used and greatly complicates the compiler. And to disallow constructs which define and reference simultaneously. One problem with unnamed types is it complicates error messaging AND makes it unfeasible to allocate.

If you look at the above 2 fragments you will see the second one is much clearer to read and understand.

With real code, struct definitions tend to be in header files and variable declarations in source files.

Another thing I want to disallow is:

typedef struct x { int y, z ; } a, *x_t ;

This is even worse as it is doing 3 things: it is defining the struct, then the typedef is referencing the struct to define further types. Instead:

struct x { int y, z ; } ;
typedef struct x a, *x_t ;

This way typedefs only reference pre-existing types. Again this simplifies the compiler implementation.

ANSI C++ itself disallows various things allowed in C, eg C allows

int f( x, y , z ) ;

which noone uses, whereas ANSI C++ disallows that, instead you need:

int f( int x, int y, int z ) ;  // (A)
int g( int, int, int ) ;  // (B)

In fact (A) is better than (B) as you can create the prototype (A) just by cut and paste from the actual function. So maybe I should disallow (B).

Although (B) helps the compiler its NO USE for the programmer as you dont know which argument is what, whereas if you have:

int g( int width, int height, int count ) ;

Then you know exactly what to do. So I think I will disallow (B). If you look at the AmigaOS proto includes you will see ALL args are named.

GNU C++ seems to reject functions defined in functions, so I probably wont implement those! GNU C OTOH appears to accept them. Its not a big deal to implement them but I dont see the point,

These types of things improve code quality and simplify the compiler. I havent decided yet if I wont implement the above, but I dont want to implement them.

============== 22nd October 2007 ===============

I tried implementing C++ the way C++ is described in Stroustrup's book (Bjarne Stroustrup being the guy who invented C++), but that led to endless problems. So now I have reverted to the commonsense approach implementing C++ according to my interpretation of it. This is making better progress.

Although I am implementing C++ I only guarantee to attempt to implement the C subset of C++. I am only attempting to implement C++ as that will avoid duplication of effort.

I find Stroustrup's book is only good if you already mostly know what you are doing.

C++ generally tries to be too clever, eg it has 5 different ways to do typecasts, NONE of the new ways I have ever used! eg const_cast allows typecasts where ONLY the const-ness is altered. The thing is that in a well written program typecasting is rare so you shouldnt waste language definition on rare phenomena otherwise you get an inefficient language definition. In fact I mostly dont use the "const" construct as it slows down development too much. If I use "const" I have to perpetually stop and think: "is this a const?". The main advantage of "const" is it allows the compiler to cache the value of a const in a register. But todays computers are so fast that it doesnt make a lot of difference. Its only a tiny subset of a program that determines speed, in those cases you can optimise for consts in the source by caching the const in a variable in the program.

The other problem is that a non const variable could be locally const, eg window_move(....) changes x,y but doesnt change w,h. And window_resize() changes w,h but not x,y. So eg window_move(....) clearly doesnt change the area of the window.

============== 19th October 2007 ===============

I have completed the initial subphase mentioned yesterday. I have been looking at some of the amendments to C++. I cannot guarantee to implement each and every change they make to the language. When programming with C++ try and avoid things which COULD be interpreted more than one way.

Almost ready to begin the next subphase which is more complicated.

============== 18th October 2007 ===============

I have almost completed an initial subphase of work, this subphase is timeconsuming but straightforward. The subphase contains various problems so the next subphase will be working around those problems.

============== 17th October 2007 ===============

I am busy now working towards C++, there's a lot of gruntwork before there is anything of interest. The C- idea is making the work much better than it had been when I first tried to directly implement C++.

============== 16th October 2007 ===============

I am restarting the C++ compiler project now. Missing functionality in C- will be worked on as needed. For the OS project in fact I just need the C subset of C++ to function.

Anyway C- now patches the ambiguities of C++, all of which relate to the ambiguity between types and variables.

An example ambiguity is something like:

x::y::z < t, u > ::v (w) ;

That could either be a variable declaration of w or a function call with argument w. This particular example isnt too bad as the syntax is the same either way. But the problems are worse for say:

z = (x)&(y) ;

& could either be binary & or it could be address & with (x) a typecast. Those are syntactically different: binary & is binary_and(x,y) whereas unary & with typecast is type_cast( x, address(y)). The bracketing is totally DIFFERENT, the latter fragment has 2 operators the former has just 1. That is just bad design as it means the syntax is DEPENDENT on the semantics. With a well designed language the syntax is INDEPENDENT of the semantics and you can process the syntax first disregarding semantics. If syntax is orthogonal to semantics that makes it MUCH EASIER to implement a compiler. Via C- I can patch the problem, C- figures out which things are types and inserts @ before those. That orthogonalises the syntax, allowing the next phase to be much cleaner.

So if & above were the address operator then C- changes the fragment to: z = (@x)&(y) ; .

============== 14th October 2007 ===============

A first version of C- is now complete. This probably does have bugs and some missing features. AFA C goes anything missing should be straightforward to implement. And AFA C++ goes it should deal with NORMAL programs with missing features straightforward. If you really push C++ to its pedantic limits then there could be problems.

One feature I havent implemented yet is "friend", I will implement that later on. A complicating factor is a friend declaration to a function not yet declared, which scope is it in? C++ does specify how to deal with this. TBH C++ is a bit overanxious eg my C++ compiler will be ENTIRELY written in C where ALL fields are public. Stroustrup gives the example of multiply( matrix , vector ), where for speed multiply needs to access private fields of both matrix and vector. So he makes multiply a friend of matrix and vector.

The real problem is that the object paradigm has limits and multiply() is something BEYOND the limits of the paradigm, so he has to hack the object paradigm to deal with it via the "friend" idea.

Objects are variable centric, multiply() is an API centric problem. C++'s problem is its vantage point is wrong, C++ is an object centric language. Real programming is API centric.

The C++ tutorial book I have doesnt mention "friend" at all so it must be a more obscure feature of C++.

============== 13th October 2007 ===============

The C- "using" bug took some work to resolve but its resolved now. The "using" directive means C++ tries to resolve things relative to several namespaces. On resolution the compiler must still check the remaining namespaces: multiple resolutions mean an ambiguous resolution.

using namespace x1 ;
using namespace x1::x2 ;
using namespace x3::x4 ;

typedef y z ;

:if

x1::y

x1::x2::y

y

The bug was that on finding a resolution the later unsuccesful resolutions were overriding some of the successful resolutions parameters resulting in a failed resolution. I just had to backup all the parameters on success. Finding the bug was the tricky thing, resolving it was just a few lines of code.

Just one tricky thing left to do and I will probably then begin on the C++ compiler.

============== 12th October 2007 ===============

I completed implementing the "using" directive today for C-. Currently there is a bug with this so I am working on that at the moment.

============== 11th October 2007 ===============

The most difficult part of C- template classes are now implemented and built but not fully debugged. Working on a bug at the moment. There are various things not yet implemented. I really dont like C++ at all, its too complicated and the syntax is too inefficient. You can do much more with much less. Templates are a very inefficient and complicated way to do things, a total pain to implement.

============== 8th October 2007 ===============

I think I have the trickiest part of the C- templates implemented. I am not completely sure as templates are very complicated to implement. I need to study very carefully what I have done. Using templates isnt too bad but to implement them is very tricky. Even GNU's C++ has bugs with their templates, thats a sign of bad language design if mainstream compilers have difficulty implementing a language.

630pm: I found some problems I hadnt dealt with. Those are now dealt with. Looking now for any further problems. Later implementing C++ will be very similar so this in a way is good preparation for that.

============== 6th October 2007 ===============

The work on C- templates is getting ever more complicated, nonetheless I am making progress.

============== 5th October 2007 ===============

I am working on C- templates at the moment. This is the most difficult part of the C- subproject. The main use of templates is for recursively variable types: variable types with variable "subtypes", for example:

template < class x, class y > class z
	{
	template < class a, class b > class c 
		{
		a a1 ;
		b b1 ;
		x x1 ;
		y y2 ;
		} ;
	} ;

Here c is a variable "subtype" of the variable "type" z. (I say "subtype" and not subtype as that is probably the wrong word but its the best way to refer to the phenomenon.)

It took many days of effort to find a way to implement such variable types. I am currently implementing the plan I eventually arrived at. All the C- and C++ work runs above 68k-AmigaOS as a cross compiler.

C++ templates allow references to nonexistent things eg in the above fragment you can refer to eg

x::t

x::t

Stroustrup the inventor of C++ doesnt mention typename in his book, so he probably wasnt aware of the problem. Anyway I will use GNU's typename idea to deal with the problem as that seems a reasonable idea.

It does appear to prove that C++ as described by Stroustrup is truly ambiguous.

I dont know why everyone backed C++ as it is such a royal pain to implement.

============== 16th September 2007 ===============

The C subset of C- is complete and the C++ subset is mostly done, just one tricky thing left to implement is templates. C- so far will catch a lot of errors. But some things it wont, and it allows a certain amount of nonsense. Originally I was going to prefix things like

a::b::c

class

typedef int a ;

class a z ;

With GNU C++ class and struct can only qualify something which is either a class or struct, eg struct can qualify a class and vice versa.

So instead C- will prefix such ambiguities by @, I think some of the GNU build tools do customisable C code using @ symbols. The @ symbols will be prompts for the C++ compiler to know whether a construct is a type or a variable. It is much work to determine which. An example of what C- will do:

namespace 
	{
	namespace a
		{
		typedef struct b { typedef int u ; int v ; } w ;
		}
	}

a::b::u f( a::w::u x ) ;

will be redone by C- as:

namespace 
	{
	namespace a
		{
		typedef struct b { typedef int u ; int v ; } w ;
		}
	}

@ a::b::u f( @ a::w::u x ) ;

So all that C- does is insert @'s, but that is a complicated thing to do and it has to deal with multiple inheritance and templates. Currently it ignores private and public qualifiers as any errors with those will be detected by the C++ compiler. The inserting of @'s AFAICT removes all the unpleasant ambiguities of C++. I could actually continue C- to be a C++ compiler but it looks better to do C++ as another phase.

============== 12th September 2007 ===============

I have made some progress now towards C-. Where there is a conflict between C and C++ I will go for the C++ idea.

eg C++ doesnt allow the following 2 lines of code:

int f(x,y) ;
int f(x,y){ return( x + y ) ; }

whereas C allows both. With C++ you have to do:

int f(int,int) ;
int f(int x, int y){ return( x + y ) ; }

which is also accepted by C, so I will only allow the second fragment. The latter makes implementing the compiler easier as you dont have to deal with int args as a special case eg there is a further complicating factor for C if you have:

typedef double x, y ;
double f(x,y) ;

Are the arguments of f integer or double?

Probably double, but the problem is that if you are reading some code and there are endless header files you dont have the time to find whether by coincidence x and y are types. Disallowing this means that you ALWAYS know that a prototype argument ALWAYS starts with a type.

C- at the moment does some correctness checking, eg it will deal with:

typedef struct { typedef struct { typedef int x ; } y ; } z, (t), u ;

typedef t::y::x v ;

As you can see, with C++ things are much more complicated than with C.

Notice that C++ structs are almost identical to C++ namespaces.

============== 10th September 2007 ===============

The work towards C- is proving very tricky. I am progressing but very gradually.

============== 5th September 2007 ===============

I want my system to deal with gcc C++ headers, gcc is using really obscure C++ functionality. Admittedly that is just header stuff so my own headers dont need to use such things. it has things like:

struct x : public y { ..... }

And I thought that was only allowed for classes. A strange construct gcc uses is:

extern "C" { .... } 

It does lots of such strange things, here is another one:

__extension__ typedef long long _G_llong ;

What on earth is

__extension__

It is all quite infruriating. I dont guarantee to support all such things as I dont want to spend 10 years implementing stuff that NOBODY uses.

============== 4th September 2007 ===============

I managed to resolve the compiler subproject bug. I tried the preprocessor on a demo C++ source file, there was a preprocessor bug with this. It took a lot of work to locate the bug. I am continuing now on the first phase of C-. I have 4 languages to consider: C-preprocessor, C-, C and C++.

The initial version of the first phase of C- located some problems in the AmigaOS includes: some function prototypes use an arg name "template" but that is a keyword of C++.

11pm: On a certain example file the system freezes up after trying the preprocessor, trying to determine the problem.

1am: at last resolved the freeze up, it was to do with resetting the current directory and unlocking directory locks in the wrong order on AmigaOS. The preprocessor changes current directory to the directory of the include it is currently processing.

============== 3rd September 2007 ===============

Trying out the initial version of the first phase of C- on a real example has led to a very deep bug in the compiler subprojects. I can see 2 possible ways of dealing with it, am making a study of those

============== 2nd September 2007 ===============

In order to continue towards C++ I have had to make some major improvements to the earlier compiler subprojects.

I am continuing now with the C- project. Its a very unusual project as it is both superficial and difficult.

I have got an initial version of the first phase of the C- project, I have been trying this out on a real source file and resolving the problems. Right now it has gone 3% through the file before halting on "extern", so I have just corrected that. C- is supposed to understand ALL C and C++ source files.

============== 21st August 2007 ===============

The C++, C and C- work is proving to be very tricky,

I think today was the trickiest day of all my projects so far. I dont even know if the C- idea will work, even if it does C is a very tricky language, for instance C's function types are almost impossible eg:

void (*(f( int (*g)( int, int ) )))(int (*)( int (*)(void) ) ){ return( 0 ) ; }

That's not a void function even though void is written there! (if you compile it with gcc you will see no error)

Although C is nice to code with, implementing it is an adventure into hell.

============== 20th August 2007 ===============

A new ambiguity which I think I cannot deal with:

x(*f)(a);

So it looks like I have to go for a dialect of C(++) similar to gcc's. My implementation though will be quite different, my plan is to create a low level language C- which takes a preprocessed C file and inserts a marker keyword at all

a::b::c::d

330pm: I am working on the above idea now, if

a::b::c::d

class a::b::c::d

515pm: change of plan, I will do C- as a standalone language, it looks too complicating to superpose C++ and C-.

630pm: I am working now on the C- project!

1230am: the C- work continues, this is a gruntwork subproject.

============== 19th August 2007 ===============

Another ambiguity:

x (y) ;

That could either be a variable declaration of variable y of type x, OR it could be a function call, function x with argument y.

The irony is that a well designed system is much less work,

I have had an idea, the way to deal with all these situations is to avoid unnecessary bracketing. So if the compiler sees an ambiguity it will assume the bracketing is necessary:

x (y)

x y

(x)&y

x & y

(x)(y)

(x)y

sizeof x

sizeof( x )

The only possible problem is that an expression could be from a macro, I think in the rare cases where that happens you have to work-around things somehow eg the user supplies the bracketing. Usually macros rebracket all args, but for the rare cases where the above idea conflicts, the caller of the macro can supply the bracketing. I'll wait till I see an actual example.

If the compiler interprets different from what the user meant it will always generate an error.

8pm: So far the above idea looks feasible, it does mean the compiler is not completely compatible with gcc, but it simplifies the implementation. And it must be very rare for there to be any problems. The central ambiguity is that

a::b::c::d

The advantage of the above idea is it is entirely syntactic and local.

145am: one further ambiguity:

x *y ;

As with the earlier idea, any misinterpretation will result in a compiler error, so it cannot lead to problems. If these ideas conflict with another compiler then all you do is conditional compilation via #if etc!

The advantage of these ideas is it creates a clean dialect of C, it basically orthogonalises the phases of compilation. I think gcc's approach must be nonorthogonal with dependencies between the phases.

============== 18th August 2007 ===============

Further to yesterday I have found another C ambiguity:

(x)(y)(z)(t)

ie

x, y, z

Each of these ambiguities is extra hassle.

There are endless complicating factors, here is one: in a for loop the first part of the "for" is a list of statements, but can any statement at all be there? eg is the following allowed?:

for(  for( i = 1 ; i < 10 ; i++ ){ printf("hello");}, int j = 0 ;  j < 100 ; switch(j){ case 0 : ;})
	{
	}

Having say

for( i = 1 ; i < 10 ; )i++ ;

for( for( i = 1 ; i < 10 ; )i++, x = 10 ; ; );

The only way to decide is to see what gcc does, if gcc doesnt allow something then I wont. As mentioned on 11th August gcc tends to disallow tricky scenarios.

Kernighan and Ritchie, and Stroustrup say absolutely nothing about this problem, Stroustrup appears to have just copied K&R and gcc rejects for loops in another for loop's initialisation. In fact K&R refers to the initialisation as an "expression". (K&R first edition page 56 says

for( expr1 ; expr2 ; expr3 )statement

Well a true expression is a bit pointless, but gcc DOES appear to allow expressions as statements eg "1==1;" is a valid statement with gcc even though it is pointless.

Semantically speaking the first part of a for is statements, the second part is a boolean expression and the last part is reinitialisation statements. Note that for and switch statements arent expressions, perhaps that is the idea. Its an incoherent setup eg it allows

for( 1, 2, 3, 4, 5 ; ; );

============== 17th August 2007 ===============

Continuing with the initial C++ work, the work is complicated and slow moving.

One problem is that C has various ambiguities eg:

typedef int y ;

void f(void)
{
int y = 5 ;
int x ;
int z = 10 ;
x = (y)+z ;
x = (y)-z ;
x = (y)&z ;
}

The last 3 statements are all ambiguous as

(y)

There is also an ambiguity with sizeof:

typedef struct { int a, b, c ; } x ;

int f(void)
{ 
int x ;
return( sizeof( x ) ) ; 
}

Is that sizeof of a variable or a type? gcc appears to be going via the local variable, but that is nonetheless an ambiguity eg someone could have sizeof(x) in a macro intending the type, but the macro could in fact give the size of a local variable. Ambiguities are ok if they are ambiguities of things of the same category, eg an ambiguity between types, between variables, between functions. But an inter-category ambiguity is incoherent design eg between a type and variable,

============== 15th August 2007 ===============

I have some very initial work towards C++ done. Some very low level gruntwork,

============== 13th August 2007 ===============

130am: the C preprocessor is now preprocessing the example file from the compiler project correctly. There were several bugs. I find the preprocessor quite a painful project. My pre-processor is stricter than gcc eg gcc allows repeated definitions without error eg:

x.h is:

#define X  1

y.c is:

#include "x.h"
#include "x.h"

int x = X ;

gcc will compile that without error! My pre-processor will give an error message of a redefinition, it then uses the new definition and continues.

I think I am now ready to continue with the C++ project.

8pm: I am coding now C++. This is a continuation of the compiler subprojects so far. The C++ compiler will compile the output of the pre-processor project.

============== 11th August 2007 ===============

Trying out the pre-processor I realised a tricky problem:

#define y  100

enum x { y, z, t } ;


void f(void)
{
int y ;


y: ;
}

The pre-processor is meant to be run first, but then the y in the enum will be substituted by 100. The "int y" will become "int 100" and the y: will become 100: If they didnt that would be very tricky to code, fortunately gcc does strictly substitute the y's and then you get compiler errors in each case. I am thankful that gcc substitutes the y strictly in all situations. Looks like each potential problem will be caught by the compiler when it works on the preprocessed code.

The OS project will only use C and asm, and the C++ compiler is being done in C. The reasons for implementing C++ are various, eg if I only implement C it wont be forwardly compatible with C++ so I will have to do yet another project to implement C++. C++ OTOH is backwards compatible with C.

I am not completely enthusiastic about C++!

Some of C++ is very good and some isnt.

============== 10th August 2007 ===============

I am working on the current pre-processor bugs before continuing towards C++.

I have resolved the bug:

#define x() y

where there are no args, there is a further bug that if I call the macro eg:

#define x() y
x()

that there is a bug with this. I will look at that next. There is just one further C++ topic I need to study which is the C++ exceptions on which I need further info in order to implement them.

530pm: all the empty arg bugs are now resolved. The preprocessor code for #define is very complicated. There may be further bugs elsewhere. The pre-processor is now preprocessing gcc's < stdio.h > without error. I want to implement one further feature for the preprocessor and then will continue with C++.

1130pm: the gcc example now preprocesses correctly. I tried next to preprocess one of the compiler project source files, that revealed 2 further bugs. But interestingly it located errors in the Geekgadgets AmigaOS includes, eg exec/io.h has:

#ifndef EXEC_PORTS_H
#include "exec/ports.h"
#endif /* EXEC_PORTS_H */

That is WRONG! as it should be EITHER

#include "ports.h"

OR it should be:

#include 

"somepath" in C represents a filepath RELATIVE to the current file, the above is wrong, there were plenty further such errors!

============== 9th August 2007 ===============

I am gradually getting the 64 bit C++ compiler project started. I have been doing a study of C++ for that and figuring out how to utilise my various compiler subprojects for this.

I will try and implement features such as templates, multiple inheritance, operator overloading etc.

I decided to try out my C pre-processor which I completed last November on the gcc includes via a small test program. It malfunctioned at one point, I have that bug resolved now. I retried it again and there is another bug it doesnt deal with macros with 0 args eg:

#define x()   y

I will try to correct that bug. The preprocessor is meant to be compatible with any C compiler, in particular it should be compatible with gcc.

============== 2nd August 2007 ===============

I am restarting my compiler project. According to the updates I completed the C preprocessor 25th Nov 2006, almost 8 months ago! Just doing a study of where I reached. The build for the C preprocessor is highly convoluted, am just making sense of that.

The project will now be to create a C++ compiler and not a C compiler as originally planned.

============== 1st August 2007 ===============

330pm: I am making further progress now with the bug mentioned yesterday. I now know more precisely what the problem is. It is a coincidence situation where 2 completely different phenomena happen at exactly the same time and the code overlooked this situation. I havent yet located where in the code the problem happens but am progressing. There may well be further bugs.

335pm: it looks like a trivial error: I wrongly had jne where it should have been je! je deals with the coincidence, jne leads to garbage. It has taken more than 2 days of impossible work to locate that!

1130pm: well that one wrong ascii character removed now has both the tower and laptop launching 6 new tasks and then the launching task gets frozen out. The launched tasks are functioning fine, so I now need to debug why the launching task gets frozen out. Anyway it is major progress.

220am: this next bug is proving equally evasive.

430am: found the next bug, about to try that out. In fact above there was an error message but the output of the other tasks obscured that. I eventually found another spelling error!

5am: WHEEEEEHOOOOOOO! The new multiprocessor pre-emptive multitasking system is now fully functioning. In the experiment the launching task and all 11 launched tasks are functioning both on the 1-cpu and the 2-cpu systems. This new system tries to relaunch tasks to the same CPU whenever possible. This is to optimise cache usage, sometimes tasks will be relaunched to a different CPU. This is done via a complex heuristic optimisation. The effect on the experiment is quite dramatic. With the original system each successive echo is on a different CPU (see earlier video) eg: 111[ 0 ] 222[ 1 ] 444[ 0 ] 777[ 1 ] ... the cpu keeps alternating. With the new architecture the output is more unusual eg: 111[ 0 ] 555[ 0 ] 333[ 0 ] 888[ 1 ] 777[ 0 ] 444[ 1 ] 222[ 1 ]...

In this hypothetical output the architecture is preferring to relaunch task 5 to the same CPU as the previous task. The original architecture would have relaunched task 5 to cpu 1. The acid test is whether things run faster, that will have to wait till later. I will try and upload a video of the new architecture sometime.

I should say that currently I have only tested out all tasks being the same priority. Eventually I will try out unequal priorities, so there could be bugs in that.

I think I am ready now to restart the compiler project, the aim now is to implement a C++ compiler which will be 68k-AmigaOS hosted. I will make a 68k-AmigaOS hosted demo of this available, email me if you want to try that. It is too early for betatesting as that would require betatesting the OS itself which is no-can-do at this point.

============== 31st July 2007 ===============

Making very slow progress on the bugs.

315am: After some 2 days of effort I have at last determined one scenario which freezes up the system. Its a needle in a haystack problem, the bugs can be anywhere at all. I have to continue with this tomorrow.

============== 30th July 2007 ===============

I am looking at difficult multiprocessor bugs. At the moment the bug is that the one CPU locks A and then attempts to lock B. The other CPU has B already locked and attempts to lock A. Both wait forever. I thought I had designed the system so this couldnt happen. I know what the problem is but havent yet determined the 2 places in the architecture where the conflict is arising.

Have found another similar bug, so far none are resolved, it is proving very difficult to locate. Just about to try another debug build of the OS.

1015pm: I am studying the code, I have found one bug already. I have just removed that and will see if there is still a problem. If I can get the code to function this week I will be doing well!

============== 29th July 2007 ===============

Almost 3 weeks since the last update! I implemented some major multiprocessor enhancements to the multitasking. I have now split up the current module of the OS into smaller submodules. I also made space improvements: eg removing obsolete code and replacing some macros by functions etc, I managed to reduce the size of the OS by 67K. I am now debugging the new multitasking enhancements. Just about to try out yet another build.

Well, on the uniprocessor 6 of the 12 tasks run without problem and the other 6 dont appear to be running. On the dual core none of the further tasks run. Looks like I have some debug work to do!

750am: after a lot of work on the 2-cpu system I now have one of the further tasks running. A lot yet to do.

============== 9th July 2007 ===============

I am working on some major improvements to the multiprocessor multitasking. So at the moment the code doesnt function but I have a backup of the last functioning version just in case.

============== 8th July 2007 ===============

I spent most of yesterday on one of the trickiest bugs yet. That bug is now resolved.

Anyway the semaphored text is now functioning perfectly, I may upload a video of this. It is a very interesting phenomenon as the tasks AND cpus change after each echo eg 111[ 0 ] 444[ 1 ] 333[ 0 ] 888[ 1 ] ... It goes through all cpus and all tasks before repeating.

This means the output is very similar regardless of the cpu count.

Here is a video of the text semaphores. This time I set the build to use white text on a blue background so it looks like an Amiga 500! I can toggle off and on the text by pressing t on the keyboard, this is done by toggling the echo string function with a no-op function. That isnt in the video as it could be misunderstood as a malfunction!

I am working now on some major enhancements to the multitasking, this is a subproject.

============== 7th July 2007 ===============

Trying to get the improved semaphored text to function. Finding very tricky bugs. The code isnt yet properly functioning, so the multitasking subproject isnt complete yet.

============== 6th July 2007 ===============

A specific build of the system was freezing up on the tower each time. I eventually found the bug which was a garbage pointer. :it was a precise coincidence bug, the bug was only rarely invoked. But it happened each time at exactly the same point JUST on the tower.

I am now doing gruntwork eg most of today was making the text echoing object oriented (in asm!). The reason is that once I implement graphics I will need totally different text rendering via the same code. It was working on this that the bug above happened.

Next I am going to redo the text echo via proper semaphores. As you can see in yesterday's video all tasks access the same space for text, so only 1 can be allowed access at a time. With 2 cpus the system would crash if both accessed the screen at EXACTLY the same time. So when 1 task is writing, other tasks need to be held off with semaphores.

Much later on there will be windowing and tasks will have their own private windows to echo text in.

Looks like I cannot use proper semaphores with my text as that interferes with the debug system. Text in general can be semaphored but not this particular low level text. But I can use an improved version of the text. I am running into some really strange problems eg testing out some things at first everything looked alright but eventually there were just 2 tasks left. All the others disappeared! I eventually found a bug in the system where tasks were vanishing. Any task which reached that part of the system vanished! That problem is resolved. I now keep verifying that all 12 tasks are there. One of the "features" of the architecture is proving to be a bug. So I have removed that feature. I spent a lot of time on that feature and didnt foresee the problem. I am looking at an inefficiency problem at the moment.

============== 5th July 2007 ===============

The 64 bit multiprocessor pre-emptive multitasking seems to be functioning fine now. I havent been able to get further malfunction. There could still be bugs so I will continue to study the code.

I think I will upload a video of this in action.

here it is. This shows the tasks once all are running. Task 0 echoes 000[ m ] repeatedly where m is the cpu number, task 1 echoes 111[ m ], ..., task 10 echoes 101010[ m ], and the launching task echoes zzz[ m ].

So if you see 111[ 0 ] 444[ 1 ] 111[ 0 ] 444[ 1 ] ... that means task 1 on cpu 0 wrote 111[ 0 ] then task 4 on cpu 1 wrote 444[ 1 ] etc. The cpu numbering is an OS numbering of the cpus. 0, 1, 2, ...

From this you can see that there are 2 cpus, [ 0 ] and [ 1 ] and also that the interleaving is PERFECT. the 2 cpus perfectly alternate echoing. Each time I press a key the next screen of text occurs. Because of the way it is written task changes happen very soon after the key is pressed so each screenful tends to be a totally different pair of tasks. Later on I keep the key permanently depressed. This text echo isnt ideal as it doesnt use proper semaphores but uses hacked inefficient semaphores. Later I will redo it with proper semaphores. All the tasks here are the same priority,

If I run this on the tower which is 1-cpu you will see just eg 111[ 0 ] 111[ 0 ] 111[ 0 ] 111[ 0 ], so you can tell how many cpus there are by running this demo. Here is the demo of the 1-cpu tower version.

============== 4th July 2007 ===============

The debugging continues, I have just found a fairly major bug where I forgot to check for some bit! I am just about to try that out now.

715pm: several bugs later and it still isnt functioning. I have just now managed to locate one part of the problem.

840pm: made a lot of progress on the bug, not yet resolved.

10pm: looks like the central problem was a typo! The tower is now correctly functioning, will try it on the laptop next.

1115pm: well, it is almost functioning now, still some further bugs. On the 2-cpu laptop several tasks get launched and everything looks correct but at some point only 1 ends up running. The other tasks are frozen out, I'll continue working on this tomorrow.

340am: I put some debug code but that has affected the behaviour as now each time on the laptop the 12 tasks pre-empt perfectly. So there is a bug somewhere but it is a very precise bug.

With uniprocessor multitasking if task 1 echoes 111 111 111 ... and task 2 echoes 222 222 222 then you get:

screen(s) of 111 111 111 and then screens of 222 222 222 ...

However with multiprocessor multitasking you get interleaved output: 111 222 111 222 111 222 as both cpus are SIMULTANEOUS. The interleaving when I tried it out was PERFECT, with 12 tasks and 2 cpus it is even more fascinating. I'll upload a video once I have debugged things further.

============== 3rd July 2007 ===============

I am continuing with the work towards pre-emptive multiprocessor multitasking. This is a very complicated problem as there are a lot of potential coincidence bugs. There is a problem of a system which functions most of the time but eventually malfunctions.

615pm: I have just tried an attempt at the work, it malfunctioned. Trying to find what the problem is.

930pm: I am making some progress with the bug. The code malfunctions differently on the uniprocessor tower from the dual processor laptop. Its going to take some time. Very complicated problem as there are multiple tasks on multiple cpus and the bug is with the entirety.

============== 2nd July 2007 ===============

1245am: I have run my first pre-emptive multitasking code successfully (after debugging). Just 2 tasks here, the one busy loop echoes "hello " and the other busy loops "world ". Both echoing to the same space as there isnt any windowing yet. These are kernel tasks so this is pre-emptive kernel multitasking.

Further work to be done eg I havent yet implemented task exit, currently tasks must NEVER exit. Various other things also not yet implemented. But the semaphore subproject is complete, the multitasking subproject is almost complete. Enough implemented for the multitasking to function.

This is a fully 64 bit multiprocessor OS. The multitasking and semaphoring is fully multiprocessor and 64 bit but this initial multitasking only utilises one CPU. Some further work before the multitasking utilises all the cpus. This machine has 2 CPUs namely an AMD Turion X2 but the OS will run on up to 256 CPUs which is the limit allowed by the x86 architecture.

Once the multiprocessor multitasking is fully functional I will upload a video of that as multiprocessor multitasking will look quite different from uniprocessor multitasking.

440pm: I have tried running a dozen tasks, a number launched correctly but at some point the system froze up. So I am debugging that, looks like a bug in the semaphore system.

Once there are many tasks then the complexity is severe and bugs are highly likely.

Looks like if I delay before each new task is launched there is no problem, so it seems to be a bug when tasks are launched immediately after each other. On the tower system as I write this I have all 12 tasks running without problem pre-emptively multitasking.

540pm: BUG RESOLVED! all 12 tasks now are running without problem without delayed launches. The bug was a register hidden in a macro which hadnt gotten initialised because the initialisation had been conditionally jumped. That register has now been unhidden and initialised and everything is fine.

I think I will try this on the laptop and then begin making the multitasking multiprocessor. The entire architecture is multiprocessor but there is a bit of further work before the multiprocessorness is complete.

6pm: its all fine on the laptop also, the laptop is dual cpu: AMD Turion X2.

I will take a break now and later begin completing the 64 bit multiprocessor multitasking, should take a few hours to complete as the really difficult stuff is all done.

940pm: it is proving to be more work than I thought,

============== 17th June 2007 ===============

There was a further bug, eventually I found it was a macro with a repeated argument name and the assembler hadnt detected that error. Once the arg name was changed then everything was alright.

Further in-depth testing of the subsystem appears to suggest that everything is fine now. So that completes another subproject.

Some subsystems cannot be tested out except by actual use as they cannot be used in isolation.

I will continue now with other things,

330am: the work continues now ever forwards towards multitasking. I have got several further things done already.

============== 16th June 2007 ===============

The bug I was looking for yesterday is quite a major bug, I am correcting that at the moment: quite a bit of work as it affects a lot of things.

1215am: the bug is now resolved. Have done some very thorough testing of the subsystem and the code is functioning correctly. I need to do some further testing to be really sure. Probably will do that tomorrow.

============== 15th June 2007 ===============

I have been testing out a subsystem I wrote in a recent month and it has a tricky bug, trying to locate the bug at the moment.

============== 14th June 2007 ===============

Working now on all the multitasking subprojects including the semaphores. There are some very complicated theoretical problems,

============== 13th June 2007 ===============

I have completed some architectural subphases towards multitasking, these are running fine on the pre-multitasking system. They are features which are Unix concepts, my OS is completely different from Unix but some Unix ideas such as these are definitive. Just as Xerox's concept of windowing is definitive. All OS's have windows today but each OS does windowing differently.

There could be problems with these new features once the system is multitasking so there may be bugs which will manifest later.

============== 12th June 2007 ===============

Trying out some of the new code I have an impossible bug, have spent a lot of time on it without success.

315am: the bug is resolved. Very very obscure problem,

============== 10th June 2007 ===============

The work now is getting very complicated and involves all the different subprojects of multitasking including semaphores.

3am: the work is getting increasingly complicated. Working on very exciting parts of the architecture.

============== 8th June 2007 ===============

I have completed working through the code I was looking at. That is all running correctly. I am now ready to begin on a major subphase of the project towards multitasking, this next subphase is central supervisor level architecture.

930pm: I am working now on the next subphase, very gradual progress. There are a lot of technical constraints now eg ensuring there arent conflicts between different subsystems. This is the problem where you have the code you want but cannot use it because it conflicts with the caller system. eg the caller may have alignment constraints which arent adhered to.

============== 4-5th June 2007 ===============

I am working my way through the code I did approx March-April, there are many things I have figured out since then so I am making many improvements

5th June: have found some things I forgot to initialise, those things arent referenced yet which is why they didnt lead to problems. Have been stress testing some of the code also. Mainly this work is about carefully reading the code which may or may not be correct. So it isnt the same as reading code which you know to be correct.

============== 2nd June 2007 ===============

I have completed a major early phase of the work towards multitasking. This code functions on both my machines. Most of the multitasking code doesnt function yet and hasnt even been assembled. This phase includes the recent absolute time functionality but also is a lot of other things and is about 6 weeks of work.

I will take a rest from computing and then begin on the next major phase of work.

1130pm: well I am continuing now with the next major phase of work. This in fact continues a subproject I was working on end of March beginning of April. I tried running the code I was working on then and it malfunctioned. I found the bug, it was an incorrect stack. There may be further bugs,

============== 31st May 2007 ===============

I have got a lot done on absolute time functionality. By absolute time I mean say 31st May 2007 03:55:28 or delaying by 2 seconds.

ie synchronising with the time you see on your watch. There are a lot of complicating factors. The central problem with time is that if you try to measure it, it continues moving forwards while you are thinking what to do. Furthermore while thinking an earlier delay may now have elapsed. So the problem is that time doesnt wait, it just continues on and there is a problem of catch-up!

I have basically got completed some important steps towards full functionality. Full functionality wont be there for some time.

============== 25th May 2007 ===============

I am making progress now with time, continuing with the time work I began many months ago mentioned at the end of the web page. I have completed another phase of bootstrapping time. As mentioned recently some time functionality my work was depending on doesnt seem to function on my laptop so I had to workaround that.

I now build my OS using old fashioned MSDOS scripts!

Although I criticise MS I like some of their things eg their script system is very direct. It seems to decide that a file is a script file if it is ???.bat and you can put ordinary commands in that. It also deals with variable script args.

============== 24th May 2007 ===============

Some time functionality I require doesnt function on the laptop, however other time functionality is functioning so I am creating a workaround via that.

later: running into further time problems, trying out some new time things the tower system now malfunctions. This is using legacy 1980s hardware.

============== 23rd May 2007 ===============

Work continues with integrated time delays. There seems to be problems with time and date with the laptop. I am trying to get that to function. The same code is fine on the tower system.

============== 21st - 22nd May 2007 ===============

At the moment I am working on a lot of technical matters, there is an unavoidable problem within one of the subsystems needed for semaphores and I am working around that problem at the moment. The workaround is complicated. I am working also on delay functionality, delay is actually part of the architecture and complicates the design.

============== 13th May 2007 ===============

Recently not many updates as I was away from the internet. I have got some major multitasking functionality implemented. I have only done a small amount of further work on the semaphore subproject. I got digressed into a different subproject of implementing multitasking, something which the semaphores will depend on. That itself was major work.

============== 16th April 2007 ===============

The problems now are getting really impossible. Whichever way I try to do things I reach an impossibility!

I am making gradual progress now, eg there was some code which was only ok if there was no multitasking. I could change that code (A) to be alright if there was multitasking but that depended on something initialised (1) later. I got around that by moving the initialisation earlier. But that initialisation depended on an ABI which wasnt yet initialised. I dealt with that by temporarily initialising (2) the ABI and then deinitialising it. At that point the system depends on a different ABI. With 68k you probably just need 1 ABI, but x86 is unusual and you need different ABIs. Later on some code assumed the initialisation hadnt been done and that needed changing as it now was dependent on the initialisation (1).

I have made those changes but not yet changed the code at (A). The changes at (A) need to function also before multitasking starts. That was another complicating factor. I found a way to do it which isnt yet implemented.

Such problems are very impenetrable because a different way would have led to totally different problems.

Some of the alternatives I looked at I couldnt see how to run the system with. There was an unresolvable circular dependency where one way out was to remove some features! Unfortunately those features really were necessary, eventually I found a different way.

I have tried the above changes with the existing non multitasking system and it runs correctly. If there was any error at all the system would freeze up or reset depending on its mood.

145am: I have got some of the code towards (A) implemented. I have got this debugged now for the non multitasking situation. There is quite a lot to change. Changing the code is straightforward, but I need to do this in batches in case of bugs: I make a backup before each batch and then try that out in the non multitasking case. There was a bug where the text output was freezing up because of an interaction. Trying out the code so far I can see the idea is good. I havent yet tried the code on the laptop, so I'll try that next.

330am: HAHAHA! I found there is a much better way of doing this, I can do (A) with much less coding. Luckily I made backups so I will revert SOME of the files, other changes are fine. The bug above is in code which will be kept.

17th april: the new approach mentioned above has to be done more carefully but is less coding. Today I was optimising some of the changes. One ongoing problem with the current work is that any change at all to any of it can affect everything else. eg some changes mean that a lot of the other code becomes garbage. It is very difficult to create a system which in totality is alright. Each time I read through the new work a lot of the stuff is now garbage. It is like one of those 3D puzzles where you have different irregular shapes which you have to connect up into a regular shape, if anything at all isnt right the entirety disintegrates. As you use one of the shapes you then find it obstructs another shape. Or a rubiks cube where if you move anything a lot of other unintended stuff also moves. A LOT of effort is required to move everything into place with a rubiks cube.

The other problem is that everything is so arbitrary, there are no rules and so many different ways to do things, alternatively sometimes there doesnt seem to be any way to do something.

The reason this code is so tricky is firstly that this is coding tricky hardware: totally asynchronous, secondly that the thing being implemented is very tricky: pre-emptive multitasking s/w + kernel, thirdly that this is the substratum of all software. When you read this page on a browser, the browser runs above an OS. At the centre of that OS is material comparable to what I am synthesizing here.

============== 15th April 2007 ===============

I wasted a lot of time trying out some code, it was 2 very difficult to see bugs, one was a loop where I forgot to put the jmp statement at the end of the loop, the other was that 2 variables were very similarly named and I used the wrong one in a statement. Both are like the "Paris in the the spring" optical illusion where the first "the" is at the end of a line and the second "the" at the start of the next line and you dont see there are 2 "the"s. I read through the code again and again and could not see the problem.

The multitasking project is reaching complexity meltdown, each thing I look at requires ever more work, subproject proliferation, the workload is increasing much faster than the work! One way to deal with this is to leave things out of the design. Eg some features have a time cost, this leads to project definition questions. eg is the project about speed or about features. My project is ultimately somewhere in the middle. I want speed but I also want features. I have to make some difficult decisions as to what the system will be.

A very important part of design is deciding what a system WONT do. Good design is often about what a system DOESNT do, eg an example of good design is AmigaOS not utilising fork() or Modula not using macros. Just because Unix does something doesnt mean its any use!

============== 14th April 2007 ===============

Today I found a disadvantage of the current semaphore code, I am busy working on this problem currently. It is very tricky. The idea I am trying may even be impossible, I havent determined that, if it appears impossible I can try a different idea which I think is possible but not quite as good.

============== 13th April 2007 ===============

I have made a lot of progess towards semaphores. Got some very tricky things implemented, this is the twilight zone of computer science. (twilight zone==television series here! a place where the normal rules dont apply)

I am taking a break now from the semaphores and am doing further work on the memory architecture. Ironically first attempt to upload this froze up WinUAE!

With such things there are 2 bugs which can happen: freeze ups and tasks vanishing! I have to study the code very carefully for such problems. There are so many different interactions that some wierd problems can happen.

The current memory architecture work is very interesting, this work is deep within the architecture and depends on months of work: implementing some cool features.

============== 11th April 2007 ===============

Very busy, gradual progress. Much underway. Progress good, progress slow, progress difficult.

I give here using pseudo 68k asm an illustration of semaphore problems:

simple semaphores can be done thus:

xyz:  tas.b m
      bnz xyz

exclusive_code
...

      move.b #0, m

...
m db 0

tas tests m before setting the top bit. Here a task keeps setting the top bit of m until that results in a change. bnz means the bit was already set so try again. The top bit signifies the semaphore is BUSY. instructions such as tas were invented entirely for implementing semaphores.

That means only 1 task can execute exclusive_code. However there is a problem: if a higher priority task now pre-empts the task and also tries to lock the semaphore both tasks will freeze up. The reason is that the higher priority task loops forever at xyz: and the lower priority one being of lower priority is kept from continuing to eventually free the semaphore. So the higher priority one loops forever on the semaphore and the lower priority one waits forever for the cpu. Here the semaphore is logically correct it achieves exclusion, but the design is bugged as the system freezes up. Thats an unusual problem because nothing has crashed.

Most of the time though the above is fine. Its a 1 percenter, the bug only happens 1% of the time. AmigaOS dealt with this by not using semaphores but switching off multitasking via Forbid() and Permit():

call_forbid
exclusive_code
call_permit

which was optimal for how they did things, but in general has problems eg it is insecure as a prog can freeze the OS via:

call_forbid
rpt:  jmp rpt
call_permit

One way out is the Microsoft XP idea of "program not responding". Essentially give forbid a timeout, so the OS can only freeze up temporarily. The discussion is reaching a point where truth becomes relative. An idea is good on one OS and bad on another. AmigaOS recognised that semaphores were necessary and supplied them with AmigaOS 2.0. The AmigaOS 1.0 RKM by Sassenrath says to use message ports for semaphores. That probably is efficient but eg has the problem that it requires an auxiliary task. Either way the design is becoming complex as semaphores now depend on message ports and require a protocol. Auxiliary tasks are the way for doing certain things, AFA doing semaphores you have to be careful about the auxiliary task depending on semaphores as that is what it is trying to implement.

Whichever way you go, things get complicated, especially if you want to design a good system. Even if the system is correct you can then get user level bugs.

My architecture is completely different, the semaphores will be completely integrated into the design. They co-depend on many other things. I could design the architecture differently so that semaphores arent integrated, but that has its own problem consequences.

It has taken about a year of coding before I can even think about semaphores. So it is like installing lighting in an aeroplane, you first have to make the plane! The lighting depends on the power supply, but the aeroplane control mechanisms also depend on that. You have to make sure there is enough power for the entire journey.

Once multitasking is functioning then I really have an OS, before that it is more of a precursor. Even when multitasking is implemented it will be months before it is fully functional, eg the initial multitasking cannot access hardware.

When the multitasking is functioning I will eventually upload a video of it. Same legacy graphics as the existing video but multitasking, the graphics will be 1980 but the multitasking will be 2010.

============== 9th April 2007 ===============

9pm I have completed coding the component mentioned on the 6th. The work was neverending but I have completed it now. I havent assembled it yet. The code is very complicated and bug prone, but it will be very heavily used so any bugs should soon manifest. The code has been carefully written to avoid various dependencies which could be used. Those dependencies are avoided to avoid circularity: there is a danger of design bugs where the OS freezes up because something is circularly self dependent.

The semaphore subproject is still at an early stage, so the above component is a first step of many towards multitasking.

============== 6th April 2007 ===============

I am making very gradual progress towards multitasking,

950pm: I have just completed coding one subcomponent of one component of the architecture. I havent tried compiling it yet,

later: at least I thought I had completed it, have found several complicating factors. so I am still working on that.

============== 1st April 2007 ===============

4pm: All the different subprojects of multitasking are now merging into one project. so I am now working on all the subprojects simultaneously, some things involve one topic or feature, others another. None will be complete until all are complete. All the features are being fully integrated.

Full integration means that you wont have to implement things by hacked workarounds, instead the things will already be there designed into the system. And there are no workarounds, everything is harmonious.

Anyway, returning to semaphores those wont be complete until everything else is, there is a lot of further work before anything completes.

============== 31th March 2007 ===============

The semaphore work continues, it is very stressful work. Things are gradually progressing. Its a very interesting problem, there are very complicated bugs that can happen.

tautologically I wont be able to test out the semaphores until after multitasking itself is implemented. semaphores are an integral component of my multitasking architecture: my OS cannot function without them.

============== 30th March 2007 ===============

Finding a lot of theoretical problems, some of the existing code wont cope with these so I am having to redo various things.

As I progress towards multitasking the problems get increasingly difficult.

I am working on semaphores at the moment...

semaphores are very tricky, looks like another phase or subproject...

semaphores are inextricably linked to multitasking, the 2 problems are inseperable. So the semaphores will be designed and implemented in tandem with multitasking in general. Very difficult to be sure there are no bugs with the mechanism.

============== 29th March 2007 ===============

I am working on further memory architecture work, I had an interesting crash because I forgot that x86 stacks start at the far end.

============== 28th March 2007 ===============

I am working on a very difficult component of the multitasking architecture. This is supervisor level work. This component is the beginning of a new phase towards multitasking. The component has to deal with many different problems. Also the kernel is pre-emptive which complicates things further. AmigaOS was the first pre-emptive kernel.

============== 25th March 2007 ===============

Last thing yesterday I realised there was a better way of dealing with several x86 specific memory constraints. Several different workaround mechanisms could be replaced by 1 general scheme which also allows me to deal with new constraints or remove existing constraints by changing build parameters.

I have completed implementing that and it seems to be functioning fine. The new code is much easier to maintain.

When I make extensive changes I always backup the preceding system first in case the new work runs into problems.

I am ready now to begin the next phase of work towards multitasking, this is further memory architecture work.

1am: I am currently doing some low level reconfiguring of the hardware required by the plan. Without the reconfiguring the system will not function.

later: I've been trying out the code so far, x86 is doing something different from what I thought, so I have to figure a way around that.

============== 24th March 2007 ===============

I have been trying out the code so far. This has a bug which I am working on at the moment.

1025pm: that bug is resolved, I forgot to set some field. Fine on the tower, I am about to try it on the laptop. (later: that went fine).

Before continuing I need to make some improvements to the existing code.

530am: I have made a lot of improvements to the existing memory architecture (and several bugs getting there). Some of the improvements are x86 specific and some are general. Some of the x86 specific optimisations can probably be ported to specific requirements of other cpus. (would need to be redone in C first). The code avoids hard wired assumptions. There is a lot of further work to be done on the memory architecture.

============== 20th March 2007 ===============

I am right at the centre of the OS now, centre of the multitasking. A lot of further work before the multitasking will function. This is the most difficult part of the whole project. The code is still unitasking eg the recent video is unitasking.

No graphics at all yet, just the legacy ascii graphics. If you are very observant you will see that the snapshot of the laptop has slightly different fonts from the video of the tower. The 2 mobos have implemented the same fonts slightly differently. eg the 0's are different. I have the graphics hardware under control but that code isnt integrated into the OS. So if you were hoping to see some windowing in the video, there isnt any. It hasnt even been coded yet! The graphics system will use the CPU as a GPU.

The OS so far is completely written in x86 asm. At some point I will start using C, and some of the existing code will be redone in C. But a lot of things have to be done in asm.

The initial multitasking will have many features but wont be fully featured till later. The multitasking will gradually become fully featured. The full feature set is too complex to implement in one go, it will be arrived at in phases. The later features are designed in right at the start but implemented later. To reach multitasking is itself a major bootstrap consisting of many subprojects. eg the lowest level of the memory system took approx a month to develop. The higher levels of the memory system are still being developed ongoingly.

As an example the initial multitasking wont have access to any hardware except to echo legacy text to the screen as in that video. Task level access to hardware is major work.

I see Vista is now in the shops, I'm not at all worried about Vista though I will eventually try out Vista to evaluate it. Microsoft wont wait for any competitor! Their presentation is full of smiling dancing young actors pretending to be Vista users. with oiled teeth and ants in their shoes. They certainly know how to market thats for sure.

But if you switch on your television and watch the adverts you will see that all companies hugely hype their wares with actors pretending to be customers.

============== 18th March 2007 ===============

At the top of the webpage is a photo after the OS has echoed the first sector of the HD via a 28-bit sector number DMA ATA read.

I'll try and upload a video of a subset of the code in action. I will only show a small enough subset that doesnt reveal too much of the gameplan. Currently the graphics is entirely legacy hardware 16 colour ascii 80x25 text. (IIRC it is 16 colour, something low anyhow).

You will notice the numbers are different from those mentioned on 5th March, that is because those are for the tower and these are for the laptop.

I have now made a video of my IDE DMA code in action, DOWNLOAD THE VIDEO

The video shows some HD query code then reading the first sector. After that I press some keys which appear and move the mouse + press and release buttons. The mouse coordinates are echoed and the button changes are echoed. I press the left button down, right down, left up, right up. This is for my tower system and you will see the numbers are those mentioned on 5th March.

Although the graphics is still very primitive I guarantee that the OS underway is very advanced.

Most of the work isnt visible, the visible stuff is the tip of the iceberg. Right now I am working on some really tricky code towards multitasking. This sub project gets increasingly difficult as it proceeds.

============== 15th March 2007 ===============

I am coding one of the phases towards multitasking, this code has to deal with various future features such as security, task removal, fork() and others. Security is preventing things like viruses, spyware etc.

The security architecture is entirely my own design and is not based in any way on any other system. Security is a very far reaching topic. The security design is ongoing work and consists of different phases each of which is a subproject. The initial phase I am coding now and was arrived at over recent months.

The reason Windows has hundreds of viruses and other malware is because it is a mainframe OS which was never intended for PCs. Bill Gates paid the chief programmer of VMS to reimplement it on PC's. Windows has painted itself into a corner surrounded by viruses. viruses are at the centre of the design of Windows.

My OS is not a reimplementation, the entire design is brand new and as such I avoid all the problems of all the mainstream OS's.

============== 13th March 2007 ===============

Major work is now underway working towards multitasking. This is a brand new architecture with major features eg security, crash protection, clean task removal, pre-emptive kernel, fork() (as far as is feasible), and many others. The OS design will be as good as any on the market, the 3 comparison OS's are 68k-AmigaOS, Unix and Windows. Of the competitors AmigaOS has the cleanest and most efficient design, Unix probably has the most features of these 3 and is the least usable. Windows has the most attention and is certainly the most aggressively developed. However an Amiga 1200 outdoes say XP in many ways, AmigaOS is a much more general design eg AmigaOS is the most asynchronous OS ever created even today. AmigaOS has the most advanced windowing architecture, Windows windowing has useful features but the actual architecture has many limits.

Because there are so many deep level features the work is quite severe. Some of the features will be worked on later. Remember I am attempting to outdo Unix which has stood the test of time since the 1970s. AmigaOS also has stood the test of time of 20 years. AFAIK Windows is a reimplementation of a mainframe OS called VMS, the disadvantage of that is a PC is a totally different hardware paradigm from a mainframe. Its also why Windows is so severely complicated. Unix is also really a mainframe OS thats why it has the user-group-other file protection flags. A Unix system will have say 200 users who login through terminals, 5 of those users might be a team working on some project and their shared files will be group readable. A file is group writable if anyone in the team can modify the file, the filesystem creates an exclusive write lock so that 2 people cannot write the file at the same time.

Windows 95 made the astonishing assertion that it was a man century of work my project will prove that is false.

programmers will be discouraged from using fork(), instead there will be other ways for user programs to multitask. Example problem with fork() is if a program is writing a CD-R and right in the middle of that does fork(), 2 programs are now writing the same CD-R which is clearly a problem.

you wont be able to interfere with the OS like you can on AmigaOS, AmigaOS is unique in that respect. advantage: users can customise the OS, disadvantage: so can viruses.

============== 9th March 2007 ===============

I've completed writing and debugging a very initial batch of code towards major OS functionality,

============== 6th March 2007 ===============

Doing a lot of coding now, major stuff.

It may not be clear what the recent PATA info was about: what I achieved was making the PATA code BIOS independent, ie it now doesnt use the BIOS: thats an improvement to the system. See (A) in the project summary and (B) also.

============== 5th March 2007 ===============

further to yesterday, I was going to implement 28 bit sector numbers for PATA but as I started on this I realised I must have already implemented it. Reading the code more carefully I found it was already done: I had implemented 28 bit DMA but NOT 28 bit polled code. The code I was trying yesterday was in fact polled 48 bit code. Literally 4 lines of code later and the tower 28 bit is reading sector 0 correctly. Its on the other screen right now, the last 18 bytes being:

00 00 c1 ff 07 ef ff ff 40 94 45 04 c0 11 0b 05 55 aa

If you know enough about PC's you can figure out from that some info about the partitions. eg the 5th byte along is 07 which would appear to mean that the 4th top level partition is NTFS. The 4 bytes before 55aa tell you the partition size, 050b11c0 which is about 5 x 2^24 x 2^9 bytes ie 5 x 2^33 = 40 x 2^30 = 40G, and XP says 40.35GB. which is about half of the drive. This type of interpretation is important to determine if hardware code is correct.

I know the read is correct if it ends in 55 aa as that is the signature of sector 0 on PC's.

I am continuing now with the main OS work towards major functionality. Implementing the OS features people wish for in forums!

If you dont like what I am doing please email me and say why,

============== 4th March 2007 ===============

I have been revisiting the PATA HD code. I want to make the HD code fully BIOS independent. It was only some time after I had written the code that I figured out how to remove the BIOS dependencies. I didnt do that then as there were various complicating factors.

Anyway I have enough things now under control that I can make the HD code BIOS independent. I have been working on that and have now completed that code, but there are 2 problems: the tower system is reading the first sector but the bytes dont look correct. The laptop HD initialisation doesnt directly function, I know why and am working on that right now. Once it functions I will see whether it reads the correct bytes.

As regards fork() it seems the function is not intended for the more general situations I was considering.

later: both HD problems are now explained: the tower system currently uses an 80G HD which doesnt support 48-bit sector numbers. The current code just uses 48-bit sector numbers, so the read there was a no-op. The laptop HD needed to be reconfigured, it then did read sector 0 correctly. I know if the read is correct because sector 0 on a PC HD should end in the bytes 55, aa.

I think I have already written somewhere 28-bit sector number code, looks like I'll need to get that functioning in order to be able to test out code on the tower. This isnt urgent, main thing is the 48 bit code is correct. 28-bit sectors gets you up to 2^28 * 2^9 == 2^37 ==128G bytes. Drives bigger than 128G should therefore support 48-bit.

when the laptop floppy takes ages reading, I try to music conduct the floppy drive sounds. The sound of machines is a form of music, eg musical instruments are themselves machines. People and animals are also machines, eg horse drawn carriages and police dogs.

even later: looks like I probably havent implemented 28 bit sector number code. I have been working on so many subprojects that I have lost track of exactly what I have or havent implemented. I sometimes find things I forgot I had implemented. I think at the time I wasnt so interested in laptops as 28 bit is more for laptops with 80G drives. Its on my todo list then to implement 28 bit. ironically this laptop has a 48 bit drive (120G) and the tower has a 28 bit one. That's because I decided to go for a smaller system HD for the tower so I could move my stuff between computers by recabling. OTOH I went for a big laptop drive as it is inconvenient to use external drives on a laptop. Now that I've learnt how cool laptops are I will ensure my system runs on modern laptops with 28 bit or higher drives.

The HD code more generally will require a lot of further work,

============== 2nd March 2007 ===============

I have been studying fork() to see if I should make my OS fork() compatible.

I never use fork() myself. AmigaOS's CreateTask() is a much better function. fork() is only necessary if you want to port Unix progs to your system. fork() isnt recommended.

Having fork() compatibility is a severe design constraint as you literally have to design the whole system to allow fork() to be possible. For the moment I wont decide and will just see what the consequences are.

fork() is certainly an interesting idea, it is the thing of the universe splitting into 2 paths eg the one path you bought an Amiga and the other you bought an Atari ST. However being interesting doesnt make it good programming, making an optical mouse the size of a car is interesting but not practical engineering unless Gulliver is on his way. eg if the universe can split into 2 paths that hugely increases the dimensionality of the universe which makes it more difficult to implement. interdimensional memory isnt cheap...

Note that I dont yet have multitasking, fork() is being looked at as that constrains the entire OS design. To see the severity of fork() think of UAE as a program above Unix, what happens if you put a fork() statement?

UAE should then split into 2 UAEs, but how exactly? eg what happens to the interactions with the hardware?

Ultimately the objective is to create a good system, and if fork() gets in the way of that objective it will be removed as a constraint.

Trying out some code there was a bug with fantastic consequences, I put a line of asm in the wrong place and there were fantastic colour effects, much more interesting than the usual correct code!

The colour effects are on the other screen right now,

============== 28th Feb 2007 ===============

I have got several low level hardware things done today. As I write this I have some code running on the other screen.

things are progressing very well,

The code above eventually reset the machine which was a bug, various further changes and the code seems to be alright. I have the newer code now running on the other screen. I'll finish the session by trying the same code on the laptop.

Some things are slightly different on the laptop, this is where betatesting is necessary. However it is much too early for betatesting.

============== 26th-27th Feb 2007 ===============

I've got some very initial code now functioning. The bugs mentioned below have been resolved, took a lot of work to do. I have made some improvements also to the supervisor level of the OS. A long standing inelegance has been smoothed.

This is a very initial step towards the app level of the OS.

I've also improved my work desk! I now have the tower monitor to the right of the laptop so I can I have both machines in view simultaneously: with the "OS" on the right monitor and the source code asm on the left monitor!

One unusual thing is these 2 machines use different hardware fonts, the monitor on the right has 0's with a dot in the middle whereas the left monitor has 0's with a diagonal line.

27th: I have improved the mouse code (that was on my TODO list for many months). The mouse code is not yet app level, I will work on that later. I will continue now with the app level of the OS.

The work now is very difficult, so at the moment I'm not doing any coding but am studying the problems. At some point soon I probably need to resume work on the compiler so that the further development of the OS can be done in C.

============== 22nd-26th Feb 2007 ===============

Working on very difficult OS architectural problems...

23.feb: found a very complicated harmless bug.

If you want more specific info on what I am doing and why, email me with a specific or general question,

I can give more info in an email than on the website.

24.feb: I'm doing gruntwork programming for some interesting new functionality. This is very initial work on the app level of the OS. And yes it will be a pre-emptive multitasking OS,

25.feb: there's a bug now in the debug code!

26.feb: several bugs actually. I've got some of them resolved now, involved some supervisor level coding.

============== 21st Feb 2007 ===============

I am making gradual progress on the hardware subproject. I'll get a bit more done and then resume work on the OS: the next steps with the OS are quite major things,

When I say "hardware" I actually mean software!

Note that a lot of actual hardware is itself software eg x86 is in fact software above a RISC core. Years ago someone made an interesting remark that "hardware is software".

============== 18th Feb 2007 ===============

I've just tried for the first time the OS ported to the laptop back on the tower system and it functioned fine first time. This will greatly speed up progress as I can now develop on the laptop but test the work on the tower.

I am working on the first steps of a hardware subproject.

============== 16th Feb 2007 ===============

First update for a month, in that time I have bought a cool laptop and have ported my OS project fully to the laptop. All bugs mentioned in previous updates have now been resolved: there were many bugs and some really tricky x86 asm problems.

Not only have I ported the OS to the laptop but I am working on a lot of new things on the laptop.

============== 15-16th Jan 2007 ===============

right at the end of the day I've found a function in the boot code which contains several bugs some of which directly relate to the supervisor level bug. The code looks correct but it isnt. It took some work to determine that it wasnt correct.

I'll try to correct the function tomorrow.

I am buying a laptop now so I can continue my projects when I dont have access to my tower system. I will probably try and get the code running on the laptop though that is trickier as laptops dont leave much room to manoevre.

16th jan 7pm: I am working on the problem. This code is 16 bit asm which is very fiddly. The bug happened because I was trying out new assembler features and no problem manifested at the time.

I have found now the cause of a lot of the problems.

11pm: I've corrected the function but the problem still manifests. I have to continue this tomorrow.

============== 14th Jan 2007 ===============

Now I've completed the port to 68k-AmigaOS of AFPL Ghostscript 8.54 I am restarting work on the supervisor bug mentioned below. It is an x86 specific problem. I only have a few days of time window so I will focus mainly on this bug.

============== 29th November 2006 ===============

2am: I didnt get too much done today (Tuesday) as I had various non computing things to do. I have made a small amount of further progress on the supervisor bug. I now understand generally what the problem is but it will take some work to resolve it. I wont get much done tomorrow (Wednesday) either.

============== 28th November 2006 ===============

I realised some enhancement that would improve the early compiler phases, so I decided to implement that before I forgot. The enhancement is implemented now and seems to be functioning fine.

I am continuing with the supervisor level bug. This is a very complicated bug and I need to resolve it in order to continue the OS bootstrap.

8am: I have made a certain amount of progress with the bug. Not fully there yet as there is some further inexplicable crashing.

============== 26th November 2006 ===============

The supervisor level bug I'm looking at is very tricky. I am making some progress on the problem, however it isnt resolved yet.

============== 25th November 2006 ===============

As the C pre processor subproject is complete I have moved that info to the project summary at the end of the webpage. Thats another chapter of the project complete.

I am now working on the supervisor level OS bug I was looking at on 17th October.

I will take a holiday from computing in December. I will begin on the C compiler in 2007.

============== 21st September 2006 ===============

The low level OS component is now fully debugged. All tests are running correctly. So I regard this subproject as complete. Perhaps there are undetected bugs these will be worked on as and when I find them.

I have thus completed 2 immensely powerful subsystems: the low level OS component and phase 2 of the compiler project.

I will now make various improvements to the existing OS.

============== 25th November 2006 project summary ===============

This is an updated version of the 21st September 2006 update which was an update of the 23rd July 2006 summary.

Here is a summary of major developments: the major hardware success was getting DMA PCI control of hard disks functioning. That took months of work to figure out, I can now read and write via DMA, ATA drives via 28 bit and 48 bit sector numbers. 28 bit is used for drives which havent implemented 48 bit. Drives below 128G dont need to implement 48 bit, some dont. I have now completed the second phase of my compiler project, this is the second of approx 8 phases towards a 64 bit C compiler, this second phase took 1.5 months to complete. It is one of the most difficult phases of the compiler project. I plan to create a big endian x86 option as well.

I have a very low level PS/2 mouse driver functioning, I've implemented mouse position but no mouse pointer yet. So far I've been unable to reconfigure the mouse though I have managed to initialise the mouse. I can do the reconfiguring in software as the initialisation defaults give 16 pixels per mm resolution which is 406.4dpi so its not a major problem. I have PS/2 keyboard support, though no driver yet. Any keyboard functionality I need I can implement by hacking directly eg I've implemented WaitForChar(), this polls till the key is pressed. It is better to wait by not polling, however it will be some time before I can implement that.

I have various low level time features implemented, eg code to read and set the time and date and can do timeout polls of hardware eg timeout after 3 seconds. Without time hardware you can only poll via a counter and the code may fail on a faster CPU. I have a low level DMA floppy disk driver running: I havent yet implemented proper error handling. Dealing with error handling is a gruntwork subproject. Floppy disks have various complicating factors eg if you keep reading from a disk the head gradually becomes misaligned. This means that some errors are not real errors and you need to reset the head and try again. That is something I will need to code later.

I have a lot of low level system hardware functioning and have gradually developed my own efficient low level reconfiguration of the system hardware eg mobo hardware.

(A)By understanding the low level hardware I have managed to find a way around various BIOS dependencies, eg I can now fully bootstrap ATA PCI DMA without the BIOS. Not yet fully implemented that as it requires some work but know how to. (2007.3.6: now done see (B) below)

The current bootstrap uses legacy x86 text graphics. x86 has text rendering in legacy hardware, this gives you the well known standard x86 80 x 25 text. However a modern OS cannot use that, its very useful though for the bootstrap as it allows you to work on the CPU first. I have truecolour low level graphics functioning but completely unintegrated. So far only done graphics in 16 bit, that only gives you access to a few cm at the top of the screen as the rest of the screen is beyond the memory range of 16 bit. That must be why they used text graphics hardware, its the only way to do text in 16 bit. Integrating modern graphics is one of the next major subprojects eg I will have to implement my own fonts. I will use the CPU as a GPU as that gives me full compatibility with all graphics cards.

The filesystem project has been stalling, for the moment I am working on other things. I have tidied up the existing code and the compiler project has borrowed interesting subsystems from the filesystem project especially the memory debug system. I have also generated various plans for what to do next with the filesystem. The FS project influences all the later subprojects as I invented many mechanisms for the FS which are generally applicable.

There are endless miscellaneous subprojects I've worked on, eg I wrote my own generic ELF loader in c and have designed various things to implement later. Some subprojects have to be postponed as they depend on things not implemented yet. eg the filesystem depends on a 64 bit C compiler and an ATA driver. I have now enough ATA functionality implemented to supply the required ATA driver. However I regard other problems as more urgent.

21st September: I have just now completed a major low level OS kernel component which has taken 2 months to develop. This is code that normally I would only do in C, but here it has been done entirely in asm: mainly because the C compiler wont be usable for quite some time. Probably it would have been better done in C, its just that I was impatient.

Early phases of the compiler project are complete which are not C specific.

22nd Nov 2006: C pre processor is complete. This has not been thoroughly tested. It is a fully functioning C pre processor. It doesnt yet have support for floating point numbers, otherwise it is complete. Floating point support will be straightforward but I need to study what is involved. The C pre processor has various enhancements over the standard. More on these later.

Although the work so far looks very chaotic that is just temporary, same way a building site is total chaos. The chaos is because of the high level of complexity. When I say temporary that could be many months.

Feb 2007: the OS now has been ported to my new laptop and runs on both machines. The work now is focussing on the synthesis of OS architecture gradually manufacturing a pre-emptive multitasking system.

(B)5th March 2007: The ATA PCI DMA code is now fully independent of the BIOS, see (A) above

2nd July 2007: first successful kernel level pre-emptive multitasking has been run. This is an initial version of pre-emptive multitasking, the subproject isnt complete eg there isnt any task exit implemented yet so tasks currently must never exit. The semaphore subproject is complete and fully functional.

The OS is completely 64 bit and is fully multiprocessor x86. The multiprocessor code is tested on a dual CPU AMD Turion X2 and will run on up to 256 multicpus as that is the limit of the x86 architecture.

2nd August 2007 5am: the new pre-emptive multitasking architecture is now functioning correctly. This tries wherever possible to relaunch tasks to the same cpu in order to optimise cache usage. Sometimes it is more optimal to relaunch to a different cpu: a very complicated heuristic optimisation algorithm is used. This is much more complex than the original architecture. This makes the OS super modern.

The plan now is to implement a C++ compiler instead of a C compiler.

9th April 2008: major changes of plans in the months since the above was written, in October 2007 I abandoned the C++ project as C++ is not what I want and too time consuming to implement. No point spending many months implementing functionality I never plan to use! Instead I have since then been designing my own language from scratch which does what I want and implementing the compiler for that. I have just today (9th April 2008) completed implementing the code that checks for type equality and the compiler for this new language is probably 75% complete. It is a very difficult project.

Once the compiler is complete the remainder of the OS project will be written using my own language. C was invented to implement Unix with around 1978 and here in 2008 I am inventing my own language to implement my own OS with!

My language is a completely different paradigm from C++, and will give me the functionality that the OS coding requires. The type system has comparable power to C++ templates but is geared completely differently.