Runtime code generation (by alaric)

Spurred by a thread on comp.os.research, I've been reading up on the Synthesis OS design.

Wiki page about Synthesis

The original thesis

This looks like good work, insipring for ARGON; with HYDROGEN explicitly exposing runtime code generation primitives, like any good FORTH system, and the CHROME metaprogramming stuff is based around run time code generation.

I'd hoped to look at how to optimise the system using runtime generation for common stuff - but I expected to have to experiment later; luckily, this fine fellow has blazed a trail for me!

However, I can't help but feel this is more of a programming language issue than an operating systems issue. The author has written an OS in assembly language, and implemented much of it by generating specialised code on the fly rather than jumping to the general code that then has to analyse its dynamic context every time it's executed to decide which control path to take, and having to load data indirectly rather than having it as an immedate value. Surely this stuff should be generalised into a way of optimising all code, rather than just being used in an operating system? I don't see the fundamental technique as being particularly bound to operating systems - lots of applications could benefit from it.

For ARGON, I'd like to use the metaprogramming facilities I've already planned for CHROME to build a toolkit that makes runtime specialisation optimisation easier. Maybe even look into making it happen automatically, although I suspect that the tradeoff involved may require human intervention at heart. A lot of the benefits could be had anyway by just compiling the code in a custom environment containing the constants, which will be constant-propogated and constant-folded and the used as immediate values - but I think those cunning executable data structures need more thinking about...

ARGON node diagram (by alaric)

Since I'm always rethinking parts of it faster than I can write them up, ARGON lurks to a great extent inside my own head, with the Web site lagging behind a little. This just helps to make it all the more confusing for interested folks, so I've bitten the bullet and produced a shoddy diagram showing how all the services can fit together on a single running node.

http://www.argon.org.uk/argon-node.png.

Here, we see how the HYDROGEN hardware abstraction layer is used by various components to support WOLFRAM, for in-cluster management of shared state; MERCURY, for inter-cluster and in-cluster communication and FLUORINE for interoperability with other network protocols. These act as interfaces to the entity handler user code - your application - invoking your entities to handle incoming network requests, and providing an API for your code to make outgoing network requests.

I've shown how real-time user tasks will be executed by the HELIUM scheduler in response to timers or incoming signals, and how they interact with local hardware to perform their work.

And I've shown how the NEON user interface subsystem uses the human interface hardware APIs provided by HYDROGEN to proxy between the user and the CARBON directory (for browsing) and MERCURY to then interact with entities to request that they provide code for a user interface front end, which is then executed locally by CHROME in order to provide a responsive user experience for accessing remote resources.

Hopefully, this will make my rantings make a lot more sense to people...

Information of use to a terrorist (by alaric)

Ok, in the UK, I've heard of "posessing information of use to a terrorist" as being a crime.

Google can't find me much more detailled information about this, which is nagging at me.

Now, as somebody with a broad interest in the fundamental forces that bind the Universe together (y'know, electromagnetism, nuclear forces, and that sort of thing), and their manipulation to enhance the human frame's limited powers in order to make us godlike beings able to shape planets in our own image, and just because huge glowing balls of plasma are fun to play with, I know lots of stuff that may be of use to terrorists. I suspect, for variosu reasons, that I'm probably on some kinds of watch lists somewhere.

Therefore, I try to be SQUEAKY CLEAN. I don't partake in the minor petty crimes many people do; software piracy, breaking speed limits, and so on. I suspect that I'm probably being watched, and such things logged. If the UK takes a paranoid turn, then somebody in power might ask the intelligence services to start taking down "potentially dangerous" people on whatever minor charges can be found, "just in case". In which case, I'd probably be in for it.

However, yesterday I was browsing the welding section in Foyles, when I wondered accross (in the adjacent metallurgy section) a translaction of "The Pyrotechnia of Vannoccio Biringuccio: The Classic Sixteenth-Century Treatise on Metals and Metallurgy". It contained lots of practical instructions on metal melting and casting without access to super-high-tech equipment - perfect for my casting experiments, and historically interesting.

So I bought it. However, when reading it on the train, I saw in the contents that it has chapters on "The manner of making metal balls (that burst)", "The methods of making tongues of fire", "The methods of making fire tubes", and "Concerning the fire that consumes without leaving ashes, that is more powerful than any other fire, and whose smith is the great son of Venus" (wow).

First thought: "Cool! That sounds like crazy alchemical summoning-and-harnessing-the-great-element-of-Fire stuff. What fun!" Second thought: "Bugger, if the thought police break down my door and rifle my bookshelves, they're gonna look dimly on all that. For at the time, that was the height of military technology (it includes detailled instructions on the construction of cannon, for example)."

Read more »

Arc welding (by alaric)

As a treat, I've bought myself a manual metal arc welder!

Manual metal arc welding, however, is quite tricky to learn. Basically, the stages are:

1. Being able to make the thing go at all. You need to create an arc, then maintain it, which needs a fair amount of practice and dexterity.
2. Being able to then move the arc at the desired rate, in the desired direction, to leave a weld behind.
3. Being able to do this well enough to produce a strong weld, rather than a rough blobby one that's only attached here and there
4. Being able to do this well enough to produce a neat weld, which is the same as the previous hurdle, but now keeping the weld the same thickness all along, and nice and smooth
5. All of the above again, but under trying circumstances such as when the objects being welded aren't nice and conveniently placed in front of you

I've just managed 1 today, and am part way through 2!

My medium-term goal is to make new crucible tongs - the previous ones are OK, but a little hair-raising to use since they don't grip the crucible perfectly. They were made by bending single lengths of steel, which constrained them a little. With welding mastered, I should be able to make crucible tongs that fit around the crucible much more snugly, so requiring less wiggling to get them in the clearance between crucible and furnace wall, and then a tighter grip of the crucible itself rather than just squeezing it at a few points...

Arc welding is fun!

The association between flourescent green materials and radioactivity isn’t just the domain of comics and movies (by alaric)

Uranium can be added to give glass a fluorescent yellow or green color

http://en.wikipedia.org/wiki/Glass#Overview

...it's official! Glass containing uranium is actually coloured flourescent green/yellow!

After all my irritation at radioactive wastes always being portrayed as a glowing yellow/green liquid, that little point has made my day. Thankyou.