A new computer architecture (by alaric)

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...

= UPDATE =

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 alaric)

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

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

SOCKS vs NAT (by alaric)

The standard solution these days to the problem of a large internal network of client machines that need Internet access is to stock them behind a NAT, with a single external IP from which connections can originate.

However, before NAT was popular, I remember setting up SOCKS proxies, which did more or less the same thing.

The downside was that not all applications supported SOCKS, and annoyingly there generally wasn't an easy way of telling the whole machine to use SOCKS; each application had to be configured manually, while NAT works by providing the illusion of real Internet access.

The upside, however, is that SOCKS doesn't work by fooling anyone. The application knows that the IP address it gets from the local stack is not necessarily global, and can ask the SOCKS server what the global address is. And the application can ask for a listening socket, making peer to peer file transfers and the like work properly.

Perhaps rather than using NAT for more and more, we ought to be putting support for SOCKS right into the IP stacks of operating systems, so applications using the standard TCP/IP APIs work with SOCKS right out of the box, and specifying a DHCP option so a DHCP server can nominate a SOCKS server to a client machine?

Then we wouldn't have all this pain with peer-to-peer file transfers...

Local community (by alaric)

The village we live near, Cranham, has a particularly strong community, which we are slowly working our way into (limited somewhat by the fact that we have very little free time right now).

So today we went along to a Christmas carol singing event at the village hall. Our very own GP was there ringing handbells, and afterwards we chatted to some of our new neighbours; including a lady who (like me) grew up only seeing from one eye (and thus had a very similar experience of problems with depth perception), and another lady whose first job had been programming in assembly language and COBOL in the 1960s (on PROPER computers with punched cards).

Mmmm, people with things in common with me... and they're all so friendly. It's a far cry from life in London, or indeed in Luton where I grew up.

This is going to be a lovely place for Jean to grow up! I really need to start getting involved more in local life, though - I've been idly discussing with a few people that the school's nice optical fibre Internet connection could be share with nearby residents (who can't get good ADSL due to our distance from the exchange) with a wireless bridge... and there are myriad societies to join...

Old-school brazing (by alaric)

Yesterday, my mate Seth was trying to fix his car exhaust pipe. It had a bit that was made out of corrugated metal tubing, presumably to allow one end of the pipe to vibrate with the engine while the other is fixed.

Anyway, in the way of these things, with all the vibration and heat, it had broken off at one end, leaving the fragmented end of the corrugated thin metal tubing; now without the straight bit of tubing that would nicely clamp around the next bit of pipe.

So we decided to braze it - and due to the scale of the job and the small scale of my supplies of silver solder, to old-school braze it with real brass. After a lot of angle grinder work cleaning the corrugated tube end up and preparing an extension tube made from a tin can (ground down to reveal the steel sheeting within), we smeared a load of flux paste on, heated it up to a orange-ish red, squirted MORE flux paste on, and applied some brass rod I had lying about. Read more »