Saturday, November 12, 2005


Register-based Virtual Machines

Andy Tanenbaum made an interesting comment about register-based virtual machines in this posting to comp.os.minix:
I agree that EM-1 and JVM do differ in many ways, but they are unusual in that both are register-free stack machines, an oddity these days.

I've always regarded register-free stack VM's as being the norm - you certainly don't need to look around too far to find them. Here's a short list (by no means exhaustive) off the top of my head:

Finding a list of register-based VM's required more work, but I quickly dug-up:

There are also a couple of papers (related authors) on the topic:

I'm not yet convinced that stack-based VM's are an oddity! Certainly, RISC architectures with large register sets have transformed computing hardware, but within the software world there still appears to be a bias toward stack-based machines. Is this a consequence of van der Poel's dictum that a machine should have 0, 1, or an infinite number of any feature? This last quote is from Andy Tanenbaum (and co-authors) in Description of a Machine Architecture for use with Block Structured Languages, which is the definition of the EM virtual machine - and now I find myself bottoming out of this memes recursion :-)

Friday, November 11, 2005


Little ripper

Better late than never - the latest version of rip3 now works on Unix (regardless of the underlying platform endianness), as well as Windows. Download either rip3.tgz (12KB; contains just source code) or (39KB; contains source code and Win32 executable).

See this post for details on what rip3 does.

Wednesday, November 09, 2005


SuziQ Design

Just wandered over to SuziQ Design, which is an art gallery/shop run by my cousin SuziQ. Check it out! The webpages have changed a lot recently, which is great to see.


Red Flags (or the PHB just doesn't get it...)

Breezed past 37 Signals earlier, and stumbled across The top 5 red flags of software development. The flags are:
  1. "Wouldn't it be easy to..." (the hidden cost of change)
  2. "This shouldn't take long" (artificial time frame)
  3. "Can you make this small change real quick?" ("small" and "quick")
  4. "Before you finish x, could you do y?" (the mental costs of interruption)
  5. "Let's push this today" (artificial scope)

I seem to face 4 of these red flags on a daily basis... The list is so short and succinct, just like a lot of the stuff these guys are producing. Good on 'em! Another post from these guys is Getting Real, Step 1: No Functional Spec, which raises the interesting point that functional specifications are all too often "appeasement documents... about making people feel involved". But when writing software, we don't want everybody too involved, especially those people that talk the loudest and code the least. At a certain level, after clarifying the goals of a project, it's necessary to Just do it! (aka the Nike software development process).

What started these ponderings was reading the latest Paul Graham essay on The Venture Capital Squeeze. Graham comments that there is "too much money chasing too few deals", and in any case, the cost of creating a new webservice business is getting incredibly cheap with commodity hardware and open-source software. But the big change noted by Graham is the use of dynamically typed languages (e.g. Python or Ruby) instead of C++, and the resultant reduction in programming effort. I think this last point is the most important - programming in Python can be extremely productive, and the customers certainly don't care about the implementation language. For a webservice, where the code remains directly under the control of the organisation, it is possible to keep working on the system after it has been deployed, and to make improvements as they are needed. This is not possible with the traditional model of delivering shrink wrapped software, where the costs of software changes are far more significant.

Similar ideas to those of Graham are also discussed in less as a competitive advantage, which is well worth reading. In a nutshell, build a system that people want before architecting a system that all people can use.

Paul Graham also discusses the impact of Sarbanes-Oxley on venture capitalists, and raises some interesting points. Phil Armour has also written about Sarbanes-Oxley, and the impact that the legislation could have on the software development process and the management of risk.

Sunday, November 06, 2005


CACM Algorithms (Wegstein)

I'm an avid read of the column The Business of Software that appears in the Communications of the ACM, and was searching the ACM digital library for further articles written by Phil Armour. Whilst doing this, I stumbled across the Algorithms editorial department in early volumes of the Communications of the ACM. Each column contains 'procedures and programs in the ALGOL language', and was edited by J. H. Wegstein of the Computation Laboratory in the National Bureau of Standards.

The first column appeared in Volume 3, Issue 2, and discussed:

  1. Quad1 by R. J. Herbold
  2. Rootfinder by J. Wegstein
  3. Solution of polynomial equation by Bairstow-Hitchcock by A. A. Grau

The column that I first stumbled across was in Volume 6, Issue 3, and contained a collection of algorithms contributed by Charles J. Mifsud, of the Armour (...ain't keyword matching great!) Research Foundation:

  1. Algorithm 154: Combination in lexicographical order
  2. Algorithm 155: Combination in any order
  3. Algorithm 156: Algebra of sets
  4. Algorithm 157: Fourier Series Approximation

The same column contained a revision of Algorithm 134 (exponentiation of series) by Henry Fettis, Algorithm 159 (determinant) by David Digby, a certification of Algorithm 79 (difference expression coefficients) by Eva Clark, etc... As you can see, the column discussed a wide range of algorithms, and at times, seems to have triggered spirited debate over correctness and the best implementation. Computing really hasn't changed that much in the last 40 years, but now rather than debating the finer points of code, we debate the finer points of software process!

It would be rather fun to dig up all of the columns, and rewrite the algorithms in Python (or some other modern language that is easily accessible). Maybe once I've retired :-)

This page is powered by Blogger. Isn't yours?