https://whoosh777.com/os.html

1
2<HTML>
3	<HEAD>
4	<TITLE>My x86 Operating system project</TITLE>
5	</HEAD>
6
7<BODY bgcolor="#FFFFFF" >
8
9<p><h1>My 64 bit multiprocessor x86-native Operating System and related projects</h1>
10
11<p>email: <code>info @ whoosh777 . com </code>
12
13<p>A brand new modern fully 64 bit multiprocessor x86 native Operating system 
14that I am designing and coding from scratch.
15
16<p>The OS is written in 64 bit x86 asm and boots directly from 
17a floppy disk: insert floppy disk in PC, switch on, boot up. Hits the hardware directly
18(unhosted OS), doesnt depend on Linux or Windows. Stand-alone. 
19feb.2007: the OS now boots on my laptop as well, the complicating factor being
20that laptops dont have standard floppy drives.
21
22<p>The idea is to create an OS which is as advanced as any mainstream OS
23yet also usable + fun. dissatisfaction with existing systems!
24
25<p>I am also creating from scratch my own 64 bit C compiler to use for and on the OS. 
26But I have decided to develop my own language to develop the OS with,
27so am working on that now and will postpone further work on the C compiler till
28later. 
29
30
31<p>Eventually the project will boot from hard disk and 
32once the new language is ready I will use it to code OS components. The C compiler
33is being written entirely in C and will bootstrap from any existing C compiler on 
34any OS. But everything now will revolve around the new language and not on C.
35
36
37<p>As of 2nd July 2007 the OS is multiprocessor pre-emptive multitasking, 
38the multitasking subproject isnt yet complete.
39
40<p><img src="screen2.jpg" align="centre" width=500 height=375></p>
41<p>BLURRY SCREENSHOT: first sector of the laptop HD echoed by my OS DMA HD code
42<p>Note 55 aa which is the last 2 bytes of an x86 HD sector 0.
43
44<p><a href="video.ASF">DOWNLOAD VIDEO OF MY OS IN ACTION</a>
45
46<p><h2>The idea</h2>
47
48<p>The idea is that when the project is complete, the user will buy or 
49build their own standard x86 PC. You then buy the OS from me which 
50you then run on the machine. 
51
52<p>Developers can develop their own programs to run on the OS. They can 
53sell those programs to users or create free programs. I do not control 
54what developers do.
55
56<p>And users can use programs written by developers, they either buy them
57or the developer gives the program for free.
58
59<p>Why not use Windows, AmigaOS or Linux instead?
60
61<p>Exactly! That is the challenge, to make the system more interesting
62for developers and users. So you would use my system instead of other
63systems because it is BETTER!
64
65<p>Same reason you would switch to a car which was cheaper, faster,
66safer and more comfortable.
67
68<p>Exactly how it is better mainly wont be discussed till much later on.
69But if you contact me by email I can explain SOME of the ways it is good.
70I guarantee that when you use the system you will quit whatever system
71you currently use except for things not implemented yet. 
72How can I be so sure? well, I have used 3 of the 
73mainstream systems: Linux, AmigaOS and Windows XP. So I have a pretty
74good idea of what the competition is. Windows probably impresses users,
75but I am not a user I am completing right now an entire kernel in x86 asm which
76is completely my own design. I designed and coded the entire system.
77
78<p>Example features are Unix quality security: immunity to viruses, hackers,
79spyware. Unix quality safety: eg protection from crashes. System architecture
80as elegant and direct as AmigaOS. In many ways MORE direct than AmigaOS.
81
82<p>The actual architecture is completely new eg immunity to viruses is being done
83completely my own way and the system architecture is completely different from
84AmigaOS.
85
86<p>Unix and AmigaOS are the 2 main influences, Unix tends to be definitive in terms
87of functionality but the implementation is an enormous inextricable hack.
88And AmigaOS tends to be definitive in terms of implementation quality but has 
89problems achieving the functionality of Unix.
90Windows is also an influence on many specifics especially when they avoid
91unnecessary functionality.
92
93
94<p>The system will also be ideal for hosted OS's or emulators, hostability 
95is a design constraint.
96
97<p>I feel I can create something better than what is on offer. Microsoft are
98moving forwards unstoppably and a countersystem is urgently required.
99
100
101<p><a href="#200611251">[PROJECT SUMMARY on 25th November 2006]</a>
102
103<p><h2>Project progress</h2> 
104
105<p>In reverse chronological order:
106
107<p><a href="#20131012">12.oct.2013[ OS and language projects continue...]</a>,
108<p><a href="#20110213">13.feb.2011[ OS project survey continues, good progress ]</a>,
109<p><a href="#20110203">3.feb.2011[ EXTREMELY BUSY reviewing the OS work ]</a>,
110<p><a href="#20110127">27.jan.2011[ OS PROJECT RESTARTED! ]</a>,
111<p><a href="#20110126">26.jan.2011[ INITIAL COMPILER PROJECT IS COMPLETE! (other than testing)]</a>,
112<p><a href="#20101202">2.dec.2010[ COMPILER PROJECT IS "COMPLETE"! ]</a>,
113<p><a href="#20101123">23.nov.2010[ version 0 is built, and various bugs resolved ]</a>,
114<p><a href="#20101121">21.nov.2010[ version 0 of language is written! ]</a>,
115<p><a href="#20101002">2.oct.2010[ version -1 of language complete! ]</a>,
116<p><a href="#20100701">1.july.2010[ working on floating points ]</a>,
117<p><a href="#20100521">21.may.2010[ language almost complete, just some floating point stuff left to  do ]</a>,
118<p><a href="#20090914">14.sep.2009[ language visibility complete ]</a>,
119<p><a href="#20090902">2.sep.2009[ LAST TRICKY COMPILER CODING COMPLETE! ]</a>,
120<p><a href="#20090815">15.aug.2009[ a lot of object implementation complete ]</a>,
121<p><a href="#20090808">8.aug.2009[ major component of objects complete ]</a>,
122<p><a href="#20090729">29.july.2009[ implementing objects ]</a>,
123<p><a href="#20090708">6-8.july.2009[ initial general purpose language done, last remaining features ]</a>,
124<p><a href="#20090630">30.jun.2009[ the language is now general purpose ]</a>,
125<p><a href="#20090617">17.jun.2009[ one feature left! ]</a>,
126<p><a href="#20090602">2.jun.2009[ implementation of if-else REALLY complete! ]</a>,
127<p><a href="#20090528">28.may.2009[ implementation of if-else "complete" ]</a>,
128<p><a href="#20090521">21.may.2009[ several subphases of if-else "complete" ]</a>,
129<p><a href="#20090501">1.may.2009[ current switches complete ]</a>,
130<p><a href="#20090430">30.apr.2009[ further switch statement features complete ]</a>,
131<p><a href="#20090428">28.apr.2009[ various switch statement features complete ]</a>,
132<p><a href="#20090425">25.apr.2009[ on last subphases of implementing switch statements ]</a>,
133<p><a href="#20090125">25.jan.2009[ complex source files compiling correctly ]</a>,
134<p><a href="#20090123">23.jan.2009[ initial limited version of compiler is written ]</a>,
135<p><a href="#20090110">10.jan.2009[ holiday, work continues. ]</a>,
136<p><a href="#20081127">27.nov.2008[ excellent progress, plenty left to do ]</a>,
137<p><a href="#20081120">20.nov.2008[ compiler project last phase progressing ]</a>,
138<p><a href="#20081111">11.nov.2008[ working on last phase of compiler project ]</a>,
139<p><a href="#20081109">9.nov.2008[ completed SECOND LAST phase of compiler project! ]</a>,
140<p><a href="#20081025">25.oct.2008[ compiler phase "complete", 2 phases left ]</a>,
141<p><a href="#20081003">3.oct.2008[ new compiler phase, 2 phases left ]</a>,
142<p><a href="#20080926">26.sep.2008[ holiday, tricky compiler coding ]</a>,
143<p><a href="#20080821">

14321.aug.2008[ OS modified for compiler ]</a>,
144<p><a href="#20080819">19.aug.2008[ OS now fine on Sempron ]</a>,
145<p><a href="#20080814">14.aug.2008[ restarts OS project for compiler ]</a>,
146<p><a href="#20080806">6.aug.2008[ optimisation, OS + compiler + language, ]</a>,
147<p><a href="#20080803">3.aug.2008[ About to start on LAST difficult subproject of compiler ]</a>,
148<p><a href="#20080801">1.aug.2008[ compiler now 64 bit Linux Ubuntu and Fedora hosted, HUGE BUG RESOLVED ]</a>,
149<p><a href="#20080724">24.july.2008[ compiler now also Linux hosted, much progress ]</a>,
150<p><a href="#20080718">18.july.2008[ current code compiled, bug ]</a>,
151<p><a href="#20080715">15.july.2008[ things get very complicated ]</a>,
152<p><a href="#20080709">9.july.2008[ sizeof equivalent completed ]</a>,
153<p><a href="#20080703">3.july.2008[ restarting work ]</a>,
154<p><a href="#20080618">18.jun.2008[ sizeof equivalent: component completed ]</a>,
155<p><a href="#20080617">17.jun.2008[ sizeof equivalent ]</a>,
156<p><a href="#20080613">13.jun.2008[ much work, slow progress ]</a>,
157<p><a href="#20080611">11.jun.2008[ register usage decisions ]</a>,
158<p><a href="#20080609">9.jun.2008[ working on function calls ]</a>,
159<p><a href="#20080605">5.jun.2008[ compiler project: things get very complicated ]</a>,
160<p><a href="#20080604">4.jun.2008[ function call register usage ]</a>,
161<p><a href="#20080525">25.may.2008[ literal integer consts ]</a>,
162<p><a href="#20080524">24.may.2008[ implementing varargs and optional args ]</a>,
163<p><a href="#20080424">24.apr.2008[ changes to the type system implemented ]</a>,
164<p><a href="#20080423">23.apr.2008[ implementing changes to the type system ]</a>,
165<p><a href="#20080418">18.apr.2008[ type assignability new problems resolved ]</a>,
166<p><a href="#20080417">17.apr.2008[ type assignability new problems ]</a>,
167<p><a href="#20080416">16.apr.2008[ type assignability difficult subphase coded ]</a>,
168<p><a href="#20080411">11.apr.2008[ continuing with code generation semantics, type assignability ]</a>,
169<p><a href="#20080409">9.apr.2008[ type equality "complete" (for now) ]</a>,
170<p><a href="#20080408">8.apr.2008[ type equality some major features complete, further bugs ]</a>,
171<p><a href="#20080407">7.apr.2008[ type equality implemented ... bugs ]</a>,
172<p><a href="#20080405">5.apr.2008[ type equality: steady progress ]</a>,
173<p><a href="#20080403">3.apr.2008[ type equality very very tricky! ]</a>,
174<p><a href="#20080330">30.mar.2008[ type equality ]</a>,
175<p><a href="#20080222">22.feb.2008[ progressing towards code generation of compiler ]</a>,
176<p><a href="#20080219">19.feb.2008[ first version of major compiler component now functioning ]</a>,
177<p><a href="#20080202">2.feb.2008[ starting to make more progress, ]</a>,
178<p><a href="#20080117">17.jan.2008[ difficult language semantic design, ]</a>,
179<p><a href="#20080113">13.jan.2008[ continuing implementing type checking, ]</a>,
180<p><a href="#20080110">10.jan.2008[ holiday complete, so much to do. ]</a>,
181<p><a href="#20071203">3.dec.2007[ continuing working on type checking ]</a>,
182<p><a href="#20071118">18.nov.2007[ very difficult type coding ]</a>,
183<p><a href="#20071116">16.nov.2007[ implementing type checking ]</a>,
184<p><a href="#20071115">15.nov.2007[ plenty of work, gradual progress ]</a>,
185<p><a href="#20071111">11.nov.2007[ the work intensifies ]</a>,
186<p><a href="#20071109">9.nov.2007[ very busy implementing language semantics ]</a>,
187<p><a href="#20071108">8.nov.2007[ gradually progressing with second phase of language ]</a>,
188<p><a href="#20071107">7.nov.2007[ have started second phase of language ]</a>,
189<p><a href="#20071106">6.nov.2007[ transition phase complete and untested, bugs, changes ]</a>,
190<p><a href="#20071104">4.nov.2007[ first phase of my language complete, transition phase ]</a>,
191<p><a href="#20071103">3.nov.2007[ almost completed this first phase ]</a>,
192<p><a href="#20071031">31.oct.2007[ difficult design decisions ]</a>,
193<p><a href="#20071029">29.oct.2007[ Almost ready to start next phase of my language ]</a>,
194<p><a href="#20071027">27.oct.2007[ Progressing with my own language ]</a>,
195<p><a href="#20071026">26.oct.2007[ total change of plan? ]</a>,
196<p><a href="#20071025">25.oct.2007[ first version of current C++ phase complete but not usable yet, ]</a>,
197<p><a href="#20071024">24.oct.2007[ progressing with current C++ phase, different from Stroustrup ]</a>,
198<p><a href="#20071022">22.oct.2007[ tricky C++ ]</a>,
199<p><a href="#20071019">19.oct.2007[ C++ inital subphase done ]</a>,
200<p><a href="#20071018">18.oct.2007[ C++ inital subphase almost done ]</a>,
201<p><a href="#20071017">17.oct.2007[ busy working on C++ ]</a>,
202<p><a href="#20071016">16.oct.2007[ C++ subproject restarted. ]</a>,
203<p><a href="#20071014">14.oct.2007[ first version of C- complete ]</a>,
204<p><a href="#20071013">13.oct.2007[ C- "using" bug resolved ]</a>,
205<p><a href="#20071012">12.oct.2007[ C- "using" directive ]</a>,
206<p><a href="#20071011">11.oct.2007[ C- templates: debugging ]</a>,
207<p><a href="#20071008">08.oct.2007[ C- templates: trickiest work now done (I think) ]</a>,
208<p><a href="#20071006">06.oct.2007[ C- templates: ever more complicated. ]</a>,
209<p><a href="#20071005">05.oct.2007[ working on C- templates. ]</a>,
210<p><a href="#20070916">16.sep.2007[ C- mostly done, 1 tricky thing to do ]</a>,
211<p><a href="#20070912">12.sep.2007[ a bit of progress towards C-. ]</a>,
212<p><a href="#20070910">10.sep.2007[ work towards C- very tricky. ]</a>,
213<p><a href="#20070905">5.sep.2007[ gcc compatibility is painful! ]</a>,
214<p><a href="#20070904">4.sep.2007[ C- and preprocessor. freeze up bug. resolved. ]</a>,
215<p><a href="#20070903">3.sep.2007[ C- very deep bug ]</a>,
216<p><a href="#20070902">2.sep.2007[ many difficult problems. C- first phase initial version ]</a>,
217<p><a href="#20070821">21.aug.2007[ trickiest ]</a>,
218<p><a href="#20070820">20.aug.2007[ C- ]</a>,
219<p><a href="#20070819">19.aug.2007[ x (y) , an idea ]</a>,
220<p><a href="#20070818">18.aug.2007[ further C and C++ ambiguities ]</a>,
221<p><a href="#20070817">17.aug.2007[ continuing with the initial C++ work, ambiguities ]</a>,
222<p><a href="#20070815">15.aug.2007[ some very initial C++ done ]</a>,
223<p><a href="#20070813">13.aug.2007[ pre-processor done for now. coding C++ now. ]</a>,
224<p><a href="#20070811">11.aug.2007[ oh thank you gcc! ]</a>,
225<p><a href="#20070810">10.aug.2007[ pre-processor ]</a>,
226<p><a href="#20070809">9.aug.2007[ towards C++, pre-processor ]</a>,
227<p><a href="#20070802">2.aug.2007[ restarting compiler project, C++ ]</a>,
228<p><a href="#20070801">1.aug.2007[ WHEEEHOOOO! ]</a>,
229<p><a href="#20070731">31.july.2007[ slow progress with bugs ]</a>,
230<p><a href="#20070730">30.july.2007[ difficult multiprocessor bugs ]</a>,
231<p><a href="#20070729">29.july.2007[ much work, bugs progress ]</a>,
232<p><a href="#20070709">9.july.2007[ major improvements underway ]</a>,
233<p><a href="#20070708">8.july.2007[ multiprocessor semaphored text now good, video thereof ]</a>,
234<p><a href="#20070707">7.july.2007[ many problems, gradual progress ]</a>,
235<p><a href="#20070706">6.july.2007[ found a bug ; gruntwork ; strange + interesting problems. ]</a>,
236<p><a href="#20070705">5.july.2007[ pre-emptive multiprocessor multitasking seems ok now, video ]</a>,
237<p><a href="#20070704">4.july.2007[ pre-emptive multiprocessor multitasking debugging continues ]</a>,
238<p><a href="#20070703">3.july.2007[ very tricky work towards pre-emptive multiprocessor multitasking ]</a>,
239<p><a href="#20070702">2.july.2007[ first version of 64 bit x86 PRE-EMPTIVE MULTITASKING functioning! ]</a>,
240<p><a href="#20070617">17.jun.2007[ another subproject completed. continuing, ]</a>,
241<p><a href="#20070616">16.jun.2007[ working on major bug, resolving ]</a>,
242<p><a href="#20070615">15.jun.2007[ difficult bug in subsystem ]</a>,
243<p><a href="#20070614">14.jun.2007[ working on everything now towards multitasking ]</a>,
244<p><a href="#20070613">13.jun.2007[ some architectural subphases towards multitasking completed ]</a>,
245<p><a href="#20070612">12.jun.2007[ an impossible bug, 315am resolved ]</a>,
246<p><a href="#20070610">10.jun.2007[ working on everything now ]</a>,
247<p><a href="#20070608">8.jun.2007[ up to date, about to begin major subphase to multitasking ]</a>,
248<p><a href="#20070604">

2484-5.jun.2007[ working on the earlier code ]</a>,
249<p><a href="#20070602">2.jun.2007[ major phase completed towards multitasking. continuing from where I left off ]</a>,
250<p><a href="#20070531">31.may.2007[ progress on absolute time ]</a>,
251<p><a href="#20070525">25.may.2007[ time progress ]</a>,
252<p><a href="#20070524">24.may.2007[ laptop time workaround, further time problems ]</a>,
253<p><a href="#20070523">23.may.2007[ OS time delays, laptop time problems ]</a>,
254<p><a href="#20070521">21-22.may.2007[ a lot of technical work, delay functionality ]</a>,
255<p><a href="#20070513">13.may.2007[ much progress on multitasking components ]</a>,
256<p><a href="#20070416">16.apr.2007[ impossible problems ]</a>,
257<p><a href="#20070415">15.apr.2007[ difficult to see bugs, complexity meltdown ]</a>,
258<p><a href="#20070414">14.apr.2007[ further semaphore work ]</a>,
259<p><a href="#20070413">13.apr.2007[ a lot of progress towards semaphores ]</a>,
260<p><a href="#20070411">11.apr.2007[ very busy ]</a>,
261<p><a href="#20070409">09.apr.2007[ one component complete ]</a>,
262<p><a href="#20070406">06.apr.2007[ very gradual progress ]</a>,
263<p><a href="#20070401">01.apr.2007[ all multitasking problems combine ]</a>,
264<p><a href="#20070331">31.mar.2007[ semaphores: stressful and interesting, ]</a>,
265<p><a href="#20070330">30.mar.2007[ many theoretical problems, semaphores... ]</a>,
266<p><a href="#20070329">29.mar.2007[ memory architecture work continues ]</a>,
267<p><a href="#20070328">28.mar.2007[ very difficult multitasking component ]</a>,
268<p><a href="#20070325">25.mar.2007[ redone yesterdays memory work ]</a>,
269<p><a href="#20070324">24.mar.2007[ debugging code so far, improved memory ]</a>,
270<p><a href="#20070320">20.mar.2007[ centre of the OS, ]</a>,
271<p><a href="#20070318">18.mar.2007[ the work continues, OS photo ]</a>,
272<p><a href="#20070315">15.mar.2007[ working on an early phase towards multitasking ]</a>,
273<p><a href="#20070313">13.mar.2007[ work continues towards multitasking, ]</a>,
274<p><a href="#20070309">9.mar.2007[ a batch of OS code done, ]</a>,
275<p><a href="#20070306">6.mar.2007[ much coding, PATA independent of BIOS, ]</a>,
276<p><a href="#20070305">5.mar.2007[ 28-bit 2006 ]</a>,
277<p><a href="#20070304">4.mar.2007[ revisiting PATA code ]</a>,
278<p><a href="#20070302">2.mar.2007[ fork()?, fantastic bug! ]</a>,
279<p><a href="#20070228">28.feb.2007[ low level hardware coding, ]</a>,
280<p><a href="#20070226">26-27.feb.2007[ some very initial code functioning ]</a>,
281<p><a href="#20070222">22-25.feb.2007[ very busy on the project, bug ]</a>,
282<p><a href="#20070221">21.feb.2007[ gradual hardware progress, ]</a>,
283<p><a href="#20070218">18.feb.2007[ project fine on tower system, work continues ]</a>,
284<p><a href="#20070216">16.feb.2007[ HUGE PROGRESS, all bugs resolved, project ported to laptop ]</a>,
285<p><a href="#20070115">15-16.jan.2007[ supervisor level bug progress, ]</a>,
286<p><a href="#20070114">14.jan.2007[ restart on supervisor level bug, ]</a>,
287<p><a href="#20061129">29.nov.2006[ further progress on supervisor level bug, ]</a>,
288<p><a href="#20061128">28.nov.2006[ compiler enhancements, supervisor bug work continues,]</a>,
289<p><a href="#20061126">26.nov.2006[ some progress on supervisor bug ]</a>,
290<a href="#200611252">25.nov.2006[ C preprocessor complete. OS kernel work continues ]</a>,
291
292<a href="#200609212">21.september.2006[ low level OS component complete, new chapter of project]</a>
293
294<p><a href="#200611251">21.sep.2006[PROJECT SUMMARY]</a>
295
296<p><a href="index.html">Click for Ghostscript project</a>
297
298<p>I am creating my own OS which will run on sufficiently modern standard x86 hardware.

299Exactly how modern varies a lot. eg I will support the PS/2 mouse which is 
300quite ancient. However I wont support CHS HD sector addressing which is 
301relatively recent. This is not an encyclopaedic project, it is pragmatic.
302
303
304<p>The OS runs directly on x86 hardware and isnt hosted.
305The current work is entirely written in x86 asm.
306There is a huge amount of work to create just the beginnings of an OS.
307The logistics are very complex even to do something trivial: 
308the most trivial of actions usually occur in a context and for an OS
309project you'd need to create said context. so eg a no-op program:
310
311<pre>
312int main( int argc, char **argv ){return(0);}
313</pre>
314
315<p>needs a C compiler. It needs some scheme for storing the binary 
316on disk, not necessarily a filesystem. It needs a program loader,
317it needs a memory system to organise space for the program to run in.
318If the OS is multitasking then it needs task management. Even if you 
319use gcc for the C compiler which I dont you'll have to create an ELF loader
320which is a moderate amount of gruntwork. I have written my own ELF loader 
321but I wont use it.
322
323<p>But I am making very good progress. See the <a href="#20060723">first project update</a> for
324some of the things I've got running.
325
326<p>As a major subproject I am creating my own 64 bit C compiler to use 
327instead of gcc. This will be used later to bring my FS project to my OS project.
32818th April 2008: in fact I am now developing my own new language from
329scratch and a compiler for it. That is moving steadily towards completion,
330
331
332<p>There are 4 flagship subprojects: C compiler, FS, OS and new language + compiler.
333The FS will be cross compiled to the OS by the compiler, and the
334compiler will run above the FS in the OS. And the OS will boot eventually
335from the FS. Currently the OS boots from a floppy disk without FS.
336Once the compiler for the new language is complete future components
337of the OS will be coded using the new language.
338
339
340<p>I have made major progress on the bootstrap towards a very modern 
341brand new OS. I am designing and coding the entire system myself.
342There is no team, I am creating everything whether it be HD drivers 
343or FS or compiler or shell or graphics system. And I am designing 
344the entire architecture myself including the memory architecture, 
345the program environment, task protection, drivers, FS architecture etc.
346
347<p>Nothing is reimplemented, nothing is ported, nothing delegated,
348no teams, total attention. Completely brand new and sophisticated.
349total design: I design every aspect of every thing, this makes a big 
350difference to quality as it generates a very high level of design harmony.
351
352<p>There is an enormous amount of gruntwork before I can begin 
353on the interesting and fun things. I think I am reaching the 
354end of the most severe part of the project.
355
356<p>With the current work you insert the boot floppy disk in drive
357A: of a PC, then you switch the PC on and it boots from that.
358You dont need any existing OS and in fact you dont even need any hard disks.
359The disk then boots up. As it boots it echoes to the screen what it 
360is doing. eg in the middle of the bootstrap the current binary initialises 
361the IDE drives and echoes what the drives are: if there are none it will echo this. If you have
362just 1 HD it could be on either cable. The PS2 mouse is initialised later.
363The compiler for the new language is now at the semantic processing phase,
364eg I have already implemented type equality checking and am currently
365working on type assignability (18th April 2008).
366
367<p>At the moment I can write and run 
368programs utilising various hardware by appending the program to the 
369end of the bootstrap. I dont yet have a proper program architecture but
370can nonetheless run programs. 
371so I can write programs currently that eg read HDs and read PS/2 mouse events
372via a low level API. Basically the code I have is a rudimentary kernel 
373but not yet an OS.
374
375
376<p>A lot of the work is implementation side and technical. eg I need
377more than one ABI as x86 is basically a glob of different CPUs. Creating an 
378ABI takes some work. x86 has various complicating factors eg a near 
379call has a different stack frame from a far call. Its not like 68k where
380the stack frame is always just the 32 bit return address followed by the pushed
381arguments. With 16 bit x86 you cannot have more than 65536 bytes of stack:
382you could in theory hack beyond 65536 via some form of stack switch but 
383that would have to be done in software.
384
385<p>Contrary to popular belief little endian memory is better than big endian memory: 
386little endian is forwards compatible with
387increased field widths which big endian isnt. If you look up about endianess on the internet
388you will always be told that both schemes are equally good: WRONG! 
389eg with little endian you can do:
390
391<pre>
392void bit_set( void *x, int bit )
393{
394int *X = x ;
395
396X[ bit/32 ] |= (1 &lt &lt (bit % 32) ) ;
397}
398</pre>
399
400<p>which is mathematically clean and will set ANY bit of ANY entity, eg bit 1000 of 
401a 65536 bit entity. eg it will set 
402bit 50 of a quad or bit 18 of an int or bit 13 of a short or bit 7 of a char.
403This function is IMPOSSIBLE with big endian as big endian points to the 
404wrong end of an entity making bit position indeterminate.
405
406<p>Basically you can only do the above with little endian as it is mathematically 
407correct.
408
409<p>Little endian is better as the address of an entity is always the address of bit 0,
410which is mathematically sound. eg you can do: 
411
412<pre>
413int *x ; short *y = (short *)x ; char *z = (char *)x ;
414</pre>
415
416<p>which would be a bug with big endian. little endian has better structure than big endian.
417It can do more things and is more efficient.
418
419<p>whereas big endian crazily gives the address of a short as the address of bit 15,
420the address of an int as address of bit 31, address of a quad as address of bit 63.
421So big endian is mathematically unsound. This is one of the reasons why x86 has lasted
422so long since 1980: it is easier to extend the CPU definition and easier to extend 
423OS definitions.
424
425<p>Say you have <code>12345678</code> in memory, big endian says the address of this 
426is the address of 12. But as a word the address is the address of 56 and as a char
427the address is the address of 78. With little endian addressing the address is always
428the address of 78 regardless of whether it is a char, short or int. big endian is 
429like having the post box of a building always on the top floor and numbering the floors
430from the top downwards! eg:
431
432<pre>
433floor1
434floor2
435floor3
436....
437</pre>
438
439<p>only useful for helicopters and addressing problems if you want to make the building higher.
440
441<p>Many people believe x86 has a problem by being little endian: FALSE! 
44268k has the problem by being big endian. eg there are various bugs which only happen 
443on big endian systems. I think PPC is dual endian ie it can be configured either way but 
444it tends to be configured as big endian. I think if I ever ported my project to 
445PPC I would configure PPC to be little endian. Its some years since I looked this up 
446but IIRC PPC has a CPU config bit somewhere which makes it little endian,
447I know MIPS has such a config bit and PPC is very similar to MIPS.
448You'd have to procede carefully as any BE BIOS would now malfunction and 
449bytes may need reversing for hardware registers: comparable problems happen 
450on x86 where the BIOS will malfunction once you start reconfiguring the CPU.
451
452<p>I have made such fantastic progress with x86 that I'd be mad to switch to anything else. 
453x86 is a very Darwinian
454scene. Anyone can participate, and if you can outdo the others you will be 
455rewarded for it. If a company in this scene stops progressing another company
456will soon take its place. It means if you involve yourself with x86 
457and you make an effort success is more or less guaranteed.
458
459<p>My OS also will be presented according to Darwinian principles,
460so if you are a programmer and know your art, you'll make plenty of money.
461This is very much a programmers OS.
462
463<p><h2>==== Projects progress ====</h2>
464
465<p>My filesystem + OS projects progress will both be here. Times may be out 
466by ± ½ hour.
467
468<p><a name="20131012">============== 12th oct 2013 ===============</a>
469
470<p>More than 2 years since the last update!
471
472<p>I have made some major progress with the OS project since then, which now uses
473modern pixel graphics. But there is a lot of work to be done.
474
475<p>Although the language project is complete, I have decided to make some
476changes to the project, and these have been stalling progress.
477
478<p>In recent times I have had to spend a lot of time on non computing things
479which has also slowed down progress. But I have more time available now
480and hope to start progressing again.
481
482
483<p><a name="20110213">============== 13th Feb 2011 ===============</a>
484
485<p>The survey of the OS project continues, but I'm making good progress.
486So far the work is entirely in asm. 
487
488<p>Later on I should be able to upload some new videos of the OS 
489functioning.
490
491
492<p><a name="20110203">============== 3rd Feb 2011 ===============</a>
493
494<p>I'm extremely busy reviewing the OS work. I'm also making a lot
495of small enhancements. It will be a lot of further work before I
496can start trying to integrate the compiler with the OS.

