When writing software that uses any kind of API or hardware functionality, sooner or later there will be questions about what a particular API call or hardware operation is supposed to do. In principle, such questions should be answered by referring to the specification (and user documentation). I am a firm believer in writing readable and clear specs and keeping software coding to follow the spec, as that ensures future compatibility. But reality is not that simple. Things are generally better today than they used to be, though. Reading up a bit on the history of my first computer (the ZX Spectrum), I found some rather interesting cases of spec vs implementation, and “discovered functionality”.Continue reading “Code to the Spec(trum) or the Implementation”
A few days ago, Sir Clive Sinclair died. I owe him, or rather his most successful product, my career as a computer scientist. I bought myself a ZX Spectrum in my early teens, taught myself how to program it, and never looked back. The ArsTechnica obituary calls the Spectrum a “gaming computer”, and I guess that is mostly fair. Can’t say I ever used it for more than playing games or programming games.Continue reading “Thank You, Sir Clive Sinclair”
I am a big fan of proper real decent mechanical tactile clickety-clack keyboards. Writing is my means of communication, creation, and commercial contribution to the world. I write a lot of text – both code and normal language, and I feel that I type faster, more accurately, and produce better text when using a tactile keyboard. I cannot understand how anyone cannot love them once they have their fingers on them. However, mechanical keyboards have a bad reputation for being NOISY. The rest of my family thinks my CoolerMaster Trigger Cherry MX Brown is a bit too noisy when I use it at home. Thus, when I read about the Matias Quiet Pro keyboard, I spent the money and gave it a try. If I could have the feeling of a tactile keyboard without the noise, it would be a wonderful compromise!
I just rediscovered my first computer, a Sinclair ZX Spectrum (good picture) which I bought back in 1983 or 1984 (I have no trace of the exact date, unfortunately). The machine was a perfect machine to learn programming on in my opinion, consisting of little more than a Z80 processor with memory, bit-mapped display (with a famously odd-ball addressing scheme and color handling) and ultra-simple sound output and input. Most of my friends in the end bought Commodore C64 machines, which had more powerful graphics and sound hardware, but a processor that was much less fun to program.
The Spectrum came with a built-in BASIC interpreter that are up the bottom 16kB of the 64kB addressing space. The BASIC was actually fairly powerful and easy-to-use, and included a very fun programming textbook. I just reread that textbook, and it is quite strikingly well-written and manages to cover both basic computer-science-style programming and deep close-to-the-machine and real-time programming in a compact 150 pages. There is no credit to a particular author in the book I have (Swedish translation by a group of people at Ord & Form here in Uppsala), but an online scan credits Steven Vickers.
One thing that surprises me is how rare the feature of checkpointing or snapshotting is in the land of virtual platforms, despite the obvious benefits of that feature. Indeed, checkpointing was one of the first cool things demonstrated to me when I joined Virtutech back in 2002. Today, I could not ever imagine doing without it. Not having checkpointing is like having a word processor where you only get to save once, when your document is finished, with no option of saving intermediate states.
But not everyone seems to consider this an important feature, judging from its relative rarity in the world of EDA and virtual platforms. Why is this? Let’s look at some possible explanations.