Saturday, November 12, 2005
Register-based Virtual Machines
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:
- Java virtual machine
- Microsoft .NET CLR (based on ECMA 335)
- ACK's EM virtual machine
- UCSD p-code, commonly used in Pascal implementations
- Core of the Python interpreter
- Forth (more correctly, a dual stack machine)
- Smalltalk, and Squeak
Finding a list of register-based VM's required more work, but I quickly dug-up:
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
See this post for details on what rip3 does.
Wednesday, November 09, 2005
Red Flags (or the PHB just doesn't get it...)
- "Wouldn't it be easy to..." (the hidden cost of change)
- "This shouldn't take long" (artificial time frame)
- "Can you make this small change real quick?" ("small" and "quick")
- "Before you finish x, could you do y?" (the mental costs of interruption)
- "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)
The first column appeared in Volume 3, Issue 2, and discussed:
- Quad1 by R. J. Herbold
- Rootfinder by J. Wegstein
- 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:
- Algorithm 154: Combination in lexicographical order
- Algorithm 155: Combination in any order
- Algorithm 156: Algebra of sets
- 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 :-)