497There are a lot of more basic problems I need to work on first.
498I'm only doing a superficial review as the totality would take
499a long time to study, eg the ATA code would be a lot of work
500to verify.
501
502<p>Anyway its MUCH MORE interesting than working on the language,
503
504<p>I had problems with the keyboard and mouse with the laptop,
505eventually I got the keyboard and mouse functioning perfectly
506with the laptop, but there is something wierd going on.
507
508
509
510<p><a name="20110127">============== 27th Jan 2011 ===============</a>
511
512<p>OS PROJECT RESTARTED!
513
514<p>I will continue testing the compiler project in parallel to this,
515but I decided to restart the OS project right away.
516
517<p>The first problem is to try to build the OS where I left off.
518
519<p>To do a full rebuild and to then try to run the OS.
520
521<p>The OS is built on Windows XP using Windows BIOS programs written on WinUAE
522and then built from the XP shell. The assembler uses Intel syntax, 
523which is slightly different from AMD syntax.
524When I last built the OS I used AMD syntax with Intel incompatible stuff
525done in macros, but at some point I redid things with Intel syntax.
526But now the assembler wont assemble because it has bugs! 1 version of
527the assembler has wrongly implemented one Intel opcode and another version
528has wrongly implemented another. Hopefully the latest version of the
529assembler will work...
530
531
532
533
534
535<p><a name="20110126">============== 26th Jan 2011 ===============</a>
536
537<p>THE INITIAL COMPILER PROJECT IS COMPLETE, other than testing the code.
538
539<p>I have implemented the auxiliary functions, and also have made
540many technical enhancements.
541
542<p>The work at 2nd December 2010 didnt have satisfactory object orientation,
543I completely redid the implementation of the object orientation as the 
544existing implementation didnt deal with various technicalities and
545was too complicated to study. 
546
547<p>The language definition of objects hasnt changed, just the implementation.
548Objects are very complicated to implement.
549
550<p>I decided to change the ABI for register args of functions,
551I have just now completed implementing the new ABI which is much better.
552
553<p>ALL intended work for the initial version of the language is now complete,
554
555<p>There will be ongoing technical enhancements but the language is now
556ready for working on the OS. I am ready to restart the OS project.
557
558
559<p><a name="20101202">============== 2nd Dec 2010 ===============</a>
560
561<p>COMPILER PROJECT IS "COMPLETE".
562
563<p>The core compiler project is "complete". I still have some
564auxiliary functions to code, but these are external to the compiler
565and more like a compiler library.
566
567<p>When I say "complete", I mean version 0 of the language,
568which is the form necessary for coding the OS.
569
570
571<p>There are of course further things that need implementing,
572but these are nonessential, and I need to do a lot of further
573testing.
574
575<p>The compiler project has thus taken 3 years, 1 month and some days!
576
577<p>It should have been taken much less time, perhaps 2 years, but
578this was due to lack of discipline and continual distractions.
579
580<p>But I am now super focussed, and in fact am working much more
581productively than in say 2007.
582
583<p>The project was starting to take forever.
584
585<p>I hope to restart the OS work REALLY soon.
586
587
588<p><a name="20101123">============== 23rd Nov 2010 ===============</a>
589
590<p>Is it really 12 days since version 0 was written!
591
592<p>I have meanwhile built the compiler, and have been testing and 
593debugging the code.
594
595<p>There were some quite subtle bugs, I had commented out something 
596in 2008, and now realized the original statement was in fact correct.
597This was to do with the implementation of function calls.
598I usually put the date and time when I comment out stuff, as I find
599it fascinating to look at the datestamps some years later.
600
601<p>There were continual bugs for some object oriented example,
602with some optimization to evade an extra
603register move. I decided to remove
604the optimisation and immediately the bugs all flew away!
605The optimisation had been a perennial nuisance.
606
607
608<p>Much more maintainable without the optimisation. The code is

609slightly less efficient but its better without the optimisation.
610
611<p>I need to test some further fundamentals, then a small amount
612of minor enhancements and the project is complete!
613
614
615
616<p><a name="20101121">============== 11th Nov 2010 ===============</a>
617
618<p>I have completed implementing version 0 of my language.
619This is the final form of the language. I havent built the code yet,
620and I will also need to test and debug this code.
621
622<p>This form of the language will be used to implement the further phases
623of my OS.
624
625<p>It has taken a bit over 3 years to complete the language, which is
626much too much time. 
627
628<p>Although there is further work, the project is kind of complete.
629
630<p>I had to do some extremely tricky implementation of certain
631object orientation features since version -1.
632
633
634<p>Certain auxiliary functions arent implemented yet, but these are
635external to the language and compiler.
636
637<p>I should very soon be able to at last restart the OS project,
638
639
640<p><a name="20101002">============== 2nd Oct 2010 ===============</a>
641
642<p>Version -1 of my language is complete. There are some library functions
643I havent yet implemented. But they are external to the compiler and language
644definition.
645
646<p>ie the language can now be used, but for some things I have to implement
647some library functions.
648
649<p>I want to make one change to the object orientation before its version 0.
650I will then test that very thoroughly, and once tested it will be version 1.
651
652<p>I hope VERY SOON to continue with the OS project.
653
654<p>I am at last progressing with the core projects.
655
656<p>It will be some work before I can use the language from the OS as the
657language uses a different ABI from the OS. I have to figure out how
658to interface the 2 ABI's.
659
660<p>The OS so far uses an ABI good for hand coding, but the language uses an
661ABI good for compiler output.
662
663<p>So the initial testing is actually manual, I read the output asm
664and verify it by reading, not by using the code. But eventually I will use the
665code and the first project is to create modern graphics for my OS.
666
667<p>The graphics will use the CPU as a GPU,
668
669
670<p><a name="20100701">============== 1st July 2010 ===============</a>
671
672<p>The ICC colour profile stuff is complete, and some of the code can be downloaded
673from the homepage. That has nothing to do with the OS and language projects,
674just mentioning it as I am the same person working on different projects not
675just those on this page. And as I work on one project I am not working on the others.
676
677
678<p>Working on the compiler again. I am working on the floating point functionality,
679which is proving to be extremely difficult. But I am progressing with this.
680
681
682<p><a name="20100521">============== 21st May 2010 ===============</a>
683
684<p>No I havent quit! But I have been doing too many different things, eg I have
685been working on my own code to print with the Samsung CLP-315 printer, and on
686coding tiff files and next I am working on ICC colour profiles, which is not related
687to the projects on this webpage but the other webpage.
688
689<p>I have made a lot of progress on the language since the last update,
690all that is left to implement is some floating point functionality. Everything else
691is complete.
692
693<p>In fact I could start using the language already, but I decided I would complete
694the floating point functionality first. Either way I need to also test the compiler
695very thoroughly.
696
697<p>I have also gotten distracted by too many other things. But I am trying to 
698get back to the core projects of the compiler and the OS.
699
700<p>I dont have the time left to make regular project updates, thus there will 
701be less updates here. But my plans are unchanged, its just that a lot of other
702plans have emerged which has led to some time mismanagement and time wastage.
703
704
705<p><a name="20090914">============== 14th Sep 2009 ===============</a>
706
707<p>I have completed implementing the language visibility. I have done a reasonable
708amount of testing of the code also and it seems fine. I will do more thorough
709testing right at the end of the project.
710
711<p>I have managed to implement ALL visibility features that I wanted to implement.
712
713
714<p><a name="20090902">============== 2nd Sep 2009 ===============</a>
715
716<p>I have completed today the LAST tricky coding of the compiler and language project.
717There is a lot left to do but its all straightforward work.
718
719<p>I have decided to complete all the core language features before stabilising the
720work.
721
722<p>Enhanced conventional objects are now implemented, but there are some
723further straightforward object features I want to implement.
724
725<p>I hope now to make major progress towards completing the project.
726But all the ideas are paying off now. 
727
728
729
730<p><a name="20090815">============== 15th August 2009 ===============</a>
731
732<p>I have completed writing, building and debugging a majur amount of

733the object code.
734
735<p>The compiler now compiles a lot of object functionality correctly,
736there were a lot of bugs initially. Its really nice seeing high level
737source code compiling correctly.
738
739
740<p>There is one last further batch of very complicated coding to do.
741I am optimistic that I can complete the implementation of objects this month.
742
743<p><a name="20090808">============== 8th August 2009 ===============</a>
744
745<p>I have completed one of the really difficult components of the
746enhanced conventional object system.
747
748<p>There are at least 2 further tricky components. At the moment I am
749working on another component.
750
751<p>I think it is feasible to complete the main implementation of
752conventionl objects this month.
753
754
755<p><a name="20090729">============== 29th July 2009 ===============</a>
756
757<p>I am working now on the LAST tricky topic which is conventional objects,
758plus various language specific extensions.
759
760<p>conventional objects are extremely tricky to implement especially
761the language specific extensions. conventional objects introduce various
762new problem phenomena.
763
764<p>In fact the conventional objects are highly unconventional!
765
766<p>They are conventional in the sense that you can do EQUIVALENTS of 
767objects of other languages, but unconventional in the way you do things.
768
769<p>The unconventional design is extremely efficient, but also
770extremely difficult to implement. It is VERY difficult to get right.
771
772
773<p>But I am gradually progressing with this.
774
775<p>I completed the main implementation of the enum mechanism a few weeks ago.
776
777
778<p><a name="20090708">============== 6-8th July 2009 ===============</a>
779
780<p>I completed superficial debugging of the initial general purpose
781language on 6th July.
782
783<p>I am now implementing the last remaining features of the initial 
784project.
785
786<p>The initial project completion will be a language with the features
787I want for developing the OS.
788
789<p>The language right now doesnt have all the features yet, eg it doesnt
790have enums and objects yet.
791
792<p>Last night I completed implementing the initial enum features, today 
793I will be working on one of the trickier features.
794
795<p>The work is now finishing off the project, but its tricky all the way
796to the end eg completing the implementation of objects is quite tricky.
797
798
799<p><a name="20090630">============== 30th June 2009 ===============</a>
800
801<p>with 30 minutes of June 2009 left I have completed enough features
802to make the language general purpose.
803
804<p>I havent checked or compiled the new code, and there are various 
805further features before the initial project is complete.
806
807
808<p><a name="20090617">============== 17th June 2009 ===============</a>
809
810<p>I have just completed a major feature set, ONE FEATURE LEFT to
811complete the initial language!
812
813<p><a name="20090602">============== 2nd June 2009 ===============</a>
814
815<p>I ran into a lot of problems with if-else, and have been working on these.
816
817<p>if-else is now written built and relatively complicated examples are 
818now compiling correctly.
819
820<p>This is a MAJOR completion point of the project.
821
822<p><a name="20090528">============== 28th May 2009 ===============</a>
823
824<p>The implementation of if-else is now written, built and simple examples
825are now compiling correctly. Further testing is necessary of more complex examples.
826
827<p>Also now implemented are various other features associated with if-else
828such as "or", "and", comparisons. The way the language does things is quite
829different from C.
830
831
832<p>Once the further testing is done this is A MAJOR completion point of
833the language and compiler.
834
835<p>The initial form of the project is virtually complete, just a few features left to implement.
836
837<p>The initial form of the language and compiler project will be sufficient to 
838develop the rest of the operating system with. But there are further features
839beyond the initial form.
840
841<p>The compiler project has taken a bit too long, the biggest error was to
842attempt to implement C++. Thankfully I shelved that and have gotten on with
843something much more interesting and useful.
844
845
846
847
848<p><a name="20090521">============== 21st May 2009 ===============</a>
849
850<p>I have got several phases of implementing if-else written and compiled,
851not tested yet.
852
853<p>2 subphases left to write.
854
855<p>Once if-else is completed then the language+compiler project is moving to
856completion.
857
858<p><a name="20090501">============== 1st May 2009 ===============</a>
859
860<p>I have completed implementing the current form of switch statements.
861
862<p>Also I have resolved the bug with the switch error messages, this 
863was a straightforward memory trashing bug:
864
865<p><pre>
866for( j = 0 ; j < i ; j++ ){ .... ; mem[ j-1 ] = .... ; .... }
867</pre>
868
869<p> which trashes <code>mem[-1]</code>,
870
871<p>once I corrected that, the bugs ALL vanished.
872
873<p>Anyway that is a MAJOR completion point, 
874
875<p>There is at least one further switch feature I plan to implement later
876for the initial completion of the language.
877
878
879
880
881
882<p><a name="20090430">============== 30th April 2009 ===============</a>
883
884<p>I have got further of the current switch statement features now complete,

885functioning correctly and efficiently.
886
887<p>There is one further major feature I need to check, and then 
888the current switch statements are complete.
889
890<p>There are some switch features I havent implemented yet, but will leave
891till later on. I think they will be unproblematic to implement.
892
893<p>There are some bugs currently with the response to certain errors,
894I will try to resolve those error response bugs. I will rebuild on Linux
895to locate those bugs.
896
897<p>on AmigaOS they result in a Geekgadgets error message requester.
898
899
900<p><a name="20090428">============== 28th April 2009 ===============</a>
901
902<p>various major switch features are now fully implemented.
903
904<p>I managed to successfully compile some switch statements of the language
905to asm today, and the output asm was correct: took some debug work to get correct
906output. But I managed to do all the debug on AmigaOS without needing to use Linux.
907The Linux build is necessary for trickier debug, I will test the switch statements
908on Linux later as Linux is particularly good at locating bugs.
909
910<p>That is major progress, that various switch statements are now complete.
911
912<p>I will test out other features later today.
913
914
915<p><a name="20090425">============== 25th April 2009 ===============</a>
916
917<p>4 months since the last update! I have been extremely busy working on the language.
918
919<p>I am working on the last subphases of implementing switch statements for the language.
920
921<p>Progress should start accelerating.
922
923
924<p><a name="20090125">============== 25th Jan 2009 ===============</a>
925
926<p>There was a bit of work to build the compiler. Then on simple
927examples I located a straightforward bug where register restore
928was in fact saving registers. just a typographical error.
929
930<p>The initial limited version of the compiler is now compiling
931simple source files correctly to 64 bit x86 asm. I am about to now try out more
932complex examples.
933
934<p>Once this has stabilised this is a major completion point of the project.
935All the remaining work is much easier. There is still a lot to do, but
936progress now should be very fast.
937
938<p>11pm: more complex source files are compiling correctly eg 
939expressions such as f( f( a, a ) / f( b, b) , f( a, b) * f( b, a ) )
940and f( f( f( a, a ), f( b, b ) ) , f( f( b, a ) , f( a, b ) ) )
941
942
943<p><a name="20090123">============== 23rd Jan 2009 ===============</a>
944
945<p>I have just completed writing the initial limited version of the compiler.
946As said in the previous update I would have completed it in December had
947I not taken a complete holiday from computing.
948
949<p>Not yet compiled or tested. Once it has stabilised I will then begin
950complete the other features of the language.
951
952<p><a name="20090110">============== 10th Jan 2009 ===============</a>
953
954<p>I was working towards the initial limited version of the language till
955the middle of December and took a holiday from programming till now.
956With that programming I made major progress towards the initial limited
957version of the language. The compiler already outputs 64 bit x86 asm.
958I think I could have got the initial version functioning within December
959but decided to take a holiday from programming and spend the time with
960my relatives instead.
961
962
963<p>The asm output already deals with eg register function arguments and 
964implementing local variables via registers. It deals with
965nested function calls eg f( g( x, y ), h( z, t ) ) where evaluating
966an argument can trash the registers for the earlier args.
967
968<p>The asm output isnt yet usable as there are some further things
969to implement eg saving registers at the start of a function and
970restoring them at the end.
971
972<p>As soon as the asm output is usable then the initial limited version
973of the language is complete. If I can complete that by 25th January
974then I would have completed it in December had I not taken a holiday!
975
976
977
978<p><a name="20081127">============== 27th Nov 2008 ===============</a>
979
980<p>I am making excellent progress with the last phase of the compiler project.
981But there is a lot left to do. I have to keep moving back the timeline
982for this!
983
984<p>The work is quite tricky but I am progressing, and dealing with
985many long standing problems.
986
987<p>The aim now is to complete the initial limited form of the compiler
988by the end of December.
989 
990<p>At the moment I am implementing the stack memory usage, and have
991been working on this since Tuesday. It is quite a complex problem 
992eg dealing with var args.
993
994<p>The work is very interesting now
995
996
997<p><a name="20081120">============== 20th Nov 2008 ===============</a>
998
999<p>Progress continues on the last phase of the compiler. Various things
1000are now complete and ready to be tried out.
1001
1002<p>There is problem after problem, but I am making progress towards
1003the initial limited form of the compiler.
1004
1005<p>On 9th Nov I said I would have the initial limited form of the
1006language implemented in a few days, it is proving to be a lot longer
1007than that! more like a few weeks.
1008
1009<p>There is now already quite a bit of x86 asm output.
1010
1011<p>Progress now with the compiler project will greatly speed up.
1012But the huge amount of things still to be done mean it could be a 
1013few months before the first true version of the language is
1014functioning.
1015
1016<p>The work now is very interesting but also difficult, many of the
1017problems are how to deal with extremal situations. The language
1018is very different from C,
1019
1020
1021<p>Probably I can have an initial form of the compiler functioning
1022by the end of this month.
1023
1024
1025
1026
1027<p><a name="20081111">============== 11th Nov 2008 ===============</a>
1028
1029<p>I am working on the last phase of the compiler project,
1030where the binary is constructed. This is proving more complicated
1031than I suggested in the previous update and will take longer than
1032envisaged.
1033
1034
1035<p>There are endless complicating factors, but I am working on these
1036and making gradual progress.
1037
1038<p>The aim now is to get the limited form of the language functioning
1039within 2008.
1040
1041<p>The difficulties relate to various language features,
1042interesting new features which are difficult to implement.
1043If I do away with such features it will be easier to implement,
1044but I need to implement them to make the project worthwhile.
1045
1046<p>This last phase is where the entire project converges,
1047there are some incoherencies between the phases where
1048one phase conflicts with another. I am trying to resolve these.
1049
1050
1051
1052
1053
1054
1055<p><a name="20081109">============== 9th Nov 2008 ===============</a>
1056
1057<p>I have "completed" another phase of the compiler project.
1058I havent compiled it yet, I will get the code to compile next but wont try 
1059it out till the next phase is complete.
1060
1061<p>The next phase is the LAST phase of the compiler-language project
1062and is relatively straightforward.
1063
1064<p>However all the latter phases will need further work, but the
1065current work is enough to get a limited form of the language and compiler
1066functioning. This initial limited form of the program wont be
1067acceptable for programmers,
1068
1069
1070<p>I will then do further work on the latter phases building up to
1071the first true version of the language and compiler which WILL be
1072acceptable for programmers.
1073
1074<p>Thus in a few days I HOPE to have the initial limited form 
1075of the project complete. But it is likely to be some weeks 
1076before the initial TRUE version of the language is ready.
1077
1078<p>I will see if I can get the initial TRUE version complete this year,
1079but that is a challenge!
1080
1081
1082<p><a name="20081025">============== 25th October 2008 ===============</a>
1083
1084<p>I have "completed" the current phase of the compiler.
1085
1086<p>It is compiled + tested, but I cannot test it thoroughly till
1087the next 2 phases are completed. Linux debug is not detecting
1088any problems.
1089
1090<p>I am about to start the second last phase of the compiler.
1091
1092<p>Once all the phases are "complete", there is further work with all
1093the latter phases before the compiler is the first prototype.
1094
1095<p>I say "complete" because its not truly complete, however
1096in terms of difficulty it is complete!
1097
1098
1099
1100
1101<p><a name="20081003">============== 3rd October 2008 ===============</a>
1102
1103<p>I am already working now on the next phase of the compiler.
1104
1105<p>2 phases left and the compiler will start compiling.
1106
1107<p>There will be further work before the initial project is complete.
1108
1109<p>If I hadnt wasted so much time on C and C++ the compiler project would
1110already be complete.
1111
1112<p>I am confident I can complete the initial version of the compiler
1113this year.
1114
1115
1116<p><a name="20080926">============== 26th September 2008 ===============</a>
1117
1118<p>I've been on holiday recently so not too much done. Right now I've restarted
1119work on the compiler.
1120
1121<p>I've completed some further tricky work relating to function calls, eg
1122things like <code>f( g( a, b) , h( c ) * i( j( d ) + k( e ) ) )</code>
1123
1124<p>The work was towards the compilation of such expressions. The arguments are typically

