Historians Recreate Source Code of First 4004 Application

mcpublic writes "The team of 'digital archaeologists' who developed the technology behind the Intel Museum's 4004 microprocessor exhibit have done it again. 36 years after Intel introduced their first microprocessor on November 15, 1971, these computer historians have turned the spotlight on the first application software ever written for a general-purpose microprocessor: the Busicom 141-PF calculator. At the team's web site you can download and play with an authentic calculator simulator that sports a cool animated flowchart. Want to find out how Busicom's Masatoshi Shima compressed an entire four-function, printing calculator into only 1,024 bytes of ROM? Check out the newly recreated assembly language "source code," extensively analyzed, documented, and commented by the team's newest member: Hungary's Lajos Kintli. 'He is an amazing reverse-engineer,' recounts team leader Tim McNerney, 'We understood the disassembled calculator code well enough to simulate it, but Lajos really turned it into "source code" of the highest standards.'"

How to build a CPU -- transistor level up!

[compumike]

Take a look at this set of videos from MIT's 6.004 Computation Structures [mit.edu] class. They basically walk through the design of a simple 32-bit CPU from transistors, to gates, to functional blocks, to a full processor.

Anyway, reading about how hard it was to recreate the source code from the 4004 makes me wonder how easily we could find source code for some apps from even a decade ago. Lots of companies have gone bankrupt / discontinued products / been sold / etc, and we all know that lots of people aren't good about backing up their code. It's neat to go to the Linux Kernel Archives and look at the Historic Linux sources [kernel.org].

--
Educational microcontroller kits for the digital generation. [nerdkits.com]

large function in small code

[Have Brain Will Rent]

In 1970 the PDP series from DEC, e.g. PDP-8, had an interpreted (and used interactively) language called FOCAL, arrays (even sparse ones), real numbers, usual math and other functions, for loops, if statements blah blah blah... all the usual stuff - the entire interpreter *and* runtime was programmed in a total of 2K instructions (and they were primitive instructions). That was normal for the time.

Re:Something is wrong......

[bpharri2]

Of course if you had bothered to read the article, you'd know that it doesn't work like todays calculators but like the old adding machines:

"The electronic calculators that accountants used 35 years ago worked differently than the familiar four-function calculator we use today. These were designed to behave much like mechanical adding machines of the 1960's. After every number you want to add to the total, you need to press +, so = doesn't work like you'd expect. Here are some examples:

To add three numbers: 61 + 79 + 83 + = (if you forget the last +, the 83 won't get added)
To subtract two numbers: 2007 + 1971 - =
To multiply two numbers: 125 x 5 = (this is more like we're used to)
To divide two numbers: 625 / 5 = "

Re:Only 1024?

[ppc_digger]

They put all the actual code in a shared library:

# ldd /usr/bin/kcalc
libkdeinit_kcalc.so => /usr/lib/libkdeinit_kcalc.so (0x00002b1351db8000)
...

# ls -lh /usr/lib/libkdeinit_kcalc.so
-rw-r--r-- 1 root root 436K 2007-07-03 19:15 /usr/lib/libkdeinit_kcalc.so

Re:Commander Keen

[Hal_Porter]

Damnit slashdot really doesn't like <s in the middle of paragraph even in Plain Old Text mode, it actually junked the next couple of paragraphs!

patch1:
    addl ebp,12345678h

generates some code like this

81 C5 78 56 34 12

The first two bytes are addl,ebp and the rest are the constant.

Now what Carmack wants to do here is to have an extra register to hold a constant so he overwrites the constant in the instruction. Patch1+2 is where the constant is

movl ebx,[_dc_iscale] // get the constant
    shll ebx,9 // constant <<= 9
    movl eax,OFFSET patch1+2 // get the address of the constant in the instruction
    movl [eax],ebx // overwrite it in the instruction

So essentially the code becomes

patch1:
    addl ebp, _dc_iscale << 9

What I'm not sure is why he didn't do addl ebp,[FractionalIncrement]. That would take the FractionalIncrement from a memory location. Then he wouldn't need the self modifying code, he could just write _dc_iscale << 9 there.

On the other hand, maybe the code is memory limited anyway and this will slow it down.

On a recent x86 processor self modifying code will be correct but not too fast. If code is not self modifying it will execute from the instruction cache and writes will be buffered and stored in writeback data cache. Self modifying code screws with this - the write needs to end up in the i cache somehow. And x86 opcodes are converted into a Risc like internal format for execution, and if these are cached you need to flush that cache too. And since they have to do it on old code they have to do all steps automatically with no hints from the programmer.

On an ARM you just need to clean the dcache, flush the write buffer and flush the icache as ARM instructions are a executed directly. And all these are things the programmer has to ask for explicitly using MCR and MRC instructions. Actually ironically the ARM has more registers 13 instead of 6 so you have less need for this and you can encode shift counts for free, so in ARM you could do this

patch1:
; Rx holds whatever was in ebp
; Ry is _dc_iscale
  ldr Rx, [Rx, Ry, lsl #9] // Rx = Rx + (Ry<<9)