[NTLK] Geek Alert: NewtonOS

[Forrest]

Frighteningly so, I understand just enough about coding to comprehend most of what you're saying.

So it sounds like, if you are able to correctly and properly perform the task of converting the entire ROM into native code, it would be possible to actually IMPROVE the parts of the Newton OS that are perhaps outdated or anachronistic, or that you/we (as a group) believe could be improved upon?

This is really fascinating stuff. We could, essentially, do what only Apple could, up to this point--have a 2014 version of the Newton! Perhaps with color, a better Web browser, and so on...and on.

Of course, there is no hardware for it...I'm sure there are Himalayas of legal issues regarding that. I, myself, wouldn't give up on the idea, however...we've come this far, who knows what could be next?

The only question is: when does our creation stop being the little green friend we all know and love? Because, if this pace continues, it will at some point have less and less resemblance to an actual, late 90s Newton.

Thanks,
--Forrest

"The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place."
--Douglas Adams




On Jul 5, 2014, at 2:22 PM, Matthias Melcher <mm at matthiasm.com> wrote:

> 
> Hi Newton fans,
> 
> Earlier this week, I had a few hours to dive into the Newton ROM. Not sure, if this leads to anything, but I thought I write it down, so it is archived here.
> 
> As some of you know, I have been trying to gradually replace the emulated ROM code with native code that would run hundreds of times faster and more efficient. This would be relatively straight forward, if it wasn't for the Memory Management Unit that can interrupt our linear code execution at any time, ruining all opportunities to optimize code.
> 
> Well, I finally managed to understand what happens when the OS tries to read or write a protected memory area: first, the dreaded MMU interrupt is triggered, changing the CPU mode and starting a subroutine. This subroutine deciphers the command that caused the interrupt and restores registers to their value *before* the faulty command was executed.
> 
> Depending on the type of violation, a different Task is prepared which will fix the problem (allocate RAM for a stack, read data from a compressed file, allocate head, etc.). Then, the new task is put as the first in line to be executed. Our current (faulty) task is suspended, just as it would be when tasks are switched by the scheduler, and the task's PC is set to the faulty instruction.
> 
> Now (and that is the thing that I previously did not understand) execution does *not* return to faulty task, but instead, the scheduler switches to the first task, which will (hopefully) fix the fault. Eventually, the task is done and the scheduler will run our original task, continuing with the same instruction that caused the violation (which should not happen again this time around).
> 
> What does that mean for development?
> 
> Now that this mechanism is understood, it is possible to implement the memory violation handler in native code. This is relatively simple because this code can not cause another violation, allowing us to optimize and write good code.
> 
> Writing this code will implement large parts of the scheduler. Once the scheduler is native, we can add code that maps NewtonOS Tasks onto the thread system of the host OS. Well, and once the scheduler and task have native support, we no longer need to worry about emulating task switches, as those are now native. Handling a memory violation is now justa C call instead of running a whole new emulator fiber.
> 
> What does that mean for Einstein?
> 
> If I manage to implement this, we have enough code and knowledge to translate the entire ROM into native code. This could even be automated, generating convoluted, but working code (speed factor of 10, I would assume). With the entire ROM in native code, we can use debuggers and all the other nice tools to optimize whatever we feel is important in the code (spped factor of 100 and more possible).
> 
> Thanks for reading my ramblings ;-)
> 
> Matthias
> ----------------------------------------------------------------------
> 
> The NewtonTalk Mailing List   http://newtontalk.net/
> The Official Newton FAQ       http://splorp.com/newton/faq/
> The Newton Glossary           http://splorp.com/newton/glossary/