1125registers, and I am trying to compile such things efficiently. Here if we set up
1126the one argument in a register the other argument will typically trash the register.
1127
1128
1129<p>Right now I am beginning work on the next phase of compilation. This is 
1130very very complicated. I am trying to figure out a plan for the work.
1131I am making gradual progress.
1132
1133
1134
1135
1136<p><a name="20080821">============== 21th August 2008 ===============</a>
1137
1138<p>I have completed some modifications of the OS to make it compatible
1139with the compiler. I can now continue the compiler project. 
1140The forthcoming compiler output will be usable now within the OS 
1141but it will require stubs also.
1142
1143<p>The OS so far is ENTIRELY written in asm and uses a completely different
1144ABI from the compiler. In fact the OS itself needs several ABIs as 
1145some things just have to be done differently from other things.
1146
1147<p>Stubs will be used to interface between mechanisms, trying to have
1148the same ABI for everything will be too complicated.
1149
1150<p>Writing the OS entirely in asm was a good idea as I now have a thorough
1151understanding of x86 which I can use for implementing the compiler.
1152
1153<p>Some of the asm will be gradually migrated to my own language.
1154
1155
1156<p><a name="20080819">============== 19th August 2008 ===============</a>
1157
1158<p>After many days of effort I have the OS now functioning fine on both
1159the uniprocessor Sempron and the dual processor Turion X2. both by AMD.
1160
1161<p>The bug was that PC's can disable bit 20 of addresses!
1162
1163<p>That means when you access an address Addr, the h/w clears bit 20
1164before reading/writing the address.
1165
1166<p>But the MMU is accessing Addr. An OS needs to re-enable bit 20.
1167
1168<p>Once I re-enabled bit 20 everything is now fine.
1169
1170<p>The OS project and compiler project are now almost ready to be merged.
1171
1172
1173
1174
1175<p><a name="20080814">============== 14th August 2008 ===============</a>
1176
1177<p>I havent done any work with the OS for literally a year, if you look
1178at the update summaries at the top.
1179
1180<p>I decided to rebuild the OS, I had forgotten even the build procedure.
1181
1182<p>Eventually I got the build functioning, it is an interactive build,
1183as the build proceeds I have to modify the source each time: workaround
1184of limits of the assembler.
1185everything fine with the dual core AMD. However the uniprocessor AMD was crashing.
1186
1187<p>After some days of work I located the problem, reloading the MMU
1188table was crashing the Sempron but NOT crashing the Turion X2.
1189
1190<p>The new MMU table had identical entries to the original,
1191I verified that and it was correctly aligned. If I reloaded the original
1192table no crash. Didnt make sense,
1193but it was about 3MB into memory. PC's begin with just 1MB of memory,
1194the initial MMU table will always be in the first 1MB. Perhaps
1195NOONE has tested the Sempron with a MMU table outside the first 1MB!
1196
1197<p>I carefully arranged for the new MMU table to be within the first 1MB,
1198and no more crashes. Looks like its a CPU bug with the Sempron.
1199Thats the problem with severely complicated CPUs such as x86 that
1200it becomes impossible to really thoroughly test the CPU.
1201
1202<p>I could get around the problem by copying new MMU tables to existing
1203ones but that will be very slow. Instead for the obsolete Sempron
1204I am currently limiting the number of MMU tables to 16 which I can
1205fit in the first 1MB. That will allow me to test code on the Sempron,
1206but my OS will be meant for machines after the release of Vista.
1207
1208<p>No more crashes with this change, the Turion X2 dual core functions
1209fine just like in the video I made at the time, 
1210but the Sempron tower isnt quite right, it doesnt seem to ever start
1211echoing the 111[ 0 ] things. Probably a software bug,
1212I will debug that later. For the moment I just need the OS functioning
1213enough to verify various things I need for the compiler.
1214
1215<p>The compiler projects have taken about 1 year, looks like about 26th October
1216I changed plan and began on my own language: I wasted about 3 months on C++.
1217All that code is still there and I will probably continue the C side eventually.
1218No point at all continuing C++, and C will mainly be for bootstrap reasons
1219as the whole idea is to move away from 1978 C,Unix,C++ lineage.
1220
1221<p>Right now the language + compiler project meets the OS project.
1222No idea if I can complete within 2008 but progress should HUGELY speed up 
1223now as I essentially have most of the really tricky foundation subprojects
1224completed. If I dont complete within 2008 I should make GINORMOUS progress
1225during 2009. Reasonably confident I can complete the language + compiler
1226within 2008 and probably make major initial further progress on the OS.
1227
1228<p>According to my notes I had it functioning on the uniprocessor system,
1229yet now it doesnt. But I think I also was working on different
1230versions of the OS, possibly the version I was focussing on was different
1231and by coincidence the MMU tables were in the first 1MB. Various things
1232didnt make sense this time round, and my notes were vague which version
1233I had been working on! Also the debug output is now much less, possibly
1234that has led to a synchronisation bug emerging with the tower.
1235
1236
1237<p><a name="20080806">============== 6th August 2008 ===============</a>
1238
1239<p>I am working now on the compiler optimisation. I am going just for
1240moderately lightweight but effective optimisation. This is quite involved
1241but very interesting.
1242
1243<p>The code output will be the last subphase of the optimisation,
1244
1245<p>I am also designing integration of the language, compiler and the OS.
1246This is to allow the OS to utilise language and compiler features and 
1247for the language and compiler to utilise OS features.
1248
1249<p>Even now there are some difficult design problems that I havent 
1250resolved. 
1251
1252
1253
1254<p><a name="20080803">============== 3rd August 2008 ===============</a>
1255
1256<p>I am ready now to begin work on the last tricky subproject of the compiler.
1257
1258<p>

1258AFAICT all other subtopics not yet done arent too bad. There is a lot left
1259to be done but other than the next topic it is all downhill now.
1260
1261<p>Thus the compiler project is moving now to completion. No idea if I can
1262get the OS done within 2008 but I am sure I can get the compiler completed
1263well within 2008.
1264
1265
1266<p>Porting the compiler to Linux has hugely speeded up development.
1267I still do the main coding on WinUAE, but debug is entirely done via Linux.
1268
1269
1270
1271
1272<p><a name="20080801">============== 1st August 2008 ===============</a>
1273
1274<p>After many days of effort I have now got 64 bit Linux installed, both
1275Ubuntu 8.04.1 and Fedora 9.
1276
1277<p>The cross compiler for my language is now ported to 64 bit Linux.
1278
1279<p>A bug manifested JUST on 64 bit Linux not on 32 bit. After a lot of debug 
1280I found the bug which is in some code from many weeks ago.
1281
1282<p>It took a lot of work with gdb to locate it, the bug was that I
1283convert a list into an array, by first counting how many items to a 
1284variable count. Then I allocate the array. Then I rescan the list
1285to fill the array. HOWEVER I forgot to reinitialise count!
1286
1287<p>With 64 bit the trashing is much greater as pointers are twice as big.
1288
1289<p>reinitialising the count resolves the bug, and now C's memory allocation
1290functions fine also. ie the calloc bug mentioned on 24th July seems resolved,
1291and it was the above bug.
1292
1293<p>64 bit Linux is quite impressive, 
1294
1295<p>my own OS project is something different.
1296
1297
1298<p><a name="20080724">============== 24th July 2008 ===============</a>
1299
1300<p>The recent bug was so tricky I decided my only chance was to port the
1301build to Linux and debug on Linux.
1302
1303<p>I hadnt used Linux for a long time. Eventually I got Linux functioning.
1304(it took maybe a day)
1305
1306
1307<p>I began porting the build to Linux. I began getting the source compiling.
1308And then a huge amount of compile errors: 2 files, unportable.c and unportable.h.
1309
1310<p>I had put all the AmigaOS dependencies in these 2 files. It was major work
1311to "port" these 2 files. In fact I couldnt port them because they rely
1312heavily on dos.library things which CANNOT be ported. I had to redesign the
1313code to workaround things. The new code in fact was a lot simpler but more
1314primitive.
1315
1316<p>There were a few minor dependencies outside those 2 files, but those
1317were straightforward to redo.
1318
1319
1320<p>Eventually I got the code functioning. Using gdb I soon located various
1321bugs that were never detected on AmigaOS, eg it found a bug in some
1322code from some years ago. But one bug was elusive.
1323I concluded that it was a gcc bug with calloc(). When I use my own memory
1324system no bug on Linux. When I use calloc() or malloc() the same code crashes
1325both on AmigaOS and Linux. Both are probably using the same bugged source code for
1326calloc.
1327
1328<p>When I use calloc but alloc 4 extra bytes each time no crash. That means
1329writing to the last 4 bytes is trashing something else which it shouldnt.
1330According to gdb the bug happens within int_malloc() but there are no
1331debug symbols for int_malloc.
1332
1333<p>My own memory system checks for memory trashing in the next 4 bytes 
1334and further and there isnt any trashing. Thus it looks like calloc() 
1335is allocating incorrectly (very rarely), probably an alignment bug at the end of
1336a batch of memory.
1337
1338<p>I cannot prove it is a bug in the gcc memory system, but it looks so.
1339
1340<p>Using my own memory system I then have continued without problem,
1341locating various further bugs.
1342
1343<p>I now write the code on WinUAE as the AmigaOS default topaz fonts are
1344THE best fonts for editing. Linux and Windows fonts are all too big or
1345too small. The topaz fonts are just right.
1346
1347<p>I then try the code on AmigaOS, deal with any bugs which are detected.
1348And then reboot to Linux and try gdb.
1349
1350<p>I have completed implementing + debugging one of the most difficult
1351subtopics of the project. Progress now should speed up now.
1352
1353<p>And the code now all builds and runs from Linux. The output isnt
1354meant for Linux but can be done for Linux. There are NO OS or hardware
1355dependencies at all so far with the compiler. I can make it output
1356to ANY OS or hardware.
1357
1358<p>The compiler now is fully portable, to port to another OS
1359I just need to port the build script which is straightforward to port
1360as the only host dependencies are gcc and rm. NO GNU dependencies at all
1361(other than gcc). I dont use "make" or "sed" or "awk" etc.
1362(the build depends on delete, compile and link).
1363
1364
1365
1366
1367<p><a name="20080718">============== 18th July 2008 ===============</a>
1368
1369<p>The code so far is now compiled. Trying this out there is a delayed
1370effect bug which I am trying to locate.
1371
1372<p>After running the compiler the system crashes if I try certain shell
1373commands. Looks like some memory has got trashed.
1374
1375
1376
1377<p><a name="20080715">============== 15th July 2008 ===============</a>
1378
1379<p>Currently I am doing a study of the work so far. The compiler work is
1380getting very complicated. The work is going way beyond the planned timeline!
1381
1382<p>A lot of the really tricky things are now dealt with. But there are still
1383plenty of difficult problems left.

1384
1385<p><a name="20080709">============== 9th July 2008 ===============</a>
1386
1387<p>I have at last completed implementing the equivalent of sizeof.
1388sizeof is straightforward for most languages, but for my language 
1389it is very tricky.
1390
1391<p>At sizeof there is a major conflict of various language features. Very complicated
1392resolving the conflicts satisfactorily. Most of the conflicts have been
1393resolved via very careful changes to the language interpretation.
1394
1395<p>ie no change to the language but a changed vantage point. its a bit like taking
1396a home computer and saying: same computer but now its a server instead of a home computer.
1397
1398<p>The machine is unchanged but we change how we view the machine.
1399
1400<p>Right at the end I realised there is a dependency on the build C compiler being 64 bit.
1401I will probably change that later so that a 32 bit C compiler can be used.
1402The language itself is fully 64 bit, but there is the problem that the 
1403build compiler could be 32 bit: building a 64 bit compiler with a 32 bit compiler!
1404
1405<p>The sizeof code is written and compiled but not tested.
1406
1407
1408<p><a name="20080703">============== 3rd July 2008 ===============</a>
1409
1410<p>Not done any further work on the projects until today since the last update,
1411have just restarted work. Was working on some non programming projects!
1412
1413<p>It took me about an hour just to figure out what I had been doing with
1414the language project when I stopped, as things are very involved.
1415
1416<p>reading through the work I realised various complicating factors,
1417I have managed to deal with them satisfactorily via very carefully chosen 
1418language interpretation rules. ie all the code remains unchanged but there
1419are some rules of the form: you CANNOT do this but you CAN do that!
1420
1421<p>this relates to things where the binary will be too slow or complicated.
1422
1423<p>anyway the language project is now restarted,
1424
1425
1426<p><a name="20080618">============== 18th June 2008 ===============</a>
1427
1428<p>115am: I have completed one component of implementing type sizes.
1429
1430<p>I probably need to study it a few more times. but I will continue
1431with the other components first.
1432
1433<p>I always used to think that type sizes were straightforward! 
1434For something like C they are.
1435However my language is geared quite differently from C and C++.
1436
1437<p>The problem isnt the sizes themselves but of precise interpretation.
1438an implementation of anything is absolutely precise. But the thing
1439being implemented usually has an element of vagueness. If you arent
1440careful the vagueness may be impossible to make precise without 
1441running into various problems such as space inefficiency, speed inefficiency,
1442complicatedness or more technical problems.
1443
1444<p>The language isnt just a language but a way of doing things and a mindset.
1445Very difficult to create a new way of doing things and a new mindset!
1446
1447
1448<p><a name="20080617">============== 17th June 2008 ===============</a>
1449
1450<p>I am now working on the equivalent of sizeof, determining the sizes of types.
1451
1452<p>For a language like C sizeof isnt too bad, but for my language the problem
1453is trickier because of various features and constraints.
1454
1455<p>Essentially there are various conflicts between the different features and
1456constraints. In order to resolve these conflicts I have had to make various changes,
1457eg I had a set of 3 options for some type feature. I spent many hours on the most
1458difficult option and couldnt see how to implement it subject to the constraints.
1459The second most difficult option was also very difficult and I eventually 
1460found a satisfactory way to implement it. The last option I realised could
1461be expressed as a special case of the second option.
1462
1463<p>To deal with all this I replaced all 3 options by just the second option,
1464effectively removing the most difficult option. The second option achieves
1465most of the things I wanted from the most difficult option and is nice.
1466The special case option is now changed from an expression to an interpretation
1467which is more lightweight to understand and implement.
1468
1469<p>I have basically dealt with various points of confusion, and the language
1470is much improved as a result. Most of the improvements are based on disallowing
1471certain things. Deciding what to allow/disallow is quite tricky. 
1472It is generally true that you can judge a language not by
1473its features but by what it disallows!
1474
1475<p>its not what you can do but what you cannot do! structured programming is
1476all about "you can no longer do this". because people have found that the
1477extra liberty leads to too many problems.
1478
1479
1480<p>sizeof for AmigaOS C is actually different from sizeof for gcc.
1481C doesnt actually specify sizes fully. This makes it problematic
1482to use gcc for AmigaOS. Had C specified sizes there wouldnt be 
1483this problem!
1484
1485
1486<p>Anyway I am still working on type sizes.
1487
1488<p><a name="20080613">============== 13th June 2008 ===============</a>
1489
1490<p>I am gradually progressing with the compiler. I noticed some logical
1491problem with the implementation so far, but after maybe an hour of careful study I realised
1492there wasnt a problem! The code was so complicated and circular that it took a lot of
1493work just to determine whether the problem was dealt with.
1494
1495<p>There are a lot of different interdependent problems now, and the 
1496work tends to be on groups of problems. I am moving towards completion
1497of the current group of problems that I selected to work on now.
1498
1499<p>I have completed the really tricky problems of the group, the 
1500remaining problems of this group are downhill!
1501
1502<p>Most of the difficult work is the new features of the language.
1503
1504<p>The language will be great to use, but it is hugely difficult to implement.
1505
1506<p>An expression such as <code>f( x + g( y ) )</code> is easy to use,
1507but it is months of work to implement! One of course implements 
1508that in generality, ie when you implement that you also implement
1509<code>h( i( a, b, c ) / i( u, v ) )</code> where eg i has varargs etc.
1510
1511<p>And I DONT have that FULLY implemented, but have some of the 
1512most difficult parts of the problem implemented. eg to implement
1513that you need to implement the type system which itself is major work
1514otherwise you wont have type checking!
1515
1516<p>In a way that wont be fully implemented until the entire project is complete!
1517
1518<p>(eg to implement the call you also need to implement the called function <code>f</code>
1519and to implement that you need to implement more or less everything.)
1520
1521
1522<p><a name="20080611">============== 11th June 2008 ===============</a>
1523
1524<p>I have made decisions now on register usage for compiling functions.
1525
1526<p>The decisions are in fact quite involved and designed around the
1527constraints of x86. There isnt any right or wrong decision, and
1528the decisions I have made are based on my own opinions about
1529register usage. 
1530
1531<p>With this type of problem all you can go by are opinions,
1532
1533<p>Its a bit like asking whats the best house you can make using
1534100000 quid?
1535
1536<p>For one person the best house could be the most efficient house
1537to maintain, for another person it could be the most functional house:
1538do you want an expensive to maintain functional house?
1539A smaller house means you could use higher quality materials eg 
1540smaller but higher quality windows! You could also go for the
1541house which is quickest to build.
1542There isnt a right or wrong answer, but in practice you make a 

1543compromise decision: reasonably efficient reasonably functional.
1544
1545
1546<p>What can I reveal? well I will reveal 2 things: scratch registers
1547will NEVER be used for function args and that a and d are 2 of the
1548scratch registers. But the full set of decisions is quite complicated
1549and took about a day of study to arrive at.
1550
1551<p>scratch registers not used for function args is entirely based on opinion,
1552and is part of a bigger plan. Perhaps it is ok to have scratch registers
1553as function args with a different better plan!
1554The plan is based around a series of unprovable but reasonable assumptions.
1555
1556<p>(I define a scratch register to be one which can be trashed by function calls,
1557advantage: time isnt wasted on save-restore, disadvantage: they get trashed
1558by calls! )
1559
1560<p>what is certain is that this decision is nicer to work with,
1561but then using stack args only is even nicer to work with but slow:
1562and it frees up lots of registers.
1563
1564
1565<p>Its basically an exclusivity principle, exclusivity seems to be good,
1566except that x86 doesnt have enough registers for clean exclusivity.
1567
1568<p>The plan I have looks like it will make good use of x86's registers 
1569in practical situations. 
1570
1571<p>68k-AmigaOS in fact allowed scratch registers as function args,
1572but that was done by optimising per function the arg registers:
1573advantage: faster, disadvantage: source and binary and compiler become
1574circularly dependent! use a different compiler and a different
1575choice will be made.
1576
1577<p>It is superoptimal in terms of speed but I think only practical
1578for hand coded asm. And complicates compilers as you have to communicate
1579the choices for each function, namely the AmigaOS fd files.
1580
1581<p>Basically hand optimised asm will always outdo compilers as 
1582human thought is without boundary whereas a compiler will always
1583be oblivious of things obvious to most programmers.
1584
1585
1586<p><a name="20080609">============== 9th June 2008 ===============</a>
1587
1588<p>I am working on function calls, one problem is deciding on register usage.
1589
1590<p>But before the compiler will implement the call it needs to first 
1591check that the arguments agree with the prototype. That is a problem
1592of correctness, with a compiler one always has to check that 
1593things are correct before processing the things. And there are many
1594levels of correctness. Things correct at one level can have errors
1595at a higher level.
1596
1597<p>Anyway I have been working on checking the correctness of call args today,
1598(in total it is several weeks of work) I think I have that under control now 
1599(ie implemented). There are many complicating factors
1600including various things specific to this language. eg I have 
1601something comparable to C++'s template functions that makes 
1602correctness much more difficult.
1603
1604<p>Now that is out of the way I can continue working towards the register usage
1605conventions. For x86 I think registers a and d have to be scratch as 
1606they are the destination registers for all multiplication and division.
1607a and d are exclusive at the hardware level. x86 multiplies the value
1608in a by the operand and stores the answer at double precision in
1609d and a, the upper bits in d. eg for 32 bit multiply the upper 32 bits
1610of the 64 bit answer are in edx.
1611
1612<p>Thats a decision! a and d will be scratch, but should they be used
1613for function args? I have to study that further.
1614
1615<p><a name="20080605">============== 5th June 2008 ===============</a>
1616
1617<p>I have some of function call register usage implemented mentioned yesterday.
1618But many things not done yet.
1619
1620<p>I am working on various other things as well currently, and am working
1621on other register usage problems. I am working towards a modest amount of optimisation,
1622you can spend 10 years on compiler optimisation as it is a very deep subject.
1623
1624<p>That is why I only intend to implement a modest amount of optimisation,
1625the register usage problems I am looking at relate to optimisation.
1626The general idea is that if the code does things just with registers 
1627it should be faster. However it is a black art as to how to do that,
1628the register usage of function calls mentioned yesterday is one part of
1629the problem. The problem is you could soon run out of registers and also
1630non scratch registers need to be saved at the start + restored at the end.
1631
1632
1633<p>My compiler is for 64 bit x86, but with PPC the problem is much nicer
1634as they have so many registers, approx 32. Example not necessarily good
1635decision with PPC: have eg 5 exclusively scratch registers, have 8 registers 
1636exclusively for function args, that still leaves you with about 19 registers.
1637
1638<p>that makes the compiler much cleaner. but again you have to decide
1639how many exclusive registers, eg you could have 4 or 6 or other scratch registers,
1640
1641<p>But with x86 or 68k because there are few registers you cannot really

1642use exclusive registers. You could have one or two exclusive registers
1643eg 68k-AmigaOS uses a6 exclusively for library bases, which is a 
1644system level register optimisation. Some 68k-AmigaOS compilers use 
1645IIRC a4 as a base register for 16 bit offset addressing.
1646
1647<p>should you use exclusive registers? how many?
1648
1649<p>these are difficult questions and there is no right or wrong answer:
1650it depends on the problem.
1651
1652<p>68k-AmigaOS went for a0,a1,d0,d1 as scratch registers but not exclusively
1653scratch eg d0 could be an argument (eg SetPointer()), a scratch register and the return
1654value of a function.
1655
1656<p>that is non exclusivity, allowing multiple uses of the same register.
1657note that while d0 is an argument you cannot use it as a scratch arg,
1658you would need to move the arg to another register to free d0 up for
1659scratch use. That is where the implementation starts to get complicated.
1660with PPC you could orthogonalise the uses.
1661
1662<p>its like everything else, when you have plenty of space you can 
1663be more careless eg disk space, ram space, register space.
1664
1665<p><a name="20080604">============== 4th June 2008 ===============</a>
1666
1667<p>At the moment I am working on function call register usage:
1668
1669<p>eg scratch registers.
1670
1671<p>how many scratch registers?
1672
1673<p>should scratch registers be used as args?
1674
1675<p>which args should be which registers?
1676
1677<p>how to deal with varargs?
1678
1679<p>it isnt clear what decisions to make. something like PPC has a huge amount
1680of registers which makes it an easier problem but x86 has much fewer registers
1681which makes it much more difficult.
1682
1683<p>this is an implementation problem, it isnt part of the language definition.
1684
1685
1686
1687<p><a name="20080525">============== 25th May 2008 ===============</a>
1688
1689<p>I think I have completed the semantic processing of function args,
1690this is much trickier than say for C.
1691
1692<p>Currently I am working on the semantic processing of literal integer consts
1693eg 12345, these are more problematic than you might think...
1694
1695<p>eg C regards these as ints, but are they signed or unsigned ints?
1696
1697<p>consider eg 0xffffffff, as a 32 bit int that is -1, but as a 64 bit int
1698that is +(2^32-1), a different number with a different sign!
1699
1700<p>Another problem is for flags, if you have some 64 bit flags and 32 bit ints
1701then (1 &lt &lt 31) could be wrongly interpreted as 0xffffffff80000000 
1702via sign extension. 
1703
1704<p>There are other problems as well, with C you can get around some problems
1705via eg 0xffffffffL, but what if you use a C compiler where long = 64 bits?
1706
1707<p>I am trying to find my own way of dealing with these and other problems.
1708
1709<p><a name="20080524">============== 24th May 2008 ===============</a>
1710
1711<p>I have been designing and implementing function arg features such as  
1712varargs and optional args.
1713
1714<p>This has proven to be quite a difficult problem, but I think I have a good
1715design now. It is a different paradigm from the mechanisms used by C and Modula.
1716
1717<p>The design constraints of my language are quite different from C which 
1718makes the problem quite different from C. C's function args are more constrained
1719which makes the problem much more difficult for C.
1720
1721<p>That is why C's varargs are quite tricky, as their mechanism has to work
1722around the language constraints.
1723
1724<p><a name="20080424">============== 24th April 2008 ===============</a>
1725
1726<p>The changes to the type system are now implemented and functioning.
1727
1728<p>It needs more intense testing, sometime I will try and create a 
1729test suite and script.
1730
1731
1732
1733<p><a name="20080423">============== 23th April 2008 ===============</a>
1734
1735<p>Working on the semantic processing I gradually realised that one set 
1736of ideas of the type system had a subtle deficiency.
1737It is a meta level design problem. 
1738
1739<p>I have now got a replacement design which does what I want,
1740and am now implementing the replacement idea.
1741
1742<p>The replacement is in fact a lot simpler and completely different
1743from the original idea.
1744
1745
1746
1747
1748<p><a name="20080418">============== 18th April 2008 ===============</a>
1749
1750<p>The further problems mentioned yesterday with the type assignability 
1751I think are now resolved.
1752
1753<p>It was a very complicated recursive problem to do with an unusual 
1754feature of the type system.
1755
1756<p>The difficult subphase mentioned on the 16th I think now is complete.
1757
1758<p>I find that the code for dealing with types is very difficult to 
1759get right, but once you get it right then its ok.
1760
1761<p>The work now is to complete the code for type assignability,
1762
1763<p>Right now things have been progressing very slowly, this is because
1764of very difficult theoretical phenomena.
1765
1766<p>Actually using the language will be straightforward with some
1767fantastic features. But implementing that is near impossible.
1768
1769
1770
1771<p><a name="20080417">============== 17th April 2008 ===============</a>
1772
1773<p>Thinking about the type assignability 
1774I realised a problem with the current code. Some complicated 
1775assignability was in fact unassignable.
1776
1777<p>I think I have that problem resolved now. 
1778
1779<p>Meanwhile I have found further problems which I need to study.
1780
1781
1782
1783<p><a name="20080416">============== 16th April 2008 ===============</a>
1784
1785<p>I have got the most difficult subphase of type assignability coded.
1786Type assignability for my language is a very complicated problem. Further work
1787before I can try the code out.
1788
1789<p>The system has some features which are VERY difficult to implement,
1790
1791<p>I knew right from the start of the project that type equality and assignability
1792would be problematic.
1793
1794
1795
1796
1797<p><a name="20080411">============== 11th April 2008 ===============</a>
1798
1799<p>I am continuing now on the central semantics of the compiler,
1800which  is the semantics of code generation. This work is still at the 
1801early stages.
1802
1803<p>I earlier completed the initial semantics of local variables,
1804labels, gotos, and some language specific things.
1805
1806<p>an example of such semantics is that you can only goto a label which
1807is defined AND you can only goto outwards eg using C notation:
1808
1809<p><pre>
1810{
1811goto x ;
1812   {
1813   x:
1814   ...
1815   }
1816}
1817</pre>
1818
1819<p>:this is a semantic error as the label isnt visible to the goto.
1820But gcc in fact accepts this, my language rejects this. Thus C uses a 
1821different definition of visibility. My language is
1822more structured than C. I cannot see any circumstances where you would
1823need such a goto. even C wont allow you to jump to a label in a DIFFERENT
1824function!
1825
1826<p><pre>
1827void f(void)
1828{
1829goto x ;
1830}
1831
1832void g(void)
1833{
1834x: ;
1835}
1836</pre>
1837
1838
1839<p>345pm: I reached the point where I was to implement some feature,
1840but have decided there is a different feature which probably is a better
1841way to do things. I have just completed implementing that alternative
1842which is something I have been thinking about for some months.
1843
1844<p>I could implement both features but in the interests of efficiency
1845I think I wont implement the first feature. Both features address the
1846same problem but the first feature is a more complex constraint on 
1847the language definition.
1848
1849<p>if I discard the first feature it will free up the language definition
1850and simplify the implementation. The latter feature is already implemented
1851and running correctly.
1852
1853<p>11pm: semantic processing continues, very complicated problems,
1854but interesting also. I am starting working on the code for type assignability.
1855This is the code to determine if 2 types are assignable eg with C:
1856
1857<p><pre>
1858
1859int x ; char y ;
1860
1861x = y ;
1862
1863</pre>
1864
1865<p>with the above int is assignable to char. If the user does an assignment
1866the compiler has to determine if it is valid. Type assignability is another

1867central component.
1868
1869
1870<p><a name="20080409">============== 9th April 2008 ===============</a>
1871
1872<p>the type equality subproject is "complete" for now. The main functions
1873and features are all functioning correctly. I am sure there are some further bugs 
1874and problems but I have run out of motivation to test this any further!
1875I havent tested all features as that is very time consuming but have
1876tested the really tricky ones and resolved various bugs.
1877
1878<p>Now I will continue with the other semantic processing, all the work
1879now is tricky but I think the language + compiler project is 75% complete.
1880
1881<p>I will deal with any further type equality problems as and when they
1882arise, and have a further testing session later on in time.
1883
1884<p>I think I need to create a compiler testing script which tries out 
1885different examples to make sure everything is functioning correctly.
1886Earlier in the project there were relatively few things to test 
1887but now there are an increasing amount of things to test.
1888I will work on such a script later.
1889
1890
1891
1892<p><a name="20080408">============== 8th April 2008 ===============</a>
1893
1894<p>Some major features of the type equality code are now functioning correctly
1895and comparing tricky type constructs correctly.
1896
1897<p>Not all the major features are functioning yet, I am trying to resolve a bug
1898currently with one major feature. With this bug the code freezes up in an infinite
1899loop with some example input. It should only loop a few times but instead loops
1900forever.
1901
1902<p>Anyway progress is very good,
1903
1904
1905<p><a name="20080407">============== 7th April 2008 ===============</a>
1906
1907<p>type equality is now implemented and compiled but not debugged.
1908
1909<p>There is a bug with the first example I tried! Looks like there will
1910be some work to debug the code.
1911
1912<p>7pm: that bug is now resolved after quite a bit of work. The input example
1913was fairly straightforward, I am sure there will be further bugs.
1914
1915<p>I am taking a break now before continuing to test the program.
1916
1917
1918<p><a name="20080405">============== 5th April 2008 ===============</a>
1919
1920<p>I am starting to make good progress with implementing type equality.
1921
1922<p>But there is a lot of further work to do.
1923
1924<p>If you email me I can send you a binary of the cross compiler
1925once type equality is implemented. The binary I will send will run
1926on 68k-AmigaOS. That way you can prove to yourself that this
1927project is for real.
1928
1929
1930<p><a name="20080403">============== 3rd April 2008 ===============</a>
1931
1932<p>The work continues implementing checking for equality of types.
1933
1934<p>This is one of the most difficult problems I have looked at,
1935its because of the very general nature of types. The problems depend
1936on the definition of the type system, change the definition a bit 
1937and the problems also change.
1938
1939<p>The problems are very high level and very specific.
1940
1941<p>The main problem is that if you try to test for equality of recursive
1942types that there are multiple dangers of infinite recursion.
1943The danger is that the code never completes. Checking for the type 
1944equality is fine, its just that the code is recursive and it is 
1945difficult to guarantee that the checking ends.
1946
1947<p>Its a bit like the following code which never completes:
1948<p><pre>int factorial( int x ){ return( factorial( x + 1 ) / (x + 1) ) ; }
1949</pre>
1950
1951<p>:this code is correct but never completes!
1952
1953<p>Ordinary recursive types which you find in C arent so bad eg:
1954
1955<p><pre>
1956struct a { struct b *b ; struct c *c ; } ;
1957struct b { struct a *a ; struct c *c ; } ;
1958struct c { struct a *a ; struct b *b ; } ;
1959struct d { struct a *a ; struct b *b ; } ;
1960</pre>
1961
1962<p>Proving correctness I completed earlier, the next problem is
1963proving equality. gcc regards c and d as different, whereas old C
1964regarded them as the same. gcc's definition is better as old C's
1965definition is more likely to lead to bugs.
1966
1967<p>The major problems begin when you go beyond the C scheme...
1968
1969<p>You have to wait to see how I do that, but you can see 
1970an example of going beyond C if you look at C++'s templates.
1971I dont implement templates but I implement my own answer
1972to C++'s templates. My scheme isnt templates at all,
1973but is comparable.
1974
1975<p><a name="20080330">============== 30th March 2008 ===============</a>
1976
1977<p>I was away on holiday for a bit. On returning I had too many real world
1978things to do but now I am working on the language again.
1979
1980<p>Right now I am implementing checking type equality. This is necessary
1981eg to determine if a function prototype agrees with the function.
1982Even with type correctness implemented this is very tricky to do 
1983for my language. The trickiest thing is recursive types where a set of 
1984types are defined in terms of each other.
1985
1986<p>I am progressing now with this, the implementation is very involved.
1987
1988
1989
1990<p><a name="20080222">============== 22nd Feb 2008 ===============</a>
1991
1992<p>I am progressing now towards code generation of the compiler.
1993There is a lot of work before any code gets generated.
1994
1995<p>I have already completed implementing the initial semantic processing of 
1996local variables and labels. The compiler now determines correctness of local variables
1997and labels. I have also done some initial processing of
1998some new language features.
1999
2000<p>I am now working on the initial steps of processing language statements.
2001
2002<p><a name="20080219">============== 19th Feb 2008 ===============</a>
2003
2004<p>I have the first version of a major component of the language type
2005system implemented and functioning correctly. I have been working 
2006towards this since mid November 2007. This is the most difficult
2007part of the type system.
2008
2009<p>

2009Progress is starting to accelerate. There have been virtually no
2010updates as the work has been so severe.
2011
2012<p>This work contains a huge number of innovations, a totally 
2013different emphasis from C. But C is the yardstick to judge the
2014system by.
2015
2016<p>There are a lot of things yet to implement. But it has taken
2017me since mid November to get something that functions.
2018
2019<p>The first attempt to run the code had plenty of bugs but
2020I have gradually been resolving them.
2021
2022<p>There should be more progress updates now as progress should
2023speed up.
2024
2025
2026
2027
2028
2029<p><a name="20080202">============== 2nd Feb 2008 ===============</a>
2030
2031<p>I am starting to make more progress now, recently I made nearly no
2032progress with the language.
2033
2034<p><a name="20080117">============== 17th Jan 2008 ===============</a>
2035
2036<p>At the moment I am working on some very difficult design decisions
2037about the language semantics before I can proceed with the type checking code.
2038This work isnt coding but making decisions, the language will do this
2039the language wont do that. The best decisions tend to be about what
2040the language wont do. But such decisions need to have a good basis.
2041
2042<p>What I like about C is that there are plenty of things C 
2043doesnt do, yet you can do more or less anything with C.
2044For instance old C didnt have const, yet they implemented Unix
2045and C compilers with old C!
2046
2047<p>(My own language also doesnt have const)
2048
2049<p>Clever language features are often burdensome.
2050
2051
2052<p><a name="20080113">============== 13th Jan 2008 ===============</a>
2053
2054<p>I am continuing implementing the type checking. At the moment I am
2055going through the code so far. A lot left to do.
2056
2057<p><a name="20080110">============== 10th Jan 2008 ===============</a>
2058
2059<p>I have just completed a holiday from my computing projects. Have just restarted
2060the work, a lot to do. I have spent a lot of time deciding on one language
2061feature. It is something which C++ deals with but not C. After a lot of 
2062thinking I have decided to exclude the feature from my language.
2063The initial phases of the feature have already been implemented but 
2064I have decided to discontinue the feature!
2065
2066<p>feature exclusion is one of the most important parts of language design,
2067the power of the modula languages is the features they exclude.
2068The features are excluded because they create more problems than they 
2069resolve, although it can be very difficult to decide on this.
2070
2071<p><a name="20071203">============== 3rd December 2007 ===============</a>
2072
2073<p>continuing working on the type checking. Very complicated,
2074
2075
2076<p><a name="20071118">============== 18th November 2007 ===============</a>
2077
2078<p>working on some very difficult code with the type system of the language.
2079
2080<p><a name="20071116">============== 16th November 2007 ===============</a>
2081
2082<p>I am continuing implementing the type checking,
2083
2084<p><a name="20071115">============== 15th November 2007 ===============</a>
2085
2086<p>I have got plenty of coding done and the progress is gradual on 
2087the second phase of the compiler for my own language.
2088
2089<p>I have completed the very low level semantic processing,
2090and am now looking at higher level semantics.
2091
2092<p>Right now I am implementing the type checking. The design of the 
2093language removes a lot of the work that some languages require
2094without any reduction in power.
2095
2096<p><a name="20071111">============== 11th November 2007 ===============</a>
2097
2098<p>I am gradually moving to the trickier parts of the semantic processing.
2099There are conflicts between various of the design constraints,
2100eg there are conflicts between control, usability and readability.
2101I have had to do some further work with the language definition.
2102
2103
2104<p>If the language has too much control it also becomes more unusable.
2105Also you could increase usability but at the cost of readability:
2106where its not a problem writing code but tricky to read said written code.
2107If you work on readability you can lose control.
2108
2109<p>I wanted to increase some of the control, it took a lot of work
2110to avoid unusability and unreadability. Its like sometimes you can 
2111buy something which has lots of features but is totally unusable,
2112
2113<p>I am not attempting to outdo other languages but to create a language
2114which is good in its own way. Relative to other languages
2115there are more of some things and less of others. I think good design
2116is about recurring themes. That is economy of definition. 
2117At the same time I dont follow any absolute design principle. 
2118That is why I talk of design conflicts, in the real world
2119quality often conflicts with price. If you take any idea too far
2120you can run into opposing problems.
2121
2122<p>I am also looking at the compiler from the POV of my OS design,
2123creating features which go with the OS.
2124
2125<p><a name="20071109">============== 9th November 2007 ===============</a>
2126
2127<p>Very busy now implementing the semantics of the language.
2128
2129<p><a name="20071108">============== 8th November 2007 ===============</a>
2130
2131<p>I am making gradual progress with the second phase of my language.
2132The coding at the moment is the first subphase which is the low level
2133initialisation of the phase. The second subphase is the semantic processing
2134of source files, eg type checking and visibility control.
2135
2136<p>830pm: the beginnings of the second phase are in place. Trying this
2137out on an example source file in the language it gave an unexpected 
2138error message. I found that was something I forgot in the first phase.
2139On correcting that it found a number of bugs in the example.
2140
2141<p>I have the very beginnings of some semantic processing begun.
2142Languages in general tend to be very convoluted to implement.
2143
2144
2145
2146
2147<p><a name="20071107">============== 7th November 2007 ===============</a>
2148
2149<p>I have decided to begin now the second phase of the language project.
2150Some obscure things with the transition phase are undecided. But it doesnt
2151matter too much as long as I work just on the decided things.
2152
2153<p>The decided things are enough for developing my OS with, 
2154
2155<p>930pm: I have started now on the second phase. The initial work is 
2156gruntwork coding. The earlier compiler subprojects deal with various
2157things which will speed up development but it takes some work to 
2158figure out how to use them.
2159
2160
2161<p><a name="20071106">============== 6th November 2007 ===============</a>
2162
2163<p>The transition phase of the language project is complete. 
2164(transition phase between the first and second phases). I have just begun testing it.
2165This is the foundation of the compiler for the language.
2166
2167<p>I will then begin the next phase of the language which is a lot of work.
2168
2169<p>This project is very highly meta, there are many planes of abstraction
2170some of which are severely complicated.
2171
2172<p>The work so far is CPU independent I can use this for any CPU at all
2173eg 68k, PPC or x86. But I will be looking just at x86.
2174
2175<p>630pm: I have found a few bugs so far, things I forgot. I am working 
2176on one at the moment.
2177
2178<p>9pm: I am making a few changes as well to the language definition.
2179
2180
2181
2182
2183<p><a name="20071104">============== 4th November 2007 ===============</a>
2184
2185<p>I have completed the first phase of my language. There is now 
2186gruntwork coding before I have some code I can run. This is just an 
2187initial phase of the compiler. There are many phases of work before
2188the compiler will be ready to use.
2189
2190<p>The speed of development is because of the compiler projects I was
2191working on many months ago!
2192
2193<p>Its like if you design a lamp around a standard light bulb and standard
2194electric supply you dont need to waste time designing a light bulb.

2195Many different lamps can be done according to those constraints.
2196
2197<p>But you can go one step further by designing a NEW light bulb 
2198for use in many different NEW lamps. If you design the bulb well
2199then the many lamps compatible with it may outdo the lamps compatible
2200with the standard bulbs of today.
2201
2202<p>So here you DO waste time designing a light bulb, but that perhaps
2203makes lamp design easier so you save time each time you design a new
2204lamp for this new bulb. The idea is to not just design a light bulb
2205for a future lamp but to design it for many different future lamps.
2206And if you design the bulb not just to make the lamps more usable
2207but to make the lamps more implemable then future lamp design will
2208be much quicker.
2209
2210<p>1am: The work now is a transition phase, this is mainly complicated
2211connecting up. I have in fact just completed the low level part of this,
2212next there is higher level gruntwork.
2213
2214<p>When this transition phase is complete then things start to get 
2215very tricky.
2216
2217
2218
2219<p><a name="20071103">============== 3rd November 2007 ===============</a>
2220
2221<p>Almost completed this current phase. Even by removing a lot of unnecessary
2222things the complexity is almost out of control.
2223
2224<p>If you try to make a language too powerful it starts to become unusably complicated.
2225The reason C and AmigaOS are so popular is they are very usable. I think 
2226usability is very important.
2227
2228<p>At the same time the system needs to be practical. C and AmigaOS both 
2229are very practical. I think the reason C and AmigaOS are so good is they
2230were both created under time pressure. AmigaOS involved huge amounts
2231of hardware and OS innovation. When you are under time pressure you
2232tend to make better decisions.
2233
2234<p>It is very difficult to make decisions between usability, practicality
2235and other constraints. I have made a lot of language innovations
2236and have resolved many problems that I have encountered when programming.
2237Things which until now I couldnt see a way to resolve. You will get to 
2238see these innovations eventually.
2239
2240<p>One of the tricky things with languages is ambiguities, you try a new
2241feature but find it conflicts with an existing feature. It can be 
2242very difficult or impossible to get around some ambiguities. An example
2243ambiguity with C is:
2244
2245<p><pre>x = y+++z ; </pre>
2246
2247<p>That can either be <code>x = y + (++z) ; <code> OR <code>x = (y++)+z ; </code> 
2248OR <code>x = y + ( + ( +z ) ) ;</code>
2249Which is it? The answer is that C regards consecutive +'s as being ++,
2250so it is the 2nd interpretation. However if you put an extra space:
2251
2252<p><pre>
2253x = y+ ++z ;
2254</pre>
2255
2256<p>then it is <code>x = y + (++z) ; </code>
2257
2258<p>And with 2 spaces:
2259<p><pre>
2260x = y + + + z ;
2261</pre>
2262
2263<p>it is now <code>x = y + ( + ( +z) ) ;</code>
2264
2265<p>So spaces in C can change the meaning.
2266
2267
2268<p><a name="20071031">============== 31th October 2007 ===============</a>
2269
2270<p>Trying to complete off this first phase AFA reasonable. It involves
2271very difficult design decisions.
2272
2273<p>The language is highly notational like C, but using completely different
2274paradigms. Each potential feature has advantages and disadvantages,
2275I think the most important thing is to achieve design harmony.
2276
2277<p>I need to be really sure of the decisions, because eventually I wont
2278be able to change them. There are still things I am not sure about.
2279
2280<p>I am designing-in the language functionality my OS requires,
2281I am also resolving many problems that I have observed over the years.
2282
2283
2284<p><a name="20071029">============== 29th October 2007 ===============</a>
2285
2286<p>Although various things arent decided yet, I
2287am almost ready to begin the next phase of my language.
2288The trickiest things I will return to later.
2289
2290<p>I am making full use of the compiler projects I was working on some
2291months ago, so this can be regarded as a direct continuation of those.
2292When I began on C++ I thought that would be a direct continuation,
2293nope!
2294
2295<p>I am doing a lot of things differently from other languages,
2296some things better some things worse.
2297
2298<p>Why should some things be done worse?
2299
2300<p>

2300design efficiency, if the advantages of a feature are marginal
2301then I may omit the feature. Especially if the feature complicates
2302use and or implementation.
2303
2304<p>eg for the moment at least there is no "const" attribute, that is 
2305because it complicates use too much.
2306
2307<p>Basically it is a 100 times less work to do const optimisations
2308in software than to utilise the "const" attribute. If you know something
2309will be const then cache the value to a local variable, but only do 
2310this in the few places you need speed.
2311
2312<p>Also I dont want too many features so the language is easy to learn.
2313
2314<p>If you look at say ANSI C they remove features in order to keep
2315use and implementation under control. eg:
2316
2317<p><pre>
2318int f( struct a { int b ; } *c ) ;   // (A)
2319</pre>
2320
2321<p>is disallowed in ANSI C, you arent allowed to define types in function
2322args.
2323
2324<p>Instead you just do:
2325<p><pre>
2326
2327struct a { int b ; } ;
2328
2329int f( struct a * c ) ;
2330
2331// (B)
2332
2333</pre>
2334
2335<p>Although (A) looks clever, if you look at (B) its a LOT clearer.
2336Implementing (A) isnt a problem but it just complicates the compiler
2337because for each argument of each function there are many options:
2338
2339<p>the arg type may or may not be defined. eg <code>int f( struct b * c ) ; </code>
2340<p>the arg type may or may not be named. eg <code>int f(struct {int b ; } * c );</code>
2341<p>there may or may not be an argname. eg <code>int f(int);</code>
2342<p>there may or may not be an arg type eg <code>int f(x);</code>
2343
2344<p>If each compiler feature has many options it will take 4 x as long 
2345to learn the language and 4 x as long to implement it. So instead of 
2346taking 3 months it takes 1 year! instead of taking 1 week to learn 
2347it takes 1 month.
2348
2349<p>The above is an ANSI C example, which I agree with. ANSI C and ANSI C++
2350disallow different things! you can write a program accepted by GNU C 
2351and rejected by GNU C++ and vice versa. eg ANSI C++ disallows <code>int f(x);</code>
2352From this it is clear that language design is subjective.
2353
2354<p>Anyway I am making my own subjective decisions.
2355
2356<p>I am creating a lot of new ideas as well, in fact some new ideas have already
2357been removed for not being good enough! Some ideas are impossible to decide on,
2358
2359<p>I like old C, that was an authentic language. I think when Dennis Ritchie 
2360invented old C it wasnt meant for general use but was just a practical 
2361idea for implementing Unix. My situation is similar, I need to manufacture a language
2362in order to implement my OS. I mustnt spend too long on it. Old C and AmigaOS 
2363are similar phenomena. Both were practical methodologies with tight time 
2364constraints.
2365
2366<p>My own time constraint is to try and get most of my projects completed
2367within 2008. That is why I switched from C++ to my own language as C++ is
2368too time costly. It is like in an exam, you are answering the questions 
2369but eventually there is just 10 minutes left on the clock and you realise
2370you have to cut across a lot of things. Just a sentence where you want
2371a paragraph etc.
2372
2373<p>The original plan was to use C, and to implement C++, that plan was
2374succeeding but I was starting to see how long it would take: TOO LONG.
2375And I could see that going via my own language would drastically improve
2376the timeline. BINGO!
2377
2378<p>I think in computing the people who get to the top are the people
2379with political abilities. I want to change that and get to the top 
2380via computing abilities. I want to succeed by creating something which 
2381is good without cheating my way to the top. 
2382
2383
2384<p><a name="20071027">============== 27th October 2007 ===============</a>
2385
2386<p>I am making rapid progress working on my own language,
2387
2388<p>I will complete off the C++ work so far sometime soon, I decided
2389to go directly to working on my own language.
2390
2391<p>When the current C++ work is complete I will shelve that project
2392and will continue the C subset at some point. It is very tempting to
2393work on C++ but looking at the future timeline it will just delay
2394my OS project too much. So far I have had 2 projects which I realised

2395were futile, one was ELF and the other was Java. Both of which CAN 
2396be continued but I see no point. ELF is only necessary if you go 
2397via gcc, so once I decided to do my own C compiler ELF became 
2398unnecessary. Java was an error, I thought I was implementing Javascript,
2399when someone pointed out Java != Javascript, I quit that project
2400immediately, also I really dont like the design of Java.
2401
2402<p>I am resolving all the endless design problems of C and C++ in my
2403own language. In a few seconds I can avoid a week of coding!
2404The entire language will have an orthogonal syntax.
2405
2406<p>That is the modern approach to languages. An orthogonal syntax is 
2407one where you can process the entire source file without interpreting
2408any symbols. You then only interpret symbols in later phases.
2409To see that C's syntax isnt orthogonal:
2410
2411<p><pre>
2412x = (y)&(z) ;
2413</pre>
2414
2415<p>Is the & a binary bitwise & OR is it the unary address operator?
2416We can only know by interpreting the symbol y, if y is a type then
2417the & is the address operator, otherwise & is binary bitwise and.
2418So we cannot know just from the syntax, we need to understand the 
2419program to know.
2420
2421
2422<p>The problem with a nonorthogonal syntax is it is very complicated to 
2423both interpret AND process the syntax. I achieved that via C-, which you
2424can even try out if you email me. C- essentially orthogonalises the
2425syntax by figuring its way around such nonorthogonalities.
2426If you look at the project updates you
2427will see I have been working towards C and C++ since August 2007, ie
24283 months. ALL THAT IS UNNECESSARY FOR A WELL DESIGNED LANGUAGE!
2429eg its all unnecessary AFAIK for the Modula languages, and I think
2430unnecessary for Basic. (I dont know that for sure but think it is)
2431
2432<p>Now that work towards C and C++ wasnt a waste of time as I will
2433continue that work towards C and COULD implement C++ also anyway!
2434But I can see that it is too inefficient to do that now.
2435
2436<p>More importantly that work towards C++ has given me very deep insights
2437into the flaws of C++'s design which I will use to design my own language.
2438
2439<p>The biggest design flaw of all is the nonorthogonality of the syntax,
2440but there are plenty of other flaws. Instead of complaining about them
2441better to implement my criticisms.
2442
2443<p>Historically speaking I think the idea of orthogonal syntax was 
2444AFTER C. C was such a powerful language that people were able to 
2445write cleverer programs, they discovered ideas better than those
2446used by C. eg Modula type of languages are usually written in C!
2447
2448<p>One of the things I will be doing is removing features,
2449eg C++ allows variables to be declared anywhere eg:
2450
2451<p><pre>
2452void f(void)
2453{
2454int x = 1 ;
2455
2456x++ ;
2457
2458int y = 2 ;
2459}
2460</pre>
2461
2462<p>is rejected by GNU C but accepted by GNU C++. The problem with 
2463this idea is it makes it more difficult to see whether all allocated
2464things are freed. If all variables are at the start of a compound
2465construct then you only need to look there:
2466
2467<p><pre>
2468{
2469// variable declarations
2470
2471// code
2472
2473// variable freeing.
2474}
2475</pre>
2476
2477<p>Basically this is more structured than what C++ allows, it is 

2478much easier to check for correctness. Possibly 
2479C++ does this to deal with const inits which cannot be done till later.
2480But I am thinking of doing away with the const declaration as it 
2481slows down development too much: the disadvantages outweigh the advantages.
2482const certainly has advantages but those arent such a big deal now
2483that CPUs have speculative execution. In the few parts of a program
2484where speed matters you should optimise things in software.
2485
2486<p>A lot of C++ is workarounds to deal with consts, if you remove the
2487const idea then you dont need those workarounds. Seems worth removing 
2488features if it makes life easier for the programmer and compiler.
2489A lot of the brilliance of C was the removal of features of earlier languages.
2490eg C removed call by reference, major C feature: all functions are call by 
2491value. But later people have reintroduced that. Call by reference leads
2492to complicated bugs. eg:
2493
2494<p><pre>
2495void f( int &x, int &y )
2496{
2497x++ ;
2498}
2499</pre>
2500
2501<p>The statement x++ CAN increase y also! eg:
2502
2503<p><pre>
2504int z ;
2505
2506f(z,z) ;
2507</pre>
2508
2509<p>Most programmers instinctively assume different names are orthogonal,
2510if you see x and y in a program, then x++ wont affect y. But if you 
2511allow reference variables you lose orthogonality of names. So its a good
2512idea to disallow reference variables. The original C idea was that if
2513you want to reference you go via pointers. That way the * operator
2514means other variables could be affected. Put it this way: I can implement
2515C++ without any of these new ideas and without any problems.
2516This may sound strange but I am saying that old C is a better language
2517than C++.
2518
2519<p>The above ideas arent decisions, the fact is that it is much easier
2520to code with C than C++. The biggest problem with C++ is that the usage is too
2521complicated. There are too many rules, too much thinking to generate code.
2522A subset of C++ is very good, but another subset isnt.
2523
2524<p><a name="20071026">============== 26th October 2007 ===============</a>
2525
2526<p>I am considering a TOTAL CHANGE OF PLAN! To abandon implementing C++
2527and instead to create my own answer to C++ instead.
2528
2529<p>The reason for this is various: I have no intention of using C++
2530and dont want anyone else to either so its a bit of a waste of time to
2531implement it. I can design and implement something much better in much less time.
2532To understand the HUGE difference this makes ALL the C++ work up to now is unnecessary 
2533if I do my own language and compiler.
2534
2535<p>All the work up to now has been firstly because C uses a pre-processor and
2536secondly because C's syntax is nonorthogonal to its semantics. By working on my 
2537own language firstly there will be no preprocessor AND secondly the syntax will be 
2538orthogonal. That immediately saves several months of work!
2539
2540<p>I can then go directly and implement my own OS using my own language.
2541This will save months of time for my project schema.
2542
2543<p>I think I can complete such at least 4 x as quickly as completing the C++ 
2544project. C++ and C are HUGELY inefficient from an implementation POV.
2545
2546<p>Now I still need to implement C at some point as that is the only
2547way to build my own language above my own OS. Without my own C compiler
2548I can only build my own language from say AmigaOS. But I can implement
2549C later. Its also MUCH MORE INTERESTING to design and implement my
2550own language.
2551
2552<p>What I am thinking of doing is completing off the current C++ phases of
2553work as that is just a few more hours of work
2554and then working on my own language which should implement lightning fast.
2555
2556<p>Later on then I will complete the C compiler.
2557
2558<p>I have begun today working on this and the progress is so rapid that
2559I think I have to do this.
2560
2561<p>IMO at least 75% of the work of implementing C and C++ is because of 
2562the maldesign. There are so many ways to overtake C++ that it would fill
2563a book. A lot of things in C++ are unnecessary, eg C++ allows you to 
2564define classes within classes, but I cannot see any use for that. 
2565Just move all your classes to the top level. C++ allows namespaces

2566within namespaces, but there is no point to that. You only need top
2567level namespaces. Other languages just use top level namespaces.
2568
2569<p>C++ is a case study in overgeneralisation and disregard for implementation.
2570In computer science implementation is everything, disregard it at your peril.
2571You can do much more than C++ with much less work than C. Also I want something 
2572geared differently from C++, the reason I wont ever use C++ is it is wrongly geared.
2573
2574<p>Why reimplement C++ when it is much less work to overtake it?
2575
2576<p>So just as I am attempting to overtake Unix I will now attempt to 
2577overtake C++.
2578
2579<p>To understand the change of direction: I can overtake where I reached with C++ 
2580in a matter of DAYS!
2581
2582<p>You have to remember that C is from around 1978 and C++ is from around 1985,
2583both are dinosaurs.
2584
2585<p>My plan is to create something which matches all the good points of C and C++
2586without the bad points.
2587
2588<p>My earlier compiler projects were all geared to a well designed language,
2589I didnt realise then how badly designed C and C++ were. Anyway now I can
2590use the earlier compiler projects for what they were meant for namely
2591a well designed language.
2592
2593
2594<p><a name="20071025">============== 25th October 2007 ===============</a>
2595
2596<p>The first version of the current C++ phase is complete and built.
2597However this first version cannot be used yet until I resolve 
2598several problems. One problem is that I need to implement some features
2599in C- which this phase depends on. Another problem is that an even 
2600earlier phase of the project needs to be modified.
2601
2602<p>Some features are missing also with this current phase eg 
2603I havent dealt with C++'s redefinable operators. I'll probably work on 
2604those later.
2605
2606<p>The phases so far deal with the features I mentioned which possibly
2607I wont implement. The switch construct is done the ordinary way which 
2608IMO is the right way. The guys who invented switch had the idea that
2609you test a value and take different actions according to which const it matches.
2610
2611<p>ie you test a value x and if it is x0 you take action0, if it is x1 you 
2612take action1 etc. where x0, x1 are consts known at compile time.
2613
2614<p>That is what I will implement and that will deal with all situations.
2615
2616<p>I will implement what I want how I want when I want, its my compiler
2617and I can do whatever I wish with it. I want to use the compiler for
2618constructing my OS. And the OS will only use the C subset of the compiler.
2619
2620
2621
2622<p><a name="20071024">============== 24th October 2007 ===============</a>
2623
2624<p>I am progressing now with the current early phase of my C++ project.
2625I am implementing my own interpretation of C++ and NOT the official version.
2626My interpretation is how one actually programs with C++ eg it will deal
2627with the code in the tutorial book I learnt C++ from.
2628
2629<p>Generally speaking it is better to program in C, if you do 
2630objects via C tricks you get much better code than using C++.
2631No idea why C++ and Windows are so popular,
2632
2633<p>An example where my code is different from Stroustrup's definition of C++,
2634
2635<p>Stroustrup regards a switch statement as having the form:
2636
2637<p><pre>
2638switch( expression_list )any_statement
2639</pre>
2640
2641<p>This means that he and therefore gcc accept:
2642
2643<p><pre>
2644switch( 1, 2, 3 );
2645</pre>
2646
2647<p>which is a bit of a pointless liberty. In order to do this he 
2648has to regard cases as being normal statements. But they are disallowed
2649outside of switches. So eg gcc rejects:
2650
2651<p><pre>
2652void f(void)
2653{
2654case 10 : ;
2655}
2656</pre>
2657
2658<p>The only point I can see is that it allows you to bracket off a case:
2659<p><pre>
2660switch( 1, 2, 3 )
2661	{
2662		{
2663		case 10 : ........
2664		}
2665	}
2666</pre>
2667
2668<p>But this leads to problems such as:
2669
2670<p><pre>
2671switch( 1, 2, 3 )
2672	{
2673	while( y )
2674		{
2675		if( x > 10 ){ case 30 : t = 10 ; }
2676		else { case 20 : t = 11 ; }
2677		}
2678	}
2679</pre>
2680
2681<p>It just complicates the compiler. In fact to my amazement gcc accepts the above,
2682but that is bad code as you SHOULD NEVER jump into compound statements. You can jump
2683out but not in. 
2684
2685
2686<p>So with my interpretation I only allow the normal form of switch:
2687
2688<p><pre>
2689switch( 1, 2, 3 )
2690	{
2691	case CONST_EXPRESSION1 : case CONST_EXPRESSION2 : ......
2692		any_statements
2693	........
2694	}
2695</pre>
2696
2697<p><code>default:</code> also allowed instead of a case. Case expressions arent
2698allowed to be bracketed. 
2699
2700
2701<p>That removes a whole wad of work that noone uses!
2702
2703
2704<p>One problem with bracketing off a case mentioned above is it violates the
2705idea of never jumping INTO a compound construct. I had a look at some open source
2706and found everyone does switch cases the way I do. I think with my compiler I
2707will disallow all jumping into compound constructs. You can jump forwards or backwards
2708but only at the same level or outwards relative to {} constructs. Some C programmers
2709even never use goto's at all as they object to all jumping.
2710
2711<p><pre>
2712{
2713a:
2714   {
2715   b:
2716      {
2717      c: 
2718      }
2719   d:
2720      {
2721      e:
2722      }
2723   f:
2724   }
2725g:
2726   {
2727   h:
2728      {
2729      i:
2730         {
2731         j:
2732         }
2733      k:
2734      }
2735   l:
2736   }
2737m:
2738}
2739</pre>
2740
2741<p>:from c: you can jump to a: b: d: f: g: and m: and not to any other label.
2742Jumping is more complicated with C++ than with C as C++ has automatic freeing
2743of classes when you leave a compound construct: if you jump from c: to a:
2744the code has to free things from the 2 enclosing scopes. I personally NEVER
2745use the automatic classes as I like to control everything at the source level
2746not at the compiler level.
2747
2748<p>This is all about "structured programming", where you try to only use
2749very regular constructs. C and C++ are very unstructured languages, but by 
2750avoiding all the bad stuff you can write structured programs.
2751
2752<p>The advantage of structured programming is that bugs are less likely
2753and it is easier to write, read and understand code. Also its much easier
2754to write a compiler for a structured language than an unstructured one.
2755
2756<p>I personally do use goto's but usually I only use gotos forwards and 

2757to the same or an outer point in the scoping. Also I dont allow goto's to 
2758cross. But sometimes you need crossing gotos eg for a Turing machine:
2759
2760<p><pre>
2761state1: 
2762
2763switch( get_symbol() )
2764	{
2765	case 1 : action1_1() ; goto state20 ;
2766	case 2 : action1_2() ; goto state7 ;
2767	....
2768	}
2769
2770state2:
2771....
2772</pre>
2773
2774<p>You can do that without gotos but its not as fast, just a bit slower.
2775Structured programmers avoid gotos like this:
2776
2777<p><pre>
2778if( x &gt 3 )goto xyz ;
2779
2780........
2781
2782xyz:
2783
2784</pre>
2785
2786
2787<p>is redone as:
2788<p><pre>
2789if( x &lt= 3 )
2790	{
2791	.......
2792	}
2793
2794xyz:
2795
2796</pre>
2797
2798<p>The problem with that is it increases the nesting of the code, if 
2799there are many gotos you end up with excessive nesting eg:
2800
2801<p><pre>
2802if( x &gt 3 )goto xyz ;
2803....
2804if( y &gt 4 )goto xyz ;
2805....
2806if( z &gt 5 )goto xyz ;
2807....
2808xyz:
2809</pre>
2810
2811<p>becomes:
2812
2813<p><pre>
2814if( x &lt= 3 )
2815	{
2816	....
2817	if( y &lt= 4 )
2818		{
2819		.....
2820		if( z &lt= 5 )
2821			{
2822			........
2823			}
2824		}
2825	}
2826xyz:
2827</pre>
2828
2829<p>The code is moving rightwards too much and is much more complicated to read
2830than the original goto version. gotos are alright just use them carefully.
2831
2832<p>I may even change the project to "structured C++" where I only implement
2833the things I use or approve of. That will greatly speed up the development.
2834eg to not implement automatic variables:
2835
2836<p><pre>
2837xyz  a( 1, 2, 3 ) ; // DISALLOW
2838xyz *a = new xyz( 1, 2, 3 ) ; // ALLOW
2839</pre>
2840
2841<p>The problem with automatic variables is first they are on the stack
2842which is VERY wasteful of the stack, and second you need invisible deallocation
2843code, so eg if you jump out 2 levels of nesting the jump has to be via 
28442 lots of deallocations before you reach the label. I can implement such things
2845but it will just delay progress.
2846
2847<p>Another thing I want to disallow is:
2848
2849<p><pre>
2850struct { int x, y , t ; } a, *b, c ;
2851struct z { int u , v ; } w ;
2852</pre>
2853
2854<p>Instead:
2855
2856<p><pre>
2857struct abc { int x, y, t ; } ;
2858struct z { int u, v ; } ;
2859
2860struct abc a, *b, c ;
2861struct z w ;
2862</pre>
2863
2864<p>Here I am disallowing unnamed types, that is rarely used and 
2865greatly complicates the compiler. And to disallow constructs which
2866define and reference simultaneously. One problem with unnamed types
2867is it complicates error messaging AND makes it unfeasible to allocate.
2868
2869<p>If you look at the above 2 fragments you will see the second one
2870is much clearer to read and understand.
2871
2872<p>With real code, struct definitions tend to be in header files 
2873and variable declarations in source files.
2874
2875<p>Another thing I want to disallow is:
2876
2877<p><pre>
2878typedef struct x { int y, z ; } a, *x_t ;
2879</pre>
2880
2881<p>This is even worse as it is doing 3 things: it is defining the struct,
2882then the typedef is referencing the struct to define further types.
2883Instead:
2884
2885<p><pre>
2886struct x { int y, z ; } ;
2887typedef struct x a, *x_t ;
2888</pre>
2889
2890<p>This way typedefs only reference pre-existing types. Again this
2891simplifies the compiler implementation.
2892
2893<p>ANSI C++ itself disallows various things allowed in C, eg C allows
2894<p><pre>
2895int f( x, y , z ) ;
2896</pre>
2897
2898<p>which noone uses, whereas ANSI C++ disallows that, instead you need:
2899
2900<p><pre>
2901int f( int x, int y, int z ) ;  // (A)
2902int g( int, int, int ) ;  // (B)
2903</pre>
2904
2905<p>In fact (A) is better than (B) as you can create the prototype (A) just
2906by cut and paste from the actual function. So maybe I should disallow (B).
2907
2908<p>Although (B) helps the compiler its NO USE for the programmer as 
2909you dont know which argument is what, whereas if you have:
2910
2911<p><pre>
2912int g( int width, int height, int count ) ;
2913</pre>
2914
2915<p>Then you know exactly what to do. So I think I will disallow (B).
2916If you look at the AmigaOS proto includes you will see ALL args are named.
2917
2918<p>GNU C++ seems to reject functions defined in functions,
2919so I probably wont implement those! GNU C OTOH appears to accept them.
2920Its not a big deal to implement them but I dont see the point,
2921
2922<p>These types of things improve code quality and simplify the compiler.
2923I havent decided yet if I wont implement the above, but I dont want to 
2924implement them.
2925
2926
2927<p><a name="20071022">============== 22nd October 2007 ===============</a>
2928
2929<p>

2929I tried implementing C++ the way C++ is described in Stroustrup's book
2930(Bjarne Stroustrup being the guy who invented C++), but that led to 
2931endless problems. So now I have reverted to the commonsense approach
2932implementing C++ according to my interpretation of it. This is making 
2933better progress.
2934
2935<p>Although I am implementing C++ I only guarantee to attempt to implement
2936the C subset of C++. I am only attempting to implement C++ as that will
2937avoid duplication of effort.
2938
2939<p>I find Stroustrup's book is only good if you already mostly know what
2940you are doing.
2941
2942<p>C++ generally tries to be too clever, eg it has 5 different ways to 
2943do typecasts, NONE of the new ways I have ever used!
2944eg const_cast allows typecasts where ONLY the const-ness 
2945is altered. The thing is that in a well written program 
2946typecasting is rare so you shouldnt waste language definition 
2947on rare phenomena otherwise you get an inefficient language definition.
2948In fact I mostly dont use the "const" construct as it slows down
2949development too much. If I use "const" I have to perpetually stop and
2950think: "is this a const?". The main advantage of "const" is it allows
2951the compiler to cache the value of a const in a register. But todays
2952computers are so fast that it doesnt make a lot of difference.
2953Its only a tiny subset of a program that determines speed,
2954in those cases you can optimise for consts in the source by 
2955caching the const in a variable in the program. 
2956
2957<p>The other problem is that a non const variable could be locally const,
2958eg window_move(....) changes x,y but doesnt change w,h. And window_resize()
2959changes w,h but not x,y. So eg window_move(....) clearly doesnt change
2960the area of the window.
2961
2962<p><a name="20071019">============== 19th October 2007 ===============</a>
2963
2964<p>I have completed the initial subphase mentioned yesterday. 
2965I have been looking at some of the amendments to C++. I cannot guarantee
2966to implement each and every change they make to the language. When 
2967programming with C++ try and avoid things which COULD be interpreted 
2968more than one way.
2969
2970<p>Almost ready to begin the next subphase which is more complicated.
2971
2972
2973<p><a name="20071018">============== 18th October 2007 ===============</a>
2974
2975<p>I have almost completed an initial subphase of work, this subphase is 
2976timeconsuming but straightforward. The subphase contains various problems
2977so the next subphase will be working around those problems.
2978
2979<p><a name="20071017">============== 17th October 2007 ===============</a>
2980
2981<p>I am busy now working towards C++, there's a lot of gruntwork before
2982there is anything of interest. The C- idea is making the work much 
2983better than it had been when I first tried to directly implement C++.
2984
2985<p><a name="20071016">============== 16th October 2007 ===============</a>
2986
2987<p>I am restarting the C++ compiler project now. Missing functionality 
2988in C- will be worked on as needed. For the OS project in fact I just 
2989need the C subset of C++ to function.
2990
2991<p>Anyway C- now patches the ambiguities of C++, all of which relate 
2992to the ambiguity between types and variables.
2993
2994<p>An example ambiguity is something like:
2995
2996<p><pre>
2997x::y::z &lt t, u &gt ::v (w) ;
2998</pre>
2999
3000<p>That could either be a variable declaration of w or a function call
3001with argument w. This particular example isnt too bad as the syntax
3002is the same either way. But the problems are worse for say:
3003
3004<p><pre>
3005z = (x)&(y) ;
3006</pre>
3007
3008<p>& could either be binary & or it could be address & with (x) a typecast.
3009Those are syntactically different: binary & is <code>binary_and(x,y)</code>
3010whereas unary & with typecast is <code>type_cast( x, address(y))</code>. The bracketing
3011is totally DIFFERENT, the latter fragment has 2 operators the former has just 1. 
3012That is just bad design as it means the syntax is DEPENDENT
3013on the semantics. With a well designed language the syntax is INDEPENDENT 
3014of the semantics and you can process the syntax first disregarding semantics.
3015If syntax is orthogonal to semantics that makes it MUCH EASIER to implement 
3016a compiler. Via C- I can patch the problem, C- figures out which things are 
3017types and inserts @ before those. That orthogonalises the syntax, allowing
3018the next phase to be much cleaner.
3019
3020<p>So if & above were the address operator then C- changes the fragment to:
3021<code>z = (@x)&(y) ; </code>.
3022
3023<p><a name="20071014">============== 14th October 2007 ===============</a>
3024
3025<p>A first version of C- is now complete. This probably does have bugs and 
3026some missing features. AFA C goes anything missing should be straightforward
3027to implement. And AFA C++ goes it should deal with NORMAL programs with missing
3028features straightforward. If you really push C++ to its pedantic limits then
3029there could be problems.
3030
3031<p>One feature I havent implemented yet is "friend", I will implement that later on.
3032A complicating factor is a friend declaration to a function not yet declared,

3033which scope is it in? C++ does specify how to deal with this.
3034TBH C++ is a bit overanxious eg my C++ compiler will be 
3035ENTIRELY written in C where ALL fields are public. Stroustrup gives the example
3036of multiply( matrix , vector ), where for speed multiply needs to access 
3037private fields of both matrix and vector. So he makes multiply a friend of 
3038matrix and vector.
3039
3040<p>The real problem is that the object paradigm has limits and multiply()
3041is something BEYOND the limits of the paradigm, so he has to hack the 
3042object paradigm to deal with it via the "friend" idea.
3043
3044<p>Objects are variable centric, multiply() is an API centric problem.
3045C++'s problem is its vantage point is wrong, C++ is an object centric 
3046language. Real programming is API centric.
3047
3048<p>The C++ tutorial book I have doesnt mention "friend" at all so 
3049it must be a more obscure feature of C++.
3050
3051<p><a name="20071013">============== 13th October 2007 ===============</a>
3052
3053<p>The C- "using" bug took some work to resolve but its resolved now.
3054The "using" directive means C++ tries to resolve things relative to 
3055several namespaces. On resolution the compiler must still check the 
3056remaining namespaces: multiple resolutions mean an ambiguous resolution.
3057
3058<p><pre>
3059using namespace x1 ;
3060using namespace x1::x2 ;
3061using namespace x3::x4 ;
3062
3063typedef y z ;
3064</pre>
3065
3066<p>:if <pre>x1::y</pre> and <pre>x1::x2::y</pre> are both defined then 
3067<pre>y</pre> has an ambiguous resolution. The compiler attempts to 
3068resolve y relative to all 3 namespaces and the top level namespace.
3069
3070<p>The bug was that on finding a resolution the later unsuccesful resolutions
3071were overriding some of the successful resolutions parameters resulting in a 
3072failed resolution. I just had to backup all the parameters on success.
3073Finding the bug was the tricky thing, resolving it was just a few lines of code.
3074
3075<p>Just one tricky thing left to do and I will probably then begin on the 
3076C++ compiler.
3077
3078<p><a name="20071012">============== 12th October 2007 ===============</a>
3079
3080<p>I completed implementing the "using" directive today for C-. 
3081Currently there is a bug with this so I am working on that at the moment.
3082
3083
3084<p><a name="20071011">============== 11th October 2007 ===============</a>
3085
3086<p>The most difficult part of C- template classes are now implemented and built 
3087but not fully debugged. Working on a bug at the moment. 
3088There are various things not yet implemented. I really dont like C++ at all,
3089its too complicated and the syntax is too inefficient. You can do much more
3090with much less. Templates are a very inefficient and complicated way to do 
3091things, a total pain to implement.
3092
3093<p><a name="20071008">============== 8th October 2007 ===============</a>
3094
3095<p>I think I have the trickiest part of the C- templates implemented.
3096I am not completely sure as templates are very complicated to implement.
3097I need to study very carefully what I have done. Using templates isnt 
3098too bad but to implement them is very tricky. Even GNU's C++ has bugs 
3099with their templates, thats a sign of bad language design if mainstream 
3100compilers have difficulty implementing a language.
3101
3102<p>630pm: I found some problems I hadnt dealt with. Those are now dealt with.
3103Looking now for any further problems. Later implementing C++ will be very similar 
3104so this in a way is good preparation for that.
3105
3106<p><a name="20071006">============== 6th October 2007 ===============</a>
3107
3108<p>The work on C- templates is getting ever more complicated,
3109nonetheless I am making progress.
3110
3111
3112
3113<p><a name="20071005">============== 5th October 2007 ===============</a>
3114
3115<p>I am working on C- templates at the moment. This is the most difficult 
3116part of the C- subproject. The main use of templates is for recursively 
3117variable types: variable types with variable "subtypes", for example:
3118
3119<p><pre>
3120template &lt class x, class y &gt class z
3121	{
3122	template &lt class a, class b &gt class c 
3123		{
3124		a a1 ;
3125		b b1 ;
3126		x x1 ;
3127		y y2 ;
3128		} ;
3129	} ;
3130</pre>
3131
3132<p>Here c is a variable "subtype" of the variable "type" z. 
3133(I say "subtype" and not subtype as that is probably the wrong word but
3134its the best way to refer to the phenomenon.)
3135
3136<p>It took many days of effort to find a way to implement such variable types.
3137I am currently implementing the plan I eventually arrived at. All the
3138C- and C++ work runs above 68k-AmigaOS as a cross compiler.
3139
3140<p>C++ templates allow references to nonexistent things eg in the above
3141fragment you can refer to eg <pre>x::t</pre> which is nonexistent nonsense,
3142this leads to an unresolvable ambiguity that we dont know if x::t is a type
3143or a variable. GNU C++ deals with this problem by ALWAYS assuming <pre>x::t</pre>
3144to be a variable UNLESS it is preceded by the keyword "typename".
3145(something I learnt from GNU C++'s error messages!)
3146
3147<p>Stroustrup the inventor of C++ doesnt mention typename in his book,
3148so he probably wasnt aware of the problem. Anyway I will use GNU's typename 
3149idea to deal with the problem as that seems a reasonable idea.
3150
3151<p>It does appear to prove that C++ as described by Stroustrup is truly 

3152ambiguous.
3153
3154<p>I dont know why everyone backed C++ as it is such a royal pain to implement.
3155
3156
3157
3158<p><a name="20070916">============== 16th September 2007 ===============</a>
3159
3160<p>The C subset of C- is complete and the C++ subset is mostly done,
3161just one tricky thing left to implement is templates. C- so far will 
3162catch a lot of errors. But some things it wont, and it allows a certain
3163amount of nonsense. Originally I was going to prefix things like
3164<pre>a::b::c</pre> by <pre>class</pre> wherever the construct was a type.
3165But that conflicts with C++ eg the following is wrong in C++:
3166
3167<p><pre>
3168typedef int a ;
3169
3170class a z ;
3171</pre>
3172
3173<p>With GNU C++ class and struct can only qualify something which is either
3174a class or struct, eg struct can qualify a class and vice versa.
3175
3176
3177
3178<p>So instead C- will prefix such ambiguities by @, I think some of the GNU 
3179build tools do customisable C code using @ symbols. The @ symbols will be prompts
3180for the C++ compiler to know whether a construct is a type or a variable.
3181It is much work to determine which. An example of what C- will do:
3182
3183<p><pre>
3184namespace 
3185	{
3186	namespace a
3187		{
3188		typedef struct b { typedef int u ; int v ; } w ;
3189		}
3190	}
3191
3192a::b::u f( a::w::u x ) ;
3193</pre>
3194
3195<p>will be redone by C- as:
3196
3197<p><pre>
3198namespace 
3199	{
3200	namespace a
3201		{
3202		typedef struct b { typedef int u ; int v ; } w ;
3203		}
3204	}
3205
3206@ a::b::u f( @ a::w::u x ) ;
3207</pre>
3208
3209<p>So all that C- does is insert @'s, but that is a complicated thing to do
3210and it has to deal with multiple inheritance and templates. Currently it 
3211ignores private and public qualifiers as any errors with those will be 
3212detected by the C++ compiler. The inserting of @'s AFAICT removes all the 
3213unpleasant ambiguities of C++. I could actually continue C- to be a C++ compiler
3214but it looks better to do C++ as another phase.
3215
3216
3217
3218<p><a name="20070912">============== 12th September 2007 ===============</a>
3219
3220<p>I have made some progress now towards C-. Where there is a conflict between
3221C and C++ I will go for the C++ idea.
3222
3223<p>eg C++ doesnt allow the following 2 lines of code:
3224<pre>
3225int f(x,y) ;
3226int f(x,y){ return( x + y ) ; }
3227</pre>
3228 
3229<p>whereas C allows both. With C++ you have to do:
3230<pre>
3231int f(int,int) ;
3232int f(int x, int y){ return( x + y ) ; }
3233</pre>
3234
3235<p>which is also accepted by C, so I will only allow the second fragment.
3236The latter makes implementing the compiler easier as you dont have to deal 
3237with int args as a special case eg there is a further complicating factor
3238for C if you have:
3239
3240<p><pre>
3241typedef double x, y ;
3242double f(x,y) ;
3243</pre>
3244
3245<p>Are the arguments of f integer or double?
3246
3247<p>Probably double, but the problem is that if you are reading some code
3248and there are endless header files you dont have the time to find whether
3249by coincidence x and y are types. Disallowing this means that you ALWAYS
3250know that a prototype argument ALWAYS starts with a type.
3251
3252<p>C- at the moment does some correctness checking, eg it will deal with:
3253
3254<p><pre>
3255
3256typedef struct { typedef struct { typedef int x ; } y ; } z, (t), u ;
3257
3258typedef t::y::x v ;
3259
3260</pre>
3261
3262<p>As you can see, with C++ things are much more complicated than with C.
3263
3264<p>Notice that C++ structs are almost identical to C++ namespaces.
3265
3266
3267
3268
3269<p><a name="20070910">============== 10th September 2007 ===============</a>
3270
3271<p>The work towards C- is proving very tricky. I am progressing but 
3272very gradually.
3273
3274<p><a name="20070905">============== 5th September 2007 ===============</a>
3275
3276<p>I want my system to deal with gcc C++ headers, gcc is using really obscure
3277C++ functionality. Admittedly that is just header stuff so my own headers dont
3278need to use such things. it has things like:
3279
3280<p><pre>
3281struct x : public y { ..... }
3282</pre>
3283
3284<p>And I thought that was only allowed for classes. A strange construct gcc uses is:
3285<p><pre>
3286extern "C" { .... } 
3287</pre>
3288
3289<p>It does lots of such strange things, here is another one:
3290
3291<p><pre>
3292__extension__ typedef long long _G_llong ;
3293</pre>
3294
3295<p>What on earth is <pre>__extension__</pre>?
3296
3297<p>

3297It is all quite infruriating. I dont guarantee to support all such things
3298as I dont want to spend 10 years implementing stuff that NOBODY uses.
3299
3300
3301<p><a name="20070904">============== 4th September 2007 ===============</a>
3302
3303<p>I managed to resolve the compiler subproject bug. I tried the preprocessor
3304on a demo C++ source file, there was a preprocessor bug with this. 
3305It took a lot of work to locate the bug. I am continuing now on the first phase of C-. 
3306I have 4 languages to consider: C-preprocessor, C-, C and C++.
3307
3308<p>The initial version of the first phase of C- located some problems in the
3309AmigaOS includes: some function prototypes use an arg name "template" but 
3310that is a keyword of C++.
3311
3312
3313<p>11pm: On a certain example file the system freezes up after trying the preprocessor, trying
3314to determine the problem.
3315
3316<p>1am: at last resolved the freeze up, it was to do with resetting the current directory
3317and unlocking directory locks in the wrong order on AmigaOS. The preprocessor
3318changes current directory to the directory of the include it is currently processing.
3319
3320
3321
3322
3323
3324<p><a name="20070903">============== 3rd September 2007 ===============</a>
3325
3326<p>Trying out the initial version of the first phase of C- on a real example
3327has led to a very deep bug in the compiler subprojects. I can see 2 possible
3328ways of dealing with it, am making a study of those
3329
3330
3331<p><a name="20070902">============== 2nd September 2007 ===============</a>
3332
3333<p>In order to continue towards C++ I have had to make some major improvements
3334to the earlier compiler subprojects. 
3335
3336<p>I am continuing now with the C- project. Its a very unusual project as it 
3337is both superficial and difficult.
3338
3339<p>I have got an initial version of the first phase of the C- project,
3340I have been trying this out on a real source file and resolving the problems.
3341Right now it has gone 3% through the file before halting on "extern",
3342so I have just corrected that. C- is supposed to understand ALL C and C++ source
3343files.
3344
3345<p><a name="20070821">============== 21st August 2007 ===============</a>
3346
3347<p>The C++, C and C- work is proving to be very tricky, 
3348
3349<p>I think today was the trickiest day of all my projects so far.
3350I dont even know if the C- idea will work, even if it does C is a very 
3351tricky language, for instance C's function types are almost impossible eg:
3352<p><pre>
3353void (*(f( int (*g)( int, int ) )))(int (*)( int (*)(void) ) ){ return( 0 ) ; }
3354</pre>
3355
3356<p>That's not a void function even though void is written there!
3357(if you compile it with gcc you will see no error)
3358
3359<p>Although C is nice to code with, implementing it is an adventure into hell.
3360
3361<p><a name="20070820">============== 20th August 2007 ===============</a>
3362
3363<p>A new ambiguity which I think I cannot deal with: <pre>x(*f)(a);</pre>
3364This could either be a declaration of a variable f, pointer to function
3365with argument type a and return type x. OR it could be a double call,
3366x called with arg *f and the returned function pointer called with a as arg.
3367
3368<p>So it looks like I have to go for a dialect of C(++) similar to gcc's. 
3369My implementation though
3370will be quite different, my plan is to create a low level language C- 
3371which takes a preprocessed C file and inserts a marker keyword at all
3372<pre>a::b::c::d</pre> expressions which are types. That will remove all
3373the ambiguities and will greatly simplify the C++ compiler.
3374
3375<p>330pm: I am working on the above idea now, if <pre>a::b::c::d</pre> is
3376a type it will be redone as <pre>class a::b::c::d</pre>. I think I can
3377implement the C- and C++ as the same program, you run the program twice
3378to compile a preprocessed C file.
3379
3380<p>515pm: change of plan, I will do C- as a standalone language,
3381it looks too complicating to superpose C++ and C-.
3382
3383<p>630pm: I am working now on the C- project! 
3384
3385<p>1230am: the C- work continues, this is a gruntwork subproject.
3386
3387<p><a name="20070819">============== 19th August 2007 ===============</a>
3388
3389<p>Another ambiguity:
3390
3391<p><pre>
3392x (y) ;
3393</pre>
3394
3395<p>That could either be a variable declaration of variable y of type x,
3396OR it could be a function call, function x with argument y.
3397
3398<p>

3398The irony is that a well designed system is much less work,
3399
3400<p>I have had an idea, the way to deal with all these situations is
3401to avoid unnecessary bracketing. So if the compiler sees an ambiguity it 
3402will assume the bracketing is necessary:
3403
3404<p><pre>x (y)</pre> is a call,  <pre>x y</pre> is a variable declaration.
3405<pre>(x)&y</pre> is a typecast, <pre>x & y</pre> is a binary op,
3406<pre>(x)(y)</pre> is a call, <pre>(x)y</pre> is a typecast,
3407<pre>sizeof x</pre> is a variable, <pre>sizeof( x )</pre> is a type,
3408
3409<p>The only possible problem is that an expression could be from a macro,
3410I think in the rare cases where that happens you have to work-around 
3411things somehow eg the user supplies the bracketing. Usually macros 
3412rebracket all args, but for the rare cases where the above idea 
3413conflicts, the caller of the macro can supply the bracketing.
3414I'll wait till I see an actual example.
3415
3416<p>If the compiler interprets different from what the user meant it will
3417always generate an error.
3418
3419<p>8pm: So far the above idea looks feasible, it does mean the compiler is not completely
3420compatible with gcc, but it simplifies the implementation. And it must be very
3421rare for there to be any problems. The central ambiguity is that
3422<pre>a::b::c::d</pre> can be either a type or a thing, and that the 
3423interpretation as a type completely conflicts with as a thing for several
3424of the ambiguities. 
3425
3426<p>The advantage of the above idea is it is entirely syntactic and local.
3427
3428<p>145am: one further ambiguity:  <pre>x *y ;</pre> can either be a variable
3429declaration or an expression statement. Clearly such an expression statement
3430is meaningless so I think I will deal with this by disallowing such meaningless
3431expression statements. What possible point can there be to a statement "x * y ;"?
3432email me if you can see any point.
3433
3434<p>As with the earlier idea, any misinterpretation will result in a compiler error,
3435so it cannot lead to problems. If these ideas conflict with another compiler then
3436all you do is conditional compilation via #if etc!
3437
3438<p>The advantage of these ideas is it creates a clean dialect of C, it basically
3439orthogonalises the phases of compilation. I think gcc's approach must be nonorthogonal
3440with dependencies between the phases.
3441
3442
3443
3444<p><a name="20070818">============== 18th August 2007 ===============</a>
3445
3446<p>Further to yesterday I have found another C ambiguity:
3447
3448<p><pre>(x)(y)(z)(t)</pre>  that could be a sequence of typecasts OR 
3449it could be a sequence of function calls!
3450
3451<p>ie <pre>x, y, z</pre> could be types or they could be functions.
3452
3453<p>Each of these ambiguities is extra hassle.
3454
3455<p>There are endless complicating factors, here is one: in a for loop 
3456the first part of the "for" is a list of statements, but can any statement at all
3457be there? eg is the following allowed?:
3458
3459<p><pre>
3460for(  for( i = 1 ; i < 10 ; i++ ){ printf("hello");}, int j = 0 ;  j < 100 ; switch(j){ case 0 : ;})
3461	{
3462	}
3463</pre>
3464
3465<p>Having say <pre>for( i = 1 ; i < 10 ; )i++ ;</pre> within the initialisation of another
3466for loop will create a problem because of the semicolon, not sure if you have to omit the
3467semicolon then eg: <pre>for( for( i = 1 ; i < 10 ; )i++, x = 10 ; ; );</pre>
3468
3469<p>The only way to decide is to see what gcc does, if gcc doesnt allow something then 
3470I wont. As mentioned on 11th August gcc tends to disallow tricky scenarios.
3471
3472<p>Kernighan and Ritchie, and Stroustrup say absolutely nothing about this problem,
3473Stroustrup appears to have just copied K&R 
3474and gcc rejects for loops in another for loop's initialisation. In fact K&R refers
3475to the initialisation as an "expression".
3476(K&R first edition page 56 says <pre>for( expr1 ; expr2 ; expr3 )statement</pre>,
3477but expr1 isnt an expression. The book says "grammatically the three components of a for
3478are expressions.")
3479
3480<p>Well a true expression is a bit pointless, but gcc DOES appear to allow expressions
3481as statements eg "1==1;" is a valid statement with gcc even though it is pointless.
3482
3483<p>Semantically speaking the first part of a for is statements, the second part is 
3484a boolean expression and the last part is reinitialisation statements.
3485Note that for and switch statements arent expressions, perhaps that is the idea.
3486Its an incoherent setup eg it allows <pre>for( 1, 2, 3, 4, 5 ; ; );</pre> which is 
3487jibberish.
3488
3489<p><a name="20070817">============== 17th August 2007 ===============</a>
3490
3491<p>Continuing with the initial C++ work, the work is complicated and slow
3492moving.
3493
3494<p>One problem is that C has various ambiguities eg:
3495
3496<p><pre>
3497
3498typedef int y ;
3499
3500void f(void)
3501{
3502int y = 5 ;
3503int x ;
3504int z = 10 ;
3505x = (y)+z ;
3506x = (y)-z ;
3507x = (y)&z ;
3508}
3509</pre>
3510
3511<p>The last 3 statements are all ambiguous as <pre>(y)</pre> could either be a typecast 
3512of the 3 unary operators + - and & OR y could be the variable and the + - and & 

3513are binary operators. I think if both have meaning then its a typecast,
3514it is just irritating that such an ambiguity exists. That is quite a major ambiguity
3515as its an ambiguity whether the operator is unary or binary.
3516
3517<p>There is also an ambiguity with sizeof:
3518<p><pre>
3519
3520typedef struct { int a, b, c ; } x ;
3521
3522int f(void)
3523{ 
3524int x ;
3525return( sizeof( x ) ) ; 
3526}
3527</pre>
3528
3529<p>Is that sizeof of a variable or a type? 
3530gcc appears to be going via the local variable, but that is nonetheless an ambiguity
3531eg someone could have sizeof(x) in a macro intending the type, but the macro could 
3532in fact give the size of a local variable. Ambiguities are ok if they are ambiguities
3533of things of the same category, eg an ambiguity between types, between variables,
3534between functions. But an inter-category ambiguity is incoherent design eg
3535between a type and variable, 
3536 
3537
3538
3539<p><a name="20070815">============== 15th August 2007 ===============</a>
3540
3541<p>I have some very initial work towards C++ done. Some very low level gruntwork,
3542
3543<p><a name="20070813">============== 13th August 2007 ===============</a>
3544
3545<p>130am: the C preprocessor is now preprocessing the example file from the
3546compiler project correctly. There were several bugs. I find the preprocessor
3547quite a painful project. My pre-processor is stricter than gcc eg gcc 
3548allows repeated definitions without error eg:
3549
3550<p>x.h is:
3551
3552<p><pre>
3553#define X  1
3554</pre>
3555
3556<p>y.c is:
3557<pre>
3558#include "x.h"
3559#include "x.h"
3560
3561int x = X ;
3562
3563</pre>
3564
3565<p>gcc will compile that without error! My pre-processor will give an error message
3566of a redefinition, it then uses the new definition and continues.
3567
3568
3569<p> I think I am now ready to continue with the C++ project.
3570
3571<p>8pm: I am coding now C++. This is a continuation of the compiler subprojects
3572so far. The C++ compiler will compile the output of the pre-processor project.
3573
3574
3575<p><a name="20070811">============== 11th August 2007 ===============</a>
3576
3577<p>Trying out the pre-processor I realised a tricky problem:
3578
3579<p>
3580<pre>
3581#define y  100
3582
3583enum x { y, z, t } ;
3584
3585
3586void f(void)
3587{
3588int y ;
3589
3590
3591y: ;
3592}
3593</pre>
3594
3595<p>The pre-processor is meant to be run first, but then the y in the enum
3596will be substituted by 100. The "int y" will become "int 100" and the 
3597y: will become 100:  If they didnt that would be very tricky to code,
3598fortunately gcc does strictly substitute the y's and then you get 
3599compiler errors in each case. I am thankful that gcc substitutes the y 
3600strictly in all situations. Looks like each potential problem will be
3601caught by the compiler when it works on the preprocessed code.
3602
3603<p>The OS project will only use C and asm, and the C++ compiler is being 
3604done in C. The reasons for implementing C++ are various, 
3605eg if I only implement C it wont be forwardly compatible with C++ so 
3606I will have to do yet another project to implement C++. C++ OTOH is 
3607backwards compatible with C.
3608
3609<p>I am not completely enthusiastic about C++! 
3610
3611<p>Some of C++ is very good and some isnt.
3612
3613
3614
3615<p><a name="20070810">============== 10th August 2007 ===============</a>
3616
3617<p>I am working on the current pre-processor bugs before continuing towards C++.
3618
3619<p>I have resolved the bug:
3620<p><pre>
3621#define x() y
3622</pre>
3623
3624<p>where there are no args, there is a further bug that if I call the macro eg:
3625
3626<p><pre>
3627#define x() y
3628x()
3629</pre>
3630
3631<p>that there is a bug with this. I will look at that next. There is just
3632one further C++ topic I need to study which is the C++ exceptions on which
3633I need further info in order to implement them.
3634
3635<p>530pm: all the empty arg bugs are now resolved. The preprocessor code 
3636for #define is very complicated. There may be further bugs elsewhere.
3637The pre-processor is now preprocessing gcc's &lt stdio.h &gt without error.
3638I want to implement one further feature for the preprocessor and then
3639will continue with C++.
3640
3641<p>1130pm: the gcc example now preprocesses correctly. I tried next to 
3642preprocess one of the compiler project source files, that revealed 2 further bugs.
3643But interestingly it located errors in the Geekgadgets AmigaOS includes, 
3644eg exec/io.h has:
3645
3646<p><pre>
3647#ifndef EXEC_PORTS_H
3648#include "exec/ports.h"
3649#endif /* EXEC_PORTS_H */
3650</pre>
3651
3652<p>That is WRONG! as it should be EITHER
3653
3654<p>
3655<pre>
3656#include "ports.h"
3657</pre>
3658<p> OR it should be:
3659
3660<p>
3661<pre>
3662#include <exec/ports.h>
3663</pre>
3664
3665<p>"somepath" in C represents a filepath RELATIVE to the current file, the above
3666is wrong, there were plenty further such errors!
3667
3668
3669
3670
3671<p><a name="20070809">============== 9th August 2007 ===============</a>
3672
3673<p>

3673I am gradually getting the 64 bit C++ compiler project started.
3674I have been doing a study of C++ for that and figuring out how to 
3675utilise my various compiler subprojects for this.
3676
3677<p>I will try and implement features such as templates, multiple inheritance,
3678operator overloading etc. 
3679
3680<p>I decided to try out my C pre-processor which I completed last November
3681on the gcc includes via a small test program. It malfunctioned at one point,
3682I have that bug resolved now. I retried it again and there is another bug
3683it doesnt deal with macros with 0 args eg:
3684<p>
3685<pre>
3686#define x()   y
3687</pre>
3688
3689<p>I will try to correct that bug. The preprocessor is meant to be compatible
3690with any C compiler, in particular it should be compatible with gcc.
3691
3692
3693<p><a name="20070802">============== 2nd August 2007 ===============</a>
3694
3695<p>I am restarting my compiler project. According to the updates I completed the
3696C preprocessor 25th Nov 2006, almost 8 months ago! Just doing a study of where
3697I reached. The build for the C preprocessor is highly convoluted, am just 
3698making sense of that. 
3699
3700<p>The project will now be to create a C++ compiler and not a C compiler
3701as originally planned. 
3702
3703
3704<p><a name="20070801">============== 1st August 2007 ===============</a>
3705
3706<p>330pm: I am making further progress now with the bug mentioned yesterday.
3707I now know more precisely what the problem is. It is a coincidence situation 
3708where 2 completely different phenomena happen at exactly the same time and 
3709the code overlooked this situation. I havent yet located where in the code
3710the problem happens but am progressing. There may well be 
3711further bugs.
3712
3713<p>335pm: it looks like a trivial error: I wrongly had jne where it should
3714have been je! je deals with the coincidence, jne leads to garbage.
3715It has taken more than 2 days of impossible work to locate that!
3716
3717<p>1130pm: well that one wrong ascii character removed now has both 
3718the tower and laptop launching 6 new tasks and then the launching task
3719gets frozen out. The launched tasks are functioning fine, so I now
3720need to debug why the launching task gets frozen out.
3721Anyway it is major progress.
3722
3723<p>220am: this next bug is proving equally evasive. 
3724
3725<p>430am: found the next bug, about to try that out. In fact above
3726there was an error message but the output of the other tasks obscured that.
3727I eventually found another spelling error!
3728
3729<P>5am: WHEEEEEHOOOOOOO! The new multiprocessor pre-emptive multitasking system
3730is now fully functioning. In the experiment the launching task and all 11 launched
3731tasks are functioning both on the 1-cpu and the 2-cpu systems. 
3732This new system tries to relaunch tasks to the same 
3733CPU whenever possible. This is to optimise cache usage, sometimes tasks 
3734will be relaunched to a different CPU. This is done via a complex 
3735heuristic optimisation. The effect on the experiment is quite dramatic.
3736With the original system each successive echo is on a different CPU 
3737(see earlier video) eg:  111[ 0 ] 222[ 1 ] 444[ 0 ] 777[ 1 ] ...
3738the cpu keeps alternating. With the new architecture the output 
3739is more unusual eg: 111[ 0 ] 555[ 0 ] 333[ 0 ] 888[ 1 ] 777[ 0 ] 444[ 1 ] 222[ 1 ]...
3740
3741<p>In this hypothetical output the architecture is preferring to relaunch 
3742task 5 to the same CPU as the previous task. The original architecture would have
3743relaunched task 5 to cpu 1. The acid test is whether things run faster, that
3744will have to wait till later. I will try and upload a video of the new 
3745architecture sometime.
3746
3747<p>I should say that currently I have only tested out all tasks being the same
3748priority. Eventually I will try out unequal priorities, so there could be bugs
3749in that.
3750
3751<p>I think I am ready now to restart the compiler project, the aim now is 
3752to implement a C++ compiler which will be 68k-AmigaOS hosted. I will make 
3753a 68k-AmigaOS hosted demo of this available, email me if you want to 
3754try that. It is too early for betatesting as that would require betatesting
3755the OS itself which is no-can-do at this point.
3756
3757
3758<p><a name="20070731">============== 31st July 2007 ===============</a>
3759
3760<p>Making very slow progress on the bugs. 
3761
3762<p>315am: After some 2 days of effort I have at last determined one 
3763scenario which freezes up the system. Its a needle in a haystack problem,
3764the bugs can be anywhere at all. I have to continue with this tomorrow.
3765
3766
3767
3768<p><a name="20070730">============== 30th July 2007 ===============</a>
3769
3770<p>I am looking at difficult multiprocessor bugs. 
3771At the moment the bug is that the one CPU locks A and then attempts to lock B. The other CPU has 
3772B already locked and attempts to lock A. Both wait forever. 
3773I thought I had designed the system so this couldnt happen.
3774I know what the problem is but havent yet determined 
3775the 2 places in the architecture where the conflict is arising.
3776
3777<p>Have found another similar bug, so far none are resolved, it is proving 
3778very difficult to locate. Just about to try another debug build of the OS.
3779
3780<p>1015pm: I am studying the code, I have found one bug already.
3781I have just removed that and will see if there is still a problem.
3782If I can get the code to function this week I will be doing well!
3783
3784<p><a name="20070729">============== 29th July 2007 ===============</a>
3785
3786<p>Almost 3 weeks since the last update! I implemented some major multiprocessor enhancements
3787to the multitasking. I have now split up the current module of the OS into smaller 
3788submodules. I also made space improvements: 

3789eg removing obsolete code and replacing some macros by functions etc,
3790I managed to reduce the size of the OS by 67K. I am now debugging the new multitasking
3791enhancements. Just about to try out yet another build.
3792
3793<p>Well, on the uniprocessor 6 of the 12 tasks run without problem and the 
3794other 6 dont appear to be running. On the dual core none of the further tasks run.
3795Looks like I have some debug work to do!
3796
3797<p>750am: after a lot of work on the 2-cpu system I now have one of the 
3798further tasks running. A lot yet to do.
3799
3800<p><a name="20070709">============== 9th July 2007 ===============</a>
3801
3802<p>I am working on some major improvements to the multiprocessor multitasking.
3803So at the moment the code doesnt function but I have a backup of the last
3804functioning version just in case.
3805
3806<p><a name="20070708">============== 8th July 2007 ===============</a>
3807
3808<p>I spent most of yesterday on one of the trickiest bugs yet.
3809That bug is now resolved.
3810
3811<p>Anyway the semaphored text is now functioning perfectly, I may upload a 
3812video of this. It is a very interesting phenomenon as the tasks AND cpus change
3813after each echo eg 111[ 0 ] 444[ 1 ] 333[ 0 ] 888[ 1 ] ... It goes through
3814all cpus and all tasks before repeating.
3815
3816<p>This means the output is very similar regardless of the cpu count.
3817
3818<p><a href="textsem.ASF">Here is a video</a> of the text semaphores.
3819This time I set the build to use white text on a blue background so it looks like
3820an Amiga 500! I can toggle off and on the text by pressing t on the keyboard,
3821this is done by toggling the echo string function with a no-op function. That isnt in 
3822the video as it could be misunderstood as a malfunction!
3823
3824<p>I am working now on some major enhancements to the multitasking, this is a 
3825subproject.
3826
3827
3828<p><a name="20070707">============== 7th July 2007 ===============</a>
3829
3830<p>Trying to get the improved semaphored text to function. Finding very 
3831tricky bugs. The code isnt yet properly functioning, so the multitasking 
3832subproject isnt complete yet.
3833
3834<p><a name="20070706">============== 6th July 2007 ===============</a>
3835
3836<p>A specific build of the system was freezing up on the tower each time.
3837I eventually found the bug which was a garbage pointer. :it was a precise
3838coincidence bug, the bug was only rarely invoked. But it happened each time
3839at exactly the same point JUST on the tower.
3840
3841<p>I am now doing gruntwork eg most of today was making the text echoing 
3842object oriented (in asm!). The reason is that once I implement graphics
3843I will need totally different text rendering via the same code. It was 
3844working on this that the bug above happened.
3845
3846<p>Next I am going to redo the text echo via proper semaphores.
3847As you can see in yesterday's video all tasks access the same space for
3848text, so only 1 can be allowed access at a time. With 2 cpus the system
3849would crash if both accessed the screen at EXACTLY the same time.
3850So when 1 task is writing, other tasks need to be held off with semaphores.
3851
3852<p>Much later on there will be windowing and tasks will have their own
3853private windows to echo text in. 
3854 
3855<p>Looks like I cannot use proper semaphores with my text as that 
3856interferes with the debug system. Text in general can be semaphored but not 
3857this particular low level text. But I can use an improved version of 
3858the text. I am running into some really strange problems eg testing 
3859out some things at first everything looked alright but eventually 
3860there were just 2 tasks left. All the others disappeared!
3861I eventually found a bug in the system where tasks were vanishing.
3862Any task which reached that part of the system vanished!
3863That problem is resolved. I now keep verifying that all 12 tasks are there.
3864One of the "features" of the architecture is proving to be a bug. 
3865So I have removed that feature. I spent a lot 
3866of time on that feature and didnt foresee the problem.
3867I am looking at an inefficiency problem at the moment.
3868
3869
3870
3871<p><a name="videos">
3872<a name="20070705">============== 5th July 2007 ===============</a>
3873
3874<p>The 64 bit multiprocessor pre-emptive multitasking seems to be functioning
3875fine now. I havent been able to get further malfunction. There could still
3876be bugs so I will continue to study the code. 
3877
3878<p>I think I will upload a video of this in action.
3879
3880<p><a href="multi.ASF">here it is</a>. This shows the tasks once all are 
3881running. Task 0 echoes 000[ m ] repeatedly where m is the cpu number,
3882task 1 echoes 111[ m ], ..., task 10 echoes 101010[ m ],
3883and the launching task echoes zzz[ m ].
3884
3885<p>So if you see 111[ 0 ] 444[ 1 ] 111[ 0 ] 444[ 1 ] ...
3886that means task 1 on cpu 0 wrote 111[ 0 ] then task 4 on cpu 1 wrote 444[ 1 ] etc.
3887The cpu numbering is an OS numbering of the cpus. 0, 1, 2, ...
3888
3889<p>From this you can see that there are 2 cpus, [ 0 ] and [ 1 ] and also 
3890that the interleaving is PERFECT. the 2 cpus perfectly alternate echoing.
3891Each time I press a key the next screen of text occurs. Because of the way it is 
3892written task changes happen very soon after the key is pressed so each screenful
3893tends to be a totally different pair of tasks.
3894Later on I keep the key permanently depressed. This text echo isnt ideal as it doesnt
3895use proper semaphores but uses hacked inefficient semaphores. Later I will
3896redo it with proper semaphores. All the tasks here are the same priority,
3897
3898<p>If I run this on the tower which is 1-cpu you will see just eg
3899111[ 0 ] 111[ 0 ] 111[ 0 ] 111[ 0 ], so you can tell how many cpus there are
3900by running this demo. Here is the <a href="uni.ASF">demo of the 1-cpu tower version</a>.
3901
3902<p><a name="20070704">============== 4th July 2007 ===============</a>
3903
3904<p>The debugging continues, I have just found a fairly major bug where
3905I forgot to check for some bit! I am just about to try that out now.
3906
3907<p>715pm: several bugs later and it still isnt functioning. I have just
3908now managed to locate one part of the problem.
3909
3910<p>840pm: made a lot of progress on the bug, not yet resolved.
3911
3912<p>10pm: looks like the central problem was a typo! The tower is now
3913correctly functioning, will try it on the laptop next.
3914
3915<p>1115pm: well, it is almost functioning now, still some further bugs.
3916On the 2-cpu laptop several tasks get launched and everything looks correct
3917but at some point only 1 ends up running. The other tasks are frozen out,
3918I'll continue working on this tomorrow.
3919
3920<p>340am: I put some debug code but that has affected the behaviour as
3921now each time on the laptop the 12 tasks pre-empt perfectly.
3922So there is a bug somewhere but it is a very precise bug.
3923
3924<p>With uniprocessor multitasking if task 1 echoes 111 111 111 ...
3925and task 2 echoes 222 222 222 then you get:
3926
3927<p>screen(s) of 111 111 111 and then screens of 222 222 222 ...
3928
3929<p>However with multiprocessor multitasking you get interleaved output:
3930111 222 111 222 111 222 as both cpus are SIMULTANEOUS.
3931The interleaving when I tried it out was PERFECT, with 12 tasks and 2 cpus
3932it is even more fascinating. I'll upload a video once I have debugged things
3933further.
3934
3935
3936<p><a name="20070703">============== 3rd July 2007 ===============</a>
3937
3938<p>I am continuing with the work towards pre-emptive multiprocessor multitasking.
3939This is a very complicated problem as there are a lot of potential coincidence bugs.
3940There is a problem of a system which functions most of the time but eventually
3941malfunctions.
3942
3943<p>615pm: I have just tried an attempt at the work, it malfunctioned.
3944Trying to find what the problem is. 
3945
3946<p>930pm: I am making some progress with the bug. The code malfunctions 
3947differently on the uniprocessor tower from the dual processor laptop.
3948Its going to take some time. Very complicated problem as there are 
3949multiple tasks on multiple cpus and the bug is with the entirety.
3950
3951
3952<p><a name="20070702">============== 2nd July 2007 ===============</a>
3953
3954<p>1245am: I have run my first pre-emptive multitasking code successfully
3955(after debugging). Just 2 tasks here, the one busy loop echoes "hello "
3956and the other busy loops "world ". Both echoing to the same space as 

3957there isnt any windowing yet. These are kernel tasks so this is 
3958pre-emptive kernel multitasking.
3959
3960<p>Further work to be done eg I havent yet implemented task exit,
3961currently tasks must NEVER exit. Various other things also not yet implemented.
3962But the semaphore subproject is complete, the multitasking subproject is 
3963almost complete. Enough implemented for the multitasking to function.
3964
3965<p>This is a fully 64 bit multiprocessor OS. The multitasking and semaphoring 
3966is fully multiprocessor and 64 bit but this initial multitasking only utilises one CPU.
3967Some further work before the multitasking utilises all the cpus.
3968This machine has 2 CPUs namely an AMD Turion X2 but the OS will run on
3969up to 256 CPUs which is the limit allowed by the x86 architecture.
3970
3971<p>Once the multiprocessor multitasking is fully functional I will 
3972upload a video of that as multiprocessor multitasking will look quite
3973different from uniprocessor multitasking.
3974
3975<p>440pm: I have tried running a dozen tasks, a number launched correctly but at
3976some point the system froze up. So I am debugging that, looks like a 
3977bug in the semaphore system.
3978
3979<p>Once there are many tasks then the complexity is severe and bugs are highly
3980likely.
3981
3982<p>Looks like if I delay before each new task is launched there is no problem,
3983so it seems to be a bug when tasks are launched immediately after each other.
3984On the tower system as I write this I have all 12 tasks running without problem
3985pre-emptively multitasking.
3986
3987<p>540pm: BUG RESOLVED! all 12 tasks now are running without problem 
3988without delayed launches. The bug was a register hidden in a macro which
3989hadnt gotten initialised because the initialisation had been conditionally
3990jumped. That register has now been unhidden and initialised and everything
3991is fine.
3992
3993<p>I think I will try this on the laptop and then begin making the 
3994multitasking multiprocessor. The entire architecture is multiprocessor
3995but there is a bit of further work before the multiprocessorness is 
3996complete.
3997
3998<p>6pm: its all fine on the laptop also, the laptop is dual cpu: AMD Turion X2.
3999
4000<p>I will take a break now and later begin completing the 64 bit multiprocessor
4001multitasking, should take a few hours to complete as the really difficult
4002stuff is all done.
4003
4004<p>940pm: it is proving to be more work than I thought,
4005
4006<p><a name="20070617">============== 17th June 2007 ===============</a>
4007
4008<p>There was a further bug, eventually I found it was a macro with a 
4009repeated argument name and the assembler hadnt detected that error. Once the 
4010arg name was changed then everything was alright.
4011
4012<p>Further in-depth testing of the subsystem appears to suggest that
4013everything is fine now. So that completes another subproject.
4014
4015<p>Some subsystems cannot be tested out except by actual use as they 
4016cannot be used in isolation.
4017
4018<p>I will continue now with other things,
4019
4020<p>330am: the work continues now ever forwards towards multitasking.
4021I have got several further things done already.
4022
4023
4024
4025
4026<p><a name="20070616">============== 16th June 2007 ===============</a>
4027
4028<p>The bug I was looking for yesterday is quite a major bug,
4029I am correcting that at the moment: quite a bit of work as it affects
4030a lot of things.
4031
4032<p>1215am: the bug is now resolved. Have done some very thorough testing
4033of the subsystem and the code is functioning correctly. I need to do some
4034further testing to be really sure. Probably will do that tomorrow.
4035
4036<p><a name="20070615">============== 15th June 2007 ===============</a>
4037
4038<p>I have been testing out a subsystem I wrote in a recent month
4039and it has a tricky bug, trying to locate the bug at the moment.
4040
4041<p><a name="20070614">============== 14th June 2007 ===============</a>
4042
4043<p>Working now on all the multitasking subprojects including the semaphores.
4044There are some very complicated theoretical problems, 
4045
4046<p><a name="20070613">============== 13th June 2007 ===============</a>
4047
4048<p>I have completed some architectural subphases towards multitasking,
4049these are running fine on the pre-multitasking system. They are features
4050which are Unix concepts, my OS is completely different from Unix but 
4051some Unix ideas such as these are definitive. Just as Xerox's concept
4052of windowing is definitive. All OS's have windows today but each OS 
4053does windowing differently.
4054
4055<p>There could be problems with these new features once the system is multitasking 
4056so there may be bugs which will manifest later.
4057
4058<p><a name="20070612">============== 12th June 2007 ===============</a>
4059
4060<p>Trying out some of the new code I have an impossible bug,
4061have spent a lot of time on it without success.
4062
4063<p>315am: the bug is resolved. Very very obscure problem,
4064
4065<p><a name="20070610">============== 10th June 2007 ===============</a>
4066
4067<p>The work now is getting very complicated and involves all the different
4068subprojects of multitasking including semaphores.
4069
4070<p>3am: the work is getting increasingly complicated. Working on very 
4071exciting parts of the architecture.
4072
4073<p><a name="20070608">============== 8th June 2007 ===============</a>
4074
4075<p>I have completed working through the code I was looking at. That is all
4076running correctly. I am now ready to begin on a major subphase of the project
4077towards multitasking, this next subphase is central supervisor level architecture.
4078
4079<p>930pm: I am working now on the next subphase, very gradual progress.
4080There are a lot of technical constraints now eg ensuring there arent conflicts
4081between different subsystems. This is the problem where you have the code you want

4082but cannot use it because it conflicts with the caller system.
4083eg the caller may have alignment constraints which arent adhered to.
4084
4085
4086<p><a name="20070604">============== 4-5th June 2007 ===============</a>
4087
4088<p>I am working my way through the code I did approx March-April,
4089there are many things I have figured out since then so I am making many 
4090improvements
4091
4092<p>5th June: have found some things I forgot to initialise, those things
4093arent referenced yet which is why they didnt lead to problems. Have been
4094stress testing some of the code also. Mainly this work is about carefully
4095reading the code which may or may not be correct. So it isnt the same as 
4096reading code which you know to be correct.
4097
4098
4099<p><a name="20070602">============== 2nd June 2007 ===============</a>
4100
4101<p>I have completed a major early phase of the work towards multitasking.
4102This code functions on both my machines. Most of the multitasking code doesnt function yet
4103and hasnt even been assembled. This phase includes the recent 
4104absolute time functionality but also is a lot of other things
4105and is about 6 weeks of work.
4106
4107<p>I will take a rest from computing and then begin on the next major
4108phase of work.
4109
4110<p>1130pm: well I am continuing now with the next major phase of work. This in
4111fact continues a subproject I was working on end of March beginning of April.
4112I tried running the code I was working on then and it malfunctioned.
4113I found the bug, it was an incorrect stack. There may be further bugs,
4114
4115
4116<p><a name="20070531">============== 31st May 2007 ===============</a>
4117
4118<p>I have got a lot done on absolute time functionality. By absolute
4119time I mean say 31st May 2007 03:55:28 or delaying by 2 seconds.
4120
4121<p>ie synchronising with the time you see on your watch. There are a lot
4122of complicating factors. The central problem with time is that if you 
4123try to measure it, it continues moving forwards while you are thinking 
4124what to do. Furthermore while thinking an earlier delay may now have
4125elapsed. So the problem is that time doesnt wait, it just continues 
4126on and there is a problem of catch-up!
4127
4128<p>I have basically got completed some important steps towards full functionality.
4129Full functionality wont be there for some time.
4130
4131
4132<p><a name="20070525">============== 25th May 2007 ===============</a>
4133
4134<p>I am making progress now with time, continuing with the time work 
4135I began many months ago mentioned at the end of the web page.
4136I have completed another phase of bootstrapping time. As mentioned 
4137recently some time functionality my work was depending on doesnt
4138seem to function on my laptop so I had to workaround that.
4139
4140<p>I now build my OS using old fashioned MSDOS scripts!
4141
4142<p>Although I criticise MS I like some of their things eg their
4143script system is very direct. It seems to decide that a file is a
4144script file if it is ???.bat and you can put ordinary commands in that.
4145It also deals with variable script args.
4146
4147<p><a name="20070524">============== 24th May 2007 ===============</a>
4148
4149<p>Some time functionality I require doesnt function on the laptop,
4150however other time functionality is functioning so I am creating a workaround
4151via that. 
4152
4153<p>later: running into further time problems, trying out some new time things
4154the tower system now malfunctions. This is using legacy 1980s hardware.
4155
4156<p><a name="20070523">============== 23rd May 2007 ===============</a>
4157
4158<p>Work continues with integrated time delays. There seems to be problems
4159with time and date with the laptop. I am trying to get that to function.
4160The same code is fine on the tower system.
4161
4162<p><a name="20070521">============== 21st - 22nd May 2007 ===============</a>
4163
4164<p>At the moment I am working on a lot of technical matters, 
4165there is an unavoidable problem within one of the subsystems needed for
4166semaphores and I am working around that problem at the moment. The workaround
4167is complicated. I am working also on delay functionality,
4168delay is actually part of the architecture and complicates the design.
4169
4170<p><a name="20070513">============== 13th May 2007 ===============</a>
4171
4172<p>Recently not many updates as I was away from the internet. I have got some
4173major multitasking functionality implemented. I have only done a small amount of further
4174work on the semaphore subproject. I got digressed into a different subproject of 
4175implementing multitasking, something which the semaphores will depend on. That itself
4176was major work.
4177
4178<p><a name="20070416">============== 16th April 2007 ===============</a>
4179
4180<p>The problems now are getting really impossible. Whichever way I try to do 
4181things I reach an impossibility!
4182
4183<p>I am making gradual progress now, eg there was some code which was only 
4184ok if there was no multitasking. I could change that code (A) to be alright 
4185if there was multitasking but that depended on something initialised (1) later.
4186I got around that by moving the initialisation earlier. But that initialisation
4187depended on an ABI which wasnt yet initialised. I dealt with that by temporarily
4188initialising (2) the ABI and then deinitialising it. At that point the system

4189depends on a different ABI. With 68k you probably just need 1 ABI, but 
4190x86 is unusual and you need different ABIs. Later on some code assumed 
4191the initialisation hadnt been done and that needed changing as it now was
4192dependent on the initialisation (1).
4193
4194<p>I have made those changes but not yet changed the code at (A). The changes
4195at (A) need to function also before multitasking starts. That was another
4196complicating factor. I found a way to do it which isnt yet implemented.
4197
4198<p>Such problems are very impenetrable because a different way would have
4199led to totally different problems.
4200
4201<p>Some of the alternatives I looked at I couldnt see how to run the
4202system with. There was an unresolvable circular dependency where one way 
4203out was to remove some features! Unfortunately those features really were
4204necessary, eventually I found a different way.
4205
4206<p>I have tried the above changes with the existing non multitasking system
4207and it runs correctly. If there was any error at all the system would freeze 
4208up or reset depending on its mood. 
4209
4210<p>145am: I have got some of the code towards (A) implemented. I have 
4211got this debugged now for the non multitasking situation. There is quite a
4212lot to change. Changing the code is straightforward, but I need to do this
4213in batches in case of bugs: I make a backup before each batch and then 
4214try that out in the non multitasking case. There was a bug where the text
4215output was freezing up because of an interaction. Trying out the code
4216so far I can see the idea is good. I havent yet tried the code on the laptop,
4217so I'll try that next.
4218
4219<p>330am: HAHAHA! I found there is a much better way of doing this,
4220I can do (A) with much less coding. Luckily I made backups so I will revert
4221SOME of the files, other changes are fine. The bug above is in code
4222which will be kept.
4223
4224<p>17th april: the new approach mentioned above has to be done more carefully
4225but is less coding. Today I was optimising some of the changes. One ongoing
4226problem with the current work is that any change at all to any of it 
4227can affect everything else. eg some changes mean that a lot of the other 
4228code becomes garbage. It is very difficult to create a system which in totality
4229is alright. Each time I read through the new work a lot of the stuff is 
4230now garbage. It is like one of those 3D puzzles where you have different
4231irregular shapes which you have to connect up into a regular shape,
4232if anything at all isnt right the entirety disintegrates. As you use one
4233of the shapes you then find it obstructs another shape.
4234Or a rubiks cube where if you move anything a lot of other unintended stuff also moves.
4235A LOT of effort is required to move everything into place with a rubiks cube.
4236
4237<p>The other problem is that everything is so arbitrary, there are no rules
4238and so many different ways to do things, alternatively sometimes there doesnt
4239seem to be any way to do something.
4240
4241<p>The reason this code is so tricky is firstly that this is coding 
4242tricky hardware: totally asynchronous, secondly that the thing being
4243implemented is very tricky: pre-emptive multitasking s/w + kernel, thirdly 
4244that this is the substratum of all software. When you read this page on a 
4245browser, the browser runs above an OS. At the centre of that OS is 
4246material comparable to what I am synthesizing here.
4247
4248
4249<p><a name="20070415">============== 15th April 2007 ===============</a>
4250
4251<p>I wasted a lot of time trying out some code, it was 2 very difficult to 
4252see bugs, one was a loop where I forgot to put the jmp statement at the end of the loop,
4253the other was that 2 variables were very similarly named and I used the wrong one in a 
4254statement. Both are like the "Paris in the the spring" optical illusion where the first "the"
4255is at the end of a line and the second "the" at the start of the next line
4256and you dont see there are 2 "the"s. I read through the
4257code again and again and could not see the problem.
4258
4259
4260<p>The multitasking project is reaching complexity meltdown, each thing I look 
4261at requires ever more work, subproject proliferation,
4262the workload is increasing much faster than the work!
4263One way to deal with this is to leave things out of the design.
4264Eg some features have a time cost, this leads to project definition questions.
4265eg is the project about speed or about features. My project is ultimately 
4266somewhere in the middle. I want speed but I also want features.
4267I have to make some difficult decisions as to what the system will be.
4268
4269<p>A very important part of design is deciding what a system WONT do.
4270Good design is often about what a system DOESNT do, eg an example of good
4271design is AmigaOS not utilising fork() or Modula not using macros.
4272Just because Unix does something doesnt mean its any use!
4273
4274
4275<p><a name="20070414">============== 14th April 2007 ===============</a>
4276
4277<p>

4277Today I found a disadvantage of the current semaphore code,
4278I am busy working on this problem currently. It is very tricky.
4279The idea I am trying may even be impossible, I havent determined that,
4280if it appears impossible I can try a different idea which I think 
4281is possible but not quite as good.
4282
4283
4284<p><a name="20070413">============== 13th April 2007 ===============</a>
4285
4286<p>I have made a lot of progess towards semaphores. Got some very tricky
4287things implemented, this is the twilight zone of computer science. 
4288(twilight zone==television series here! a place where the normal rules
4289dont apply)
4290
4291<p>I am taking a break now from the semaphores and am doing further work 
4292on the memory architecture. Ironically first attempt to upload this froze
4293up WinUAE!
4294
4295<p>With such things there are 2 bugs which can happen: freeze ups and 
4296tasks vanishing! I have to study the code very carefully for such problems.
4297There are so many different interactions that some wierd problems can happen.
4298
4299<p>The current memory architecture work is very interesting,
4300this work is deep within the architecture and depends on months 
4301of work: implementing some cool features.
4302
4303<p><a name="20070411">============== 11th April 2007 ===============</a>
4304
4305<p>Very busy, gradual progress. Much underway. Progress good, progress slow,
4306progress difficult.
4307
4308<p>I give here using pseudo 68k asm an illustration of semaphore problems:
4309
4310<p>simple semaphores can be done thus:
4311
4312<p><pre>
4313xyz:  tas.b m
4314      bnz xyz
4315
4316exclusive_code
4317...
4318
4319      move.b #0, m
4320
4321...
4322m db 0
4323</pre>
4324
4325<p>tas tests m before setting the top bit. Here a task keeps setting 
4326the top bit of m until that results in a 
4327change. bnz means the bit was already set so try again. The top bit
4328signifies the semaphore is BUSY. instructions such
4329as tas were invented entirely for implementing semaphores.
4330
4331<p>That means only 1 task can execute exclusive_code. However there is 
4332a problem: if a higher priority task now pre-empts the task and also 
4333tries to lock the semaphore both tasks will freeze up. The reason is 
4334that the higher priority task loops forever at xyz: and the lower priority
4335one being of lower priority is kept from continuing to eventually free
4336the semaphore. So the higher priority one loops forever on the semaphore and the 
4337lower priority one waits forever for the cpu. Here the semaphore is logically correct
4338it achieves exclusion, but the design is bugged as the system freezes up.
4339Thats an unusual problem because nothing has crashed.
4340
4341<p>Most of the time though the above is fine. Its a 1 percenter, the bug
4342only happens 1% of the time. AmigaOS dealt with this
4343by not using semaphores but switching off multitasking via Forbid() and
4344Permit():
4345
4346<p><pre>
4347call_forbid
4348exclusive_code
4349call_permit
4350</pre>
4351
4352<p>which was optimal for how they did things, 
4353but in general has problems eg it
4354is insecure as a prog can freeze the OS via:
4355
4356<p><pre>
4357call_forbid
4358rpt:  jmp rpt
4359call_permit
4360</pre>
4361
4362<p>One way out is the Microsoft XP idea of "program not responding". 
4363Essentially give forbid a timeout, so the OS can only freeze up temporarily.
4364 The discussion is reaching a point where truth becomes relative.
4365An idea is good on one OS and bad on another. AmigaOS recognised that
4366semaphores were necessary and supplied them with AmigaOS 2.0. The 
4367AmigaOS 1.0 RKM by Sassenrath says to use message ports for semaphores.
4368That probably is efficient but eg has the problem that it requires an
4369auxiliary task. Either way the design is becoming complex as semaphores
4370now depend on message ports and require a protocol. Auxiliary tasks
4371are the way for doing certain things, AFA doing semaphores you 
4372have to be careful about the auxiliary task depending on semaphores
4373as that is what it is trying to implement.
4374
4375
4376<p>Whichever way you go, things get complicated, especially if you 
4377want to design a good system. Even if the system is correct you can
4378then get user level bugs.
4379
4380<p>My architecture is completely different, the semaphores will be
4381completely integrated into the design. They co-depend on many other
4382things. I could design the architecture differently so that semaphores
4383arent integrated, but that has its own problem consequences.
4384
4385<p>It has taken about a year of coding before I can even think about
4386semaphores. So it is like installing lighting in an aeroplane,
4387you first have to make the plane! The lighting depends on the power supply,

4388but the aeroplane control mechanisms also depend on that. You have to 
4389make sure there is enough power for the entire journey.
4390
4391<p>Once multitasking is functioning then I really have an OS, before
4392that it is more of a precursor. Even when multitasking is implemented 
4393it will be months before it is fully functional, eg the initial multitasking
4394cannot access hardware.
4395
4396<p>When the multitasking is functioning I will eventually upload a video
4397of it. Same legacy graphics as the existing video but multitasking,
4398the graphics will be 1980 but the multitasking will be 2010.
4399
4400
4401
4402
4403<p><a name="20070409">============== 9th April 2007 ===============</a>
4404
4405<p>9pm I have completed coding the component mentioned on the 6th.
4406The work was neverending but I have completed it now. I havent assembled
4407it yet. The code is very complicated and bug prone, but it will be 
4408very heavily used so any bugs should soon manifest. The code has been
4409carefully written to avoid various dependencies which could be used.
4410Those dependencies are avoided to avoid circularity: there is a 
4411danger of design bugs where the OS freezes up because something 
4412is circularly self dependent.
4413
4414<p>The semaphore subproject is still at an early stage,
4415so the above component is a first step of many towards multitasking.
4416
4417
4418
4419<p><a name="20070406">============== 6th April 2007 ===============</a>
4420
4421<p>I am making very gradual progress towards multitasking,
4422
4423<p>950pm: I have just completed coding one subcomponent of one component
4424of the architecture. I havent tried compiling it yet, 
4425
4426<p>later: at least I thought I had completed it, have found several
4427complicating factors. so I am still working on that.
4428
4429
4430
4431<p><a name="20070401">============== 1st April 2007 ===============</a>
4432
4433<p>4pm: All the different subprojects of multitasking are now merging into 
4434one project. so I am now working on all the subprojects simultaneously,
4435some things involve one topic or feature, others another. None will be 
4436complete until all are complete. All the features are being fully integrated.
4437
4438<p>Full integration means that you wont have to implement things by 
4439hacked workarounds, instead the things will already be there designed into
4440the system. And there are no workarounds, everything is harmonious.
4441
4442<p>Anyway, returning to semaphores those wont be complete until everything
4443else is, there is a lot of further work before anything completes.
4444
4445
4446<p><a name="20070331">============== 31th March 2007 ===============</a>
4447
4448<p>The semaphore work continues, it is very stressful work. Things are 
4449gradually progressing. Its a very interesting problem, there are very 
4450complicated bugs that can happen.
4451
4452<p>tautologically I wont be able to test out the semaphores until after
4453multitasking itself is implemented. semaphores are an integral component
4454of my multitasking architecture: my OS cannot function without them.
4455
4456
4457
4458<p><a name="20070330">============== 30th March 2007 ===============</a>
4459
4460<p>Finding a lot of theoretical problems, some of the existing code wont
4461cope with these so I am having to redo various things.
4462
4463<p>As I progress towards multitasking the problems get increasingly difficult.
4464
4465<p>I am working on semaphores at the moment...
4466
4467<p>semaphores are very tricky, looks like another phase or subproject...
4468
4469<p>semaphores are inextricably linked to multitasking, the 2 problems are
4470inseperable. So the semaphores will be designed and implemented in tandem
4471with multitasking in general. Very difficult to be sure there are no bugs
4472with the mechanism.
4473
4474<p><a name="20070329">============== 29th March 2007 ===============</a>
4475
4476<p>I am working on further memory architecture work, I had an interesting
4477crash because I forgot that x86 stacks start at the far end.
4478
4479<p><a name="20070328">============== 28th March 2007 ===============</a>
4480
4481<p>I am working on a very difficult component of the multitasking architecture.
4482This is supervisor level work. This component is the beginning of a new
4483phase towards multitasking. The component has to deal with many different 
4484problems. Also the kernel is pre-emptive which complicates things further.
4485AmigaOS was the first pre-emptive kernel.
4486
4487<p><a name="20070325">============== 25th March 2007 ===============</a>
4488
4489<p>Last thing yesterday I realised there was a better way of dealing 

4490with several x86 specific memory constraints. Several different
4491workaround mechanisms could be replaced by 1 general scheme which also allows
4492me to deal with new constraints or remove existing constraints
4493by changing build parameters.
4494
4495
4496<p>I have completed implementing that and it seems to be functioning fine.
4497The new code is much easier to maintain.
4498
4499<p>When I make extensive changes I always backup the preceding system 
4500first in case the new work runs into problems.
4501
4502<p>I am ready now to begin the next phase of work towards multitasking,
4503this is further memory architecture work.
4504
4505<p>1am: I am currently doing some low level reconfiguring of the hardware 
4506required by the plan. Without the reconfiguring the system will not function.
4507
4508<p>later: I've been trying out the code so far, x86 is doing something different
4509from what I thought, so I have to figure a way around that.
4510
4511
4512<p><a name="20070324">============== 24th March 2007 ===============</a>
4513
4514<p>I have been trying out the code so far. This has a bug which I am
4515working on at the moment.
4516
4517<p>1025pm: that bug is resolved, I forgot to set some field. Fine on 
4518the tower, I am about to try it on the laptop. (later: that went fine).
4519
4520<p>Before continuing I need to make some improvements to the existing code.
4521
4522<p>530am: I have made a lot of improvements to the existing memory architecture
4523(and several bugs getting there). Some of the improvements are x86 specific
4524and some are general. Some of the x86 specific optimisations can probably be ported
4525to specific requirements of other cpus. (would need to be redone in C first).
4526The code avoids hard wired assumptions. There is a lot of further work 
4527to be done on the memory architecture.
4528
4529<p><a name="20070320">============== 20th March 2007 ===============</a>
4530
4531<p>I am right at the centre of the OS now, centre of the multitasking.
4532A lot of further work before the multitasking will function.
4533This is the most difficult part of the whole project.
4534The code is still unitasking eg the recent video is unitasking.
4535
4536<p>No graphics at all yet, just the legacy ascii graphics. If you are
4537very observant you will see that the snapshot of the laptop has slightly
4538different fonts from the video of the tower. The 2 mobos have implemented
4539the same fonts slightly differently. eg the 0's are different.
4540I have the graphics hardware under control but that code isnt integrated into the
4541OS. So if you were hoping to see some windowing in the video, there isnt
4542any. It hasnt even been coded yet! The graphics system will use the CPU as a GPU.
4543
4544<p>The OS so far is completely written in x86 asm. At some point I will
4545start using C, and some of the existing code will be redone in C.
4546But a lot of things have to be done in asm. 
4547
4548<p>The initial multitasking will have many features but wont be fully featured
4549till later. The multitasking will gradually become fully featured. The 
4550full feature set is too complex to implement in one go, it will be arrived
4551at in phases. The later features are designed in right at the start but
4552implemented later. To reach multitasking is itself a major bootstrap 
4553consisting of many subprojects. eg the lowest level of the memory system took 
4554approx a month to develop. The higher levels of the memory system are still being
4555developed ongoingly. 
4556
4557<p>As an example the initial multitasking wont have access to any hardware
4558except to echo legacy text to the screen as in that video. Task level access to
4559hardware is major work.
4560
4561<p>I see Vista is now in the shops, I'm not at all worried about Vista 
4562though I will eventually try out Vista to evaluate it. Microsoft wont
4563wait for any competitor! Their presentation is full of smiling dancing 
4564young actors pretending to be Vista users. with oiled teeth and ants in their
4565shoes. They certainly know how to market 
4566thats for sure.
4567
4568<p>But if you switch on your television and watch the adverts you will
4569see that all companies hugely hype their wares with actors pretending
4570to be customers.
4571
4572
4573<p><a name="20070318">============== 18th March 2007 ===============</a>
4574
4575<p>At the top of the webpage is a photo after the OS has echoed the
4576first sector of the HD via a 28-bit sector number DMA ATA read.
4577
4578<p>I'll try and upload a video of a subset of the code in action.
4579I will only show a small enough subset that doesnt reveal too much of
4580the gameplan. Currently the graphics is entirely legacy hardware 16 colour
4581ascii 80x25 text. (IIRC it is 16 colour, something low anyhow).
4582
4583<p>You will notice the numbers are different from those mentioned on
45845th March, that is because those are for the tower and these are for
4585the laptop.
4586
4587<p>I have now made a video of my IDE DMA code in action, 
4588<a href="video.ASF">DOWNLOAD THE VIDEO</a>
4589
4590<p>The video shows some HD query code then reading the first sector.
4591After that I press some keys which appear and move the mouse + press

4592and release buttons. The mouse coordinates are echoed and the button
4593changes are echoed. I press the left button down, right down, left up,
4594right up. This is for my tower system and you will see the numbers
4595are those mentioned on 5th March.
4596
4597<p>Although the graphics is still very primitive I guarantee that
4598the OS underway is very advanced.
4599
4600<p>Most of the work isnt visible, the visible stuff is the tip of the
4601iceberg. Right now I am working on some really tricky code towards
4602multitasking. This sub project gets increasingly difficult as it
4603proceeds.
4604
4605<p><a name="20070315">============== 15th March 2007 ===============</a>
4606
4607<p>I am coding one of the phases towards multitasking, this code has to 
4608deal with various future features such as security, task removal, fork() 
4609and others. Security is preventing things like viruses, spyware etc.
4610
4611<p>The security architecture is entirely my own design and is not based
4612in any way on any other system. Security is a very far reaching topic.
4613The security design is ongoing work and consists of different phases 
4614each of which is a subproject. The initial phase I am coding now 
4615and was arrived at over recent months.
4616
4617<p>The reason Windows has hundreds of viruses and other malware is
4618because it is a mainframe OS which was never intended for PCs.
4619Bill Gates paid the chief programmer of VMS to reimplement it on 
4620PC's. Windows has painted itself into a corner surrounded by viruses.
4621viruses are at the centre of the design of Windows.
4622
4623<p>My OS is not a reimplementation, the entire design is brand new 
4624and as such I avoid all the problems of all the mainstream OS's.
4625
4626<p><a name="20070313">============== 13th March 2007 ===============</a>
4627
4628<p>Major work is now underway working towards multitasking.
4629This is a brand new architecture with major features eg security,
4630crash protection, clean task removal, pre-emptive kernel, fork() (as far as is
4631feasible), and many others.
4632The OS design will be as good as any on the market, the 3 comparison 
4633OS's are 68k-AmigaOS, Unix and Windows. Of the competitors AmigaOS has the cleanest 
4634and most efficient design, Unix probably has the most features of these 3 
4635and is the least usable. Windows has the most attention and is certainly the most 

4636aggressively developed. However an Amiga 1200 outdoes say XP in many ways,
4637AmigaOS is a much more general design eg AmigaOS is the most asynchronous 
4638OS ever created even today. AmigaOS has the most advanced windowing architecture,
4639Windows windowing has useful features but the actual architecture has many 
4640limits.
4641
4642<p>Because there are so many deep level features the work is quite severe.
4643Some of the features will be worked on later. Remember I am attempting to 
4644outdo Unix which has stood the test of time since the 1970s. AmigaOS also
4645has stood the test of time of 20 years. AFAIK Windows is a reimplementation
4646of a mainframe OS called VMS, the disadvantage of that is a PC is a totally
4647different hardware paradigm from a mainframe. Its also why Windows is so 
4648severely complicated. Unix is also really a mainframe OS thats why it has
4649the user-group-other file protection flags. A Unix system will have say 
4650200 users who login through terminals, 5 of those users might be a team
4651working on some project and their shared files will be group readable.
4652A file is group writable if anyone in the team can modify the file,
4653the filesystem creates an exclusive write lock so that 2 people cannot 
4654write the file at the same time.
4655
4656<p>Windows 95 made the astonishing assertion that it was a man century of work
4657my project will prove that is false.
4658
4659<p>programmers will be discouraged from using fork(), instead there will
4660be other ways for user programs to multitask. Example problem with fork()
4661is if a program is writing a CD-R and right in the middle of that does
4662fork(), 2 programs are now writing the same CD-R which is clearly 
4663a problem.
4664
4665<p>you wont be able to interfere with the OS like you can on AmigaOS,
4666AmigaOS is unique in that respect. advantage: users can customise the OS,
4667disadvantage: so can viruses.
4668
4669
4670<p><a name="20070309">============== 9th March 2007 ===============</a>
4671
4672<p>I've completed writing and debugging a very initial batch of code
4673towards major OS functionality,
4674
4675<p><a name="20070306">============== 6th March 2007 ===============</a>
4676
4677<p>Doing a lot of coding now, major stuff.
4678
4679<p>It may not be clear what the recent PATA info was about:
4680what I achieved was making the PATA code BIOS independent, ie 
4681it now doesnt use the BIOS: thats an improvement to the system.
4682See <a href="#A">(A)</a> in the project summary and <a href="#B">(B)</a> also.
4683
4684<p><a name="20070305">============== 5th March 2007 ===============</a>
4685
4686<p>further to yesterday, I was going to implement 28 bit sector numbers for
4687PATA but as I started on this I realised I must have already implemented it.
4688Reading the code more carefully I found it was already done: 
4689I had implemented 28 bit DMA but NOT 28 bit polled code. The code I was
4690trying yesterday was in fact polled 48 bit code. Literally 4 lines of 
4691code later and the tower 28 bit is reading sector 0 correctly. Its on 
4692the other screen right now, the last 18 bytes being:
4693
4694<p><pre>
469500 00 c1 ff 07 ef ff ff 40 94 45 04 c0 11 0b 05 55 aa
4696</pre>
4697
4698<p>If you know enough about PC's you can figure out from that some info
4699about the partitions. eg the 5th byte along is 07 which would appear to 
4700mean that the 4th top level partition is NTFS. The 4 bytes before 55aa
4701tell you the partition size, 050b11c0 which is about 5 x 2^24 x 2^9 bytes
4702ie 5 x 2^33 = 40 x 2^30 = 40G, and XP says 40.35GB. which is about half of
4703the drive. This type of interpretation is important to determine if 
4704hardware code is correct. 
4705
4706
4707<p>I know the read is correct if it ends in 55 aa as that is the signature
4708of sector 0 on PC's. 
4709
4710<p>I am continuing now with the main OS work towards major functionality.
4711Implementing the OS features people wish for in forums!
4712
4713<p>If you dont like what I am doing please email me and say why,
4714
4715<p><a name="20070304">============== 4th March 2007 ===============</a>
4716
4717<p>I have been revisiting the PATA HD code. I want to make the 
4718HD code fully BIOS independent. It was only some time after I had written
4719the code that I figured out how to remove the BIOS dependencies.
4720I didnt do that then as there were various complicating factors.
4721
4722<p>Anyway I have enough things now under control that I can 
4723make the HD code BIOS independent. I have been working on that and
4724have now completed that code, but there are 2 problems: the tower system is reading the 
4725first sector but the bytes dont look correct. The laptop HD initialisation
4726doesnt directly function, I know why and am working on that right now.
4727Once it functions I will see whether it reads the correct bytes.
4728
4729<p>As regards fork() it seems the function is not intended for the more
4730general situations I was considering.
4731
4732<p>later: both HD problems are now explained: the tower system currently
4733uses an 80G HD which doesnt support 48-bit sector numbers. The current
4734code just uses 48-bit sector numbers, so the read there was a no-op.
4735The laptop HD needed to be reconfigured, it then did read sector 0 correctly.
4736I know if the read is correct because sector 0 on a PC HD should end in 
4737the bytes 55, aa.
4738
4739<p>I think I have already written somewhere 28-bit sector number code,
4740looks like I'll need to get that functioning in order to be able to 
4741test out code on the tower. This isnt urgent, main thing is the 48 bit
4742code is correct. 28-bit sectors gets you up to 2^28 * 2^9 == 2^37 ==128G bytes.
4743Drives bigger than 128G should therefore support 48-bit.
4744
4745<p>when the laptop floppy takes ages reading, I try to music conduct the
4746floppy drive sounds. The sound of machines is a form of music, eg 
4747musical instruments are themselves machines. People and animals are
4748also machines, eg horse drawn carriages and police dogs.
4749
4750<p>even later: looks like I probably havent implemented 28 bit sector
4751number code. I have been working on so many subprojects that I have
4752lost track of exactly what I have or havent implemented. I sometimes
4753find things I forgot I had implemented. I think at
4754the time I wasnt so interested in laptops as 28 bit is more for
4755laptops with 80G drives. Its on my todo list then to implement 28 bit.
4756ironically this laptop has a 48 bit drive (120G) and the tower has a 28 bit one.
4757That's because I decided to go for a smaller system HD for the tower so
4758I could move my stuff between computers by recabling. OTOH I went for
4759a big laptop drive as it is inconvenient to use external drives on a laptop.
4760Now that I've learnt how cool laptops are I will ensure my system 
4761runs on modern laptops with 28 bit or higher drives. 
4762
4763<p>The HD code more generally will require a lot of further work,
4764
4765
4766
4767<p><a name="20070302">============== 2nd March 2007 ===============</a>
4768
4769<p>I have been studying fork() to see if I should make my OS 
4770fork() compatible.
4771
4772<p>I never use fork() myself. AmigaOS's CreateTask() is a much better 
4773function. fork() is only necessary if you want to port Unix progs to
4774your system. fork() isnt recommended.
4775
4776<p>Having fork() compatibility is a severe design constraint as 
4777you literally have to design the whole system to allow fork() to
4778be possible. For the moment I wont decide and will just 
4779see what the consequences are.
4780
4781<p>fork() is certainly an interesting idea, it is the thing of the universe
4782splitting into 2 paths eg the one path you bought an Amiga and 
4783the other you bought an Atari ST. However being interesting 
4784doesnt make it good programming, making an optical mouse the size of a 
4785car is interesting but not practical engineering unless Gulliver is
4786on his way. eg if the universe can split into 2 paths that hugely increases
4787the dimensionality of the universe which makes it more difficult
4788to implement. interdimensional memory isnt cheap...
4789
4790<p>Note that I dont yet have multitasking, fork() is being looked at

4791as that constrains the entire OS design. To see the severity of fork()
4792think of UAE as a program above Unix, what happens if you put a fork() statement? 
4793
4794<p>UAE should then split into 2 UAEs, but how exactly? eg 
4795what happens to the interactions with the hardware? 
4796
4797
4798
4799<p>Ultimately the objective is
4800to create a good system, and if fork() gets in the way of that objective
4801it will be removed as a constraint.
4802
4803<p>Trying out some code there was a bug with fantastic consequences,
4804I put a line of asm in the wrong place and there were fantastic
4805colour effects, much more interesting than the usual correct code!
4806
4807<p>The colour effects are on the other screen right now,
4808
4809<p><a name="20070228">============== 28th Feb 2007 ===============</a>
4810
4811<p>I have got several low level hardware things done today. As I write this
4812I have some code running on the other screen.
4813
4814<p>things are progressing very well,
4815
4816<p>The code above eventually reset the machine which was a bug,
4817various further changes and the code seems to be alright. I have the newer
4818code now running on the other screen. I'll finish the session by trying
4819the same code on the laptop.
4820
4821<p>Some things are slightly different on the laptop, this is where betatesting
4822is necessary. However it is much too early for betatesting. 
4823
4824
4825<p><a name="20070226">============== 26th-27th Feb 2007 ===============</a>
4826
4827<p>I've got some very initial code now functioning. The bugs mentioned 
4828below have been resolved, took a lot of work to do. I have made some
4829improvements also to the supervisor level of the OS. A long standing inelegance
4830has been smoothed.
4831
4832<p>This is a very initial step towards the app level of the OS.
4833
4834<p>I've also improved my work desk! I now have the tower monitor to the
4835right of the laptop so I can I have both machines in view simultaneously:
4836with the "OS" on the right monitor and the source code asm on the left monitor!
4837
4838<p>One unusual thing is these 2 machines use different hardware fonts,
4839the monitor on the right has 0's with a dot in the middle whereas the
4840left monitor has 0's with a diagonal line.
4841
4842<p>27th: I have improved the mouse code (that was on my TODO list
4843for many months). The mouse code is not yet app level, I will work on 
4844that later. I will continue now with the app level of the OS.
4845
4846<p>The work now is very difficult, so at the moment I'm not doing any
4847coding but am studying the problems. At some point soon I probably 
4848need to resume work on the compiler so that the further development
4849of the OS can be done in C.
4850
4851
4852<p><a name="20070222">============== 22nd-26th Feb 2007 ===============</a>
4853
4854<p>Working on very difficult OS architectural problems...
4855
4856<p>23.feb: found a very complicated harmless bug.
4857
4858<p>If you want more specific info on what I am doing and why, email me with a 
4859specific or general question,
4860
4861<p>I can give more info in an email than on the website.
4862
4863<p>24.feb: I'm doing gruntwork programming for some interesting new
4864functionality. This is very initial work on the app level of the OS.
4865And yes it will be a pre-emptive multitasking OS,
4866
4867<p>25.feb: there's a bug now in the debug code!
4868
4869<p>26.feb: several bugs actually. I've got some of them resolved now,
4870involved some supervisor level coding.
4871
4872<p><a name="20070221">============== 21st Feb 2007 ===============</a>
4873
4874<p>I am making gradual progress on the hardware subproject. I'll get a bit
4875more done and then resume work on the OS:  the next steps with the OS 
4876are quite major things,
4877
4878<p>When I say "hardware" I actually mean software!
4879
4880<p>Note that a lot of actual hardware is itself software eg x86 is 
4881in fact software above a RISC core.
4882 Years ago someone made an interesting 
4883remark that "hardware is software".
4884
4885
4886
4887<p><a name="20070218">============== 18th Feb 2007 ===============</a>
4888
4889<p>I've just tried for the first time the OS ported to the laptop back
4890on the tower system and it functioned fine first time. This will greatly
4891speed up progress as I can now develop on the laptop but test the work
4892on the tower.
4893
4894<p>I am working on the first steps of a hardware subproject.
4895
4896
4897<p><a name="20070216">============== 16th Feb 2007 ===============</a>
4898
4899<p>First update for a month, in that time I have bought a cool laptop 
4900and have ported my OS project fully to the laptop. All bugs mentioned in 
4901previous updates have now been resolved: there were many bugs and some
4902really tricky x86 asm problems.
4903
4904<p>Not only have I ported the OS to the laptop but I am working on 
4905a lot of new things on the laptop. 
4906
4907
4908
4909<p><a name="20070115">============== 15-16th Jan 2007 ===============</a>
4910
4911<p>right at the end of the day I've found a function in the boot code
4912which contains several bugs some of which directly relate to the supervisor
4913level bug. The code looks correct but it isnt. It took some work to determine
4914that it wasnt correct.
4915
4916<p>I'll try to correct the function tomorrow.
4917
4918<p>I am buying a laptop now so I can continue my projects when I dont
4919have access to my tower system. I will probably try and get the code 
4920running on the laptop though that is trickier as laptops dont leave
4921much room to manoevre.
4922
4923<p>16th jan 7pm: 
4924I am working on the problem. This code is 16 bit asm which is very fiddly.
4925The bug happened because I was trying out new assembler features and 
4926no problem manifested at the time.
4927
4928<p>I have found now the cause of a lot of the problems.
4929<p>11pm: I've corrected the function but the problem still manifests.
4930I have to continue this tomorrow.
4931
4932<p><a name="20070114">============== 14th Jan 2007 ===============</a>
4933
4934<p>Now I've completed the port to 68k-AmigaOS of AFPL Ghostscript 8.54 
4935I am restarting work on the supervisor bug mentioned below. It is an x86
4936specific problem. I only have a few days of time window so I will focus 
4937mainly on this bug.
4938
4939<p><a name="20061129">============== 29th November 2006 ===============</a>
4940
4941<p>2am: I didnt get too much done today (Tuesday) as I had various non 
4942computing things to do. I have made a small amount of further progress on 
4943the supervisor bug. I now understand generally what the problem is but it 
4944will take some work to resolve it. I wont get much done tomorrow (Wednesday)
4945either.
4946
4947
4948
4949<p><a name="20061128">============== 28th November 2006 ===============</a>
4950
4951<p>I realised some enhancement that would improve the early compiler phases,
4952so I decided to implement that before I forgot. The enhancement is implemented
4953now and seems to be functioning fine.
4954
4955<p>I am continuing with the supervisor level bug. This is a very complicated bug
4956and I need to resolve it in order to continue the OS bootstrap.
4957
4958<p>8am: I have made a certain amount of progress with the bug. Not fully there
4959yet as there is some further inexplicable crashing.
4960
4961
4962<p><a name="20061126">

4962============== 26th November 2006 ===============</a>
4963
4964<p>The supervisor level bug I'm looking at is very tricky. I am making some
4965progress on the problem, however it isnt resolved yet.
4966
4967
4968<p><a name="200611252">============== 25th November 2006 ===============</a>
4969
4970<p>As the C pre processor subproject is complete I have moved that info to 
4971the project summary at the end of the webpage. Thats another chapter of the
4972project complete.
4973
4974<p>I am now working on the supervisor level OS bug I was looking at on 17th October.
4975
4976<p>I will take a holiday from computing in December. I will begin on the 
4977C compiler in 2007.
4978
4979
4980<p><a name="200609212">============== 21st September 2006 ===============</a>
4981
4982<p>The low level OS component is now fully debugged.
4983All tests are running correctly. So I regard this subproject as complete.
4984Perhaps there are undetected bugs these will be worked on as and when I find them.
4985
4986<p>I have thus completed 2 immensely powerful subsystems: 
4987the low level OS component and phase 2 of the compiler project.
4988
4989<p>I will now make various improvements to the existing OS.
4990
4991
4992<p><a name="200611251">============== 25th November 2006 project summary ===============</a>
4993
4994<p>This is an updated version of the 21st September 2006 update which was an 
4995update of the 23rd July 2006 summary.
4996
4997<p>Here is a summary of major developments: the major hardware success was
4998getting DMA PCI control of hard disks functioning. That took months of work
4999to figure out, I can now read and write via DMA, ATA drives via 28 bit and 48 bit
5000sector numbers. 28 bit is used for drives which havent implemented 48 bit.
5001Drives below 128G dont need to implement 48 bit, some dont.
5002I have now completed the second phase of my compiler project,
5003this is the second of approx 8 phases towards a 64 bit C compiler, this second 
5004phase took 1.5 months to complete. It is one of the most difficult phases 
5005of the compiler project. I plan to create a big endian x86 option 
5006as well.
5007
5008<p>I have a very low level PS/2 mouse driver functioning,
5009I've implemented mouse position but no mouse pointer yet. So far I've been 
5010unable to reconfigure the mouse though I have managed to initialise the mouse.
5011I can do the reconfiguring in software as the initialisation defaults give
501216 pixels per mm resolution which is 406.4dpi so its not a major problem.
5013I have PS/2 keyboard support, though no driver yet. Any keyboard functionality 
5014I need I can implement by hacking directly eg I've implemented WaitForChar(), 
5015this polls till the key is pressed. It is better to wait by not polling, 
5016however it will be some time before I can implement that.
5017
5018<p>I have various low level time features implemented,
5019eg code to read and set the time and date and can do timeout polls of 
5020hardware eg timeout after 3 seconds. Without time hardware you can only 
5021poll via a counter and the code may fail on a faster CPU.
5022I have a low level DMA floppy disk driver running: I havent yet implemented 
5023proper error handling. Dealing with error handling is a gruntwork subproject. 
5024Floppy disks have various complicating factors eg if you keep reading from a disk 
5025the head gradually becomes misaligned. This means that some errors are
5026not real errors and you need to reset the head and try again. That is 
5027something I will need to code later.
5028
5029<p>I have a lot of low level system hardware functioning and 
5030have gradually developed my own efficient low level reconfiguration
5031of the system hardware eg mobo hardware.
5032
5033<p><a name="A">(A)</a>By understanding the low level hardware I have managed to find a way 
5034around various BIOS dependencies, eg I can now fully bootstrap ATA PCI DMA 
5035without the BIOS. Not yet fully implemented that as it requires some work but know how to.
5036(2007.3.6: now done see <a href="#B">(B)</a> below)
5037
5038
5039<p>The current bootstrap uses legacy x86 text graphics. x86 has text rendering 
5040in legacy hardware, this gives you the well known standard x86 80 x 25 text.
5041However a modern OS cannot use that, its very useful though for the bootstrap 
5042as it allows you to work on the CPU first.
5043I have truecolour low level graphics functioning but completely unintegrated. 
5044So far only done graphics in 16 bit, that only gives you access to a few cm at
5045the top of the screen as the rest of the screen is beyond the memory range of 
504616 bit. That must be why they used text graphics hardware, its the only way 
5047to do text in 16 bit. <a name="graphics">Integrating modern graphics</a> is one of the next major 
5048subprojects eg I will have to implement my own fonts. I will use the 
5049CPU as a GPU as that gives me full compatibility with all graphics cards.
5050
5051<p>The filesystem project has been stalling, for the moment I am working 
5052on other things. I have tidied up the existing code and the compiler project
5053has borrowed interesting subsystems from the filesystem project especially
5054the memory debug system. I have also generated various plans for what to 

5055do next with the filesystem. The FS project influences all the later subprojects
5056as I invented many mechanisms for the FS which are generally applicable.
5057
5058
5059<p>There are endless miscellaneous subprojects I've worked on, eg 
5060I wrote my own generic ELF loader in c and have designed various things
5061to implement later. Some subprojects have to be postponed 
5062as they depend on things not implemented yet. eg the filesystem depends on a 
506364 bit C compiler and an ATA driver. 
5064I have now enough ATA functionality implemented to supply
5065the required ATA driver. However I regard other problems as more urgent.
5066
5067<p>21st September: I have just now completed a major low level OS kernel
5068component which has taken 2 months to develop. This is code that normally
5069I would only do in C, but here it has been done entirely in asm: mainly 
5070because the C compiler wont be usable for quite some time. Probably it
5071would have been better done in C, its just that I was impatient.
5072
5073<p>Early phases of the compiler project are complete which are not C specific.
5074
5075<p>22nd Nov 2006: C pre processor is complete. This has not been 
5076thoroughly tested. It is a fully functioning C pre processor. It doesnt 
5077yet have support for floating point numbers, otherwise it is complete.
5078Floating point support will be straightforward but I need to study 
5079what is involved. The C pre processor has various enhancements over
5080the standard. More on these later.
5081
5082<p>Although the work so far looks very chaotic that is just temporary,
5083same way a building site is total chaos. The chaos is because of the 
5084high level of complexity. When I say temporary that could be many months.
5085
5086<p>Feb 2007: the OS now has been ported to my new laptop and runs on 
5087both machines. The work now is focussing on the synthesis of OS architecture
5088gradually manufacturing a pre-emptive multitasking system.
5089
5090<p><a name="B">(B)</a>5th March 2007: The ATA PCI DMA code is now fully 
5091independent of the BIOS, <a href="#A">see (A) above</a>
5092
5093<p>2nd July 2007: first successful kernel level pre-emptive multitasking has been run.
5094This is an initial version of pre-emptive multitasking, the subproject isnt
5095complete eg there isnt any task exit implemented yet so tasks currently must
5096never exit. The semaphore subproject is complete and fully functional.
5097
5098<p>The OS is completely 64 bit and is fully multiprocessor x86. The 
5099multiprocessor code is tested on a dual CPU AMD Turion X2 and will run 
5100on up to 256 multicpus as that is the limit of the x86 architecture.
5101
5102<p>2nd August 2007 5am: the new pre-emptive multitasking architecture is 
5103now functioning correctly. This tries wherever possible to relaunch tasks
5104to the same cpu in order to optimise cache usage. Sometimes it is more
5105optimal to relaunch to a different cpu: a very complicated heuristic
5106optimisation algorithm is used. This is much more complex than the original architecture.
5107This makes the OS super modern.
5108
5109<p>The plan now is to implement a C++ compiler instead of a C compiler.
5110
5111<p>9th April 2008: major changes of plans in the months since the above 
5112was written, in October 2007 I abandoned the C++ project 
5113as C++ is not what I want and too time consuming to implement.
5114No point spending many months implementing functionality I never plan to use!
5115Instead I have since then been designing my own language from scratch
5116which does what I want and implementing the compiler for that. 
5117I have just today (9th April 2008) completed implementing the code that
5118checks for type equality and the compiler for this new language is 
5119probably 75% complete. It is a very difficult project.
5120
5121<p>Once the compiler is complete the remainder of the OS project will be 
5122written using my own language. C was invented to implement Unix with
5123around 1978 and here in 2008 I am inventing my own language to implement
5124my own OS with!
5125
5126<p>My language is a completely different paradigm from C++, and will
5127give me the functionality that the OS coding requires. The type system
5128has comparable power to C++ templates but is geared completely differently.
5129
5130
5131<p>
5132<p>
5133
5134<!-- GoStats JavaScript Based Code -->

5135<script type="text/javascript" src="http://gostats.com/js/counter.js">
5136</script>

5136<script type="text/javascript">
5137_gos='c2.gostats.com';_goa=511492;_got=1;_goi=65;_goz=0;_gol='webstats';_GoStatsRun();
5138</script>

5138
5139<noscript>
5140<a target="_blank" title="webstats" href="http://gostats.com">
5141<img alt="webstats" src="http://c2.gostats.com/bin/count/a_511492/t_1/i_65/counter.png" 
5142style="border-width:0" />
5143</a></noscript>
5144<!-- End GoStats JavaScript Based Code -->
5145
5146<p>
5147
5148</BODY>
5149</HTML>