A fair while ago, I posted about my Virtual CPU code, that code (still not complete) just does addition (and my association subtraction), the point was to lead into code which emulated actual logic gates and indeed I write (somewhere in these pages) a half-adder followed by a full-adder emulation logic in C++ code.
The purpose of this was actually related to my giving a talk to some school children, it was ever intended for these pages, the kids could not wrap their heads around not being able to "just multiply".
They had studied computer memory, and wrote documents in word bigger than the actual memory foot-print of the machines they were talking about.
The teacher, a friend of mine, wanted to demonstrate this to them.... I therefore hoved into view with my 12Kbyte Commodore 16... And challenged the kids to write a program for it... They then had the massive struggle... One bright young chap found a C16 emulator online, and he wrote out a long program in Commodore Basic, which amounted to little more than a text-editor...
It was very impressive work from the young chap, and I've kept his number for when he graduates (in 2021), unfortunately it worked fine on the emulator, as you could assign more memory to the machine... After typing the program into the actual machine... It ran out of memory! The edit buffer was only 214 bytes...
He had only tested with "10 print 'hello' 20 goto 10", but typing any lengthier program in and it essentially started to overwrite the previous lines of code.
You might call this an oversight, but it was semi-intentional as after all the project was about memory.
So having learned how expensive and precious memory was, and is, in this world of near unlimited storage the kids moved onto assembly, learning about how the lowest level of a machine worked.
This is where my work came into help, because they could not wrap their heads around "not multiplying". In some chips a multiplication call might be many thousands of gates ("to multiply was 200,000 gates, over half the chip" - 3Dfx Oral History Panel - See video below).
Hence I wrote the code of a CPU only to do addition, to multiple one had to write assembly which did a loop of additions! I left the kids to write the assembly for division, which is why you never see it here in my code.
It worked, but I find so many commentators have missed this piece of computing history, have missed that machines used to NOT come with every function, you had to emulate some functions in software with the bare-set of commands present.
Some have confused this with the idea of RISC, this isn't what RISC is about, but I distinctly remember being taught about the RISC based machines at school (Acorn machines) and that RISC meant there were "less instructions". Sofie Wilson herself tells us that this isn't the point of RISC...
Having just spoken to my friend about the possibility of presenting these ideas again to a class of kids, I'm wondering whether I need to clean up all my code here, to actually make-sense of all these disparate and separate sources and write one paper on the topic; histories of this which are readable by kids seem to be sadly lacking, or they start from the point of view of a child of my time, born in the late 1970's whom remembers a time when you have limits in computing.
Kids today see no such limits, and find it hard to relate to them, my own niece and nephews, whom are just turning 15, find it hard to fathom such limits, even when they can sit down with me in front of a 12K machine, or a 512K machine, they can't relate, these pieces of history, these things which previously one had to work around are alien to them.
They don't need to work around them, and this leaves me meeting modern graduates whom lack some of the lowest level debugging and problem solving skills.
Indeed, I see these great efforts to publish frameworks to make modern developers test and think about software, because new developers have never had to get things right the first time...
I did, I'm one of the seeming few, who had to get it right and first time. This is not bragging, it's actually quite sad, as how do you prove your code is good? Pointing to a track record counts for very little, especially when the person you are trying to persuade has no interest in you, just your skills.
My most recent anathema, Test Driven Development, seems to be the biggest carbuncle in this form of "modern development"... Write me some code... They might ask, and you can write the code, and show it's correct, or you can write the tests which test the range, the type, the call, the library... Then write the code?... One is quick, efficient, but requires faith in the developer... One is slower, aims to forge faith of the code out of the result... Both end up with the same result, but one requires a leap of faith and trust.
Unfortunately, bugs in code, over the history of development have destroyed that faith in the developer. There are a precious few developers whom are trusted to act on their own initiative any longer. I know I work in a part of my employers company where I am trusted to act on my own initiative; with temperance that I have delivered very many years of good working products.
But I'm seeing, and hearing, of so many other parts of companies around us which do not trust their developers, and I would argue, if these developers had had to struggle with some of the historical problems my own generation of developers had struggled with, then they would be trusted more, and be freer to act, rather than being confined and held-back by needing to check, recheck and double check their code.
Trust in one another, a peer review, and where necessary a sentence of text on the purpose of some function or other, should really define good development, the code itself can tell you it's purpose, not the tests, certainly not by just running the code employing observation.
I therefore propose I get off my pontificating bum, clean up all my "virtual CPU" stuff, document some of these issues, and we as part of the development community try to get new developers to challenge themselves against Old Computers... ComputerPhile already demonstrate this with their Crash Bug examples with the Atari ST...
No comments:
Post a Comment