Snuffles (by )

Jean has a cold! Her first taste of sickness.

She's snuffling and sneezing and coughing, and her eyes are puffed and watering, but she's not letting it get her down - she's a bit grumpier than usual, but she still smiles at us and her toys! I'm quite impressed; I don't think I could be very cheery if I felt as rough as she looks.

We're keeping her well supplied with Karvol (stuff for children that releases menthol vapours) and trying to keep her warm and comfortable.

Nooooo! Van!!! (by )

Just had a phonecall from the friend who was borrowing our lovely van - he was just driving it back, when it made rattling noises, so he pulled over and now it won't start 🙁

The fear is that it may have run out of oil and seized, since it has a known propensity to get through oil fast (as many old diesels do). However, no warning light came on.

Please be OK, van!


Looks like it did run out of oil; the engine's all seized up inside.

However, luckily, Sarah's uncle is a mechanical engineer, and has managed to find us a nice Transit engine that's even newer than the one in the van - and he can install it for us! So the van is going to have something of an upgrade to a turbo diesel engine - a new lease of life...


A new computer architecture (by )

I was in a hardware mood on a train a few months ago, so I typed up some notes about a possible different architecture for CPUs that might make good use of internal parallelism, have asynchronous control, and a high code density. The result would be an efficient CPU, but it does make interrupt handling a headache.

I then go overboard, designing a device interconnection framework for expansion! It was a boring train journey...


It occurs to me that a neat way of easing the problems of interrupt handling in highly asynchronous and parallel CPUs would be, quite simply, to not bother with them - let a dedicated I/O processor with an architecture designed for low-latency context switches handle them, and handle pre-emption of user code (eg, an interrupt saying that a block is ready for reading from the disk controller causing the code that was blocked waiting for that data to become runnable, which then preempts the current process since it has a higher priority) by allowing the I/O processor to instruct the main CPU to do so.

So the main CPU would still need context save and restore logic, but it wouldn't need to be able to nest IRQs or anything; all it would need is the ability to save the current context to RAM and then load another context from elsewhere in RAM, as an atomic operation, and it wouldn't need to be as fast about it as if it was in the critical path of interrupt handling.

Within my architecture below, this can be handled by having an (on-chip) interrupt processor which is a tiny stack-based MISC with local SRAM for code and data (shared with the main CPU). When an interrupt occurs, push the program counter (the only register!) of the MISC onto the stack, and jump to a vector in the SRAM. If the interrupt handler feels it needs the main CPU to reschedule, then it tells the CPU to switch to a context, giving it the address of the new context. The address the current context was loaded from is kept around in a register, so the CPU suspends instruction fetching, waits for all execution units to finish, then saves the contents of registers and FIFOs to the context in RAM, loads the new context pointer into the context pointer register, and then loads the new context and resumes execution. The CPU should check to see if the new context being switched to is the same as the old context (by comparing the provided pointer with that in the context register), and if so, do nothing.

Most of the time, the interrupt handlers would just cause a switch to a special scheduler context, which would work by choosing a new process to run, manually invoking a context switch to it, then looping back to the top of the code. While the scheduler context is running further requests from the MISC to reschedule will be ignored since that context is already active; this means that an interrupt causing a context switch request between (or during) the schedule algorithm and the context switch, which makes a higher-priority process runnable, may not result in that process running until the next context switch. So perhaps the CPU should handle a request to switch to the context it's already in by just reloading the context, which would restart the scheduling algorithm.

Any context switch request coming in while a switch is in process should be queued, perhaps suspending the MISC until the CPU is ready to perform the switch.

Read more »

Snow in Gloucestershire (by )

It snowed, which made a very picturesque scene of the Mill:

However, alas, it had all been washed away by rain the next morning...

WordPress Themes

Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales
Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales