Last visit was: Fri Nov 01, 2024 12:39 am
It is currently Fri Nov 01, 2024 12:39 am



 [ 8 posts ] 
 1968 IBM experimental 4 bit computer with no ALU. 
Author Message

Joined: Tue Dec 18, 2018 11:25 am
Posts: 43
Location: Hampshire, UK.
While browsing for inspirations, I came across this:-

https://www.computer.org/csdl/proceedin ... 720655.pdf

A 4 bit computer, 512 bytes of core store, vector graphics via an oscilloscope, and no ALU, all ALU operations synthesised by look-up tables in the core store.


Tue Dec 18, 2018 2:39 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1803
Welcome - that's a really interesting find! Seems to be asking the question: if memory were really cheap and fast, how might you make a cheap and functional computer? And part of the answer, as you say, is lookup tables.

They seem to have made the memory nibble-addressable, so the lookup tables are much smaller, and to use self-modifying code to access them. As a result the machine is really simple and all the (transistor) logic fits on a single board.

It's what you'd normally call an accumulator machine, I suppose, except with no ALU it's not really an accumulator. They do have a link register though, to support subroutine calls, which is really important for a minimal machine with a tiny memory space.

Attachment:
Screen Shot 2018-12-18 at 21.17.21.png


As some kind of demonstration they also use a dictation tape recorder for mass storage, at 40 bytes a second.

I'm reminded of the much earlier 1620 CADET also from IBM, nicknamed "Can't Add, Doesn't Even Try" because it too used lookup tables instead of ALU.


You do not have the required permissions to view the files attached to this post.


Tue Dec 18, 2018 9:19 pm

Joined: Tue Dec 18, 2018 11:25 am
Posts: 43
Location: Hampshire, UK.
It did make me wonder how minimal one could go. I agree that subroutines are important, but I think that it could be possible to omit the Link Register by employing an idea from a RASP machine (https://en.m.wikipedia.org/wiki/Random-access_stored-program_machine).

The calling routine first stores the return address in the subroutine's last command, i.e. "JMP return_address”.

I am at a loss to understand how they might implement any of the ALU’s logical functions by a look-up table.


Tue Dec 18, 2018 10:41 pm

Joined: Wed Apr 24, 2013 9:40 pm
Posts: 213
Location: Huntsville, AL
A very interesting concept. In some ways similar to a move architecture, but purer since it lacks normal ALU structures behind the address regions.

_________________
Michael A.


Wed Dec 19, 2018 12:38 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1803
B.Bibby wrote:
The calling routine first stores the return address in the subroutine's last command, i.e. "JMP return_address”.

Mmm, not quite so general, but might do the trick. It rules out certain patterns of calls: you can't have a subroutine directly or eventually calling itself. But then, even though the Minicomputer as described does have a link register, it's hard to imagine they could arrange a stack very readily. In fact I wonder if the link register is only able to provide for one level of subroutine - so, it's useful for the leaf routines and makes them cheaper to call, but any other call might well need to do something like your description. (I've previously come across the Wheeler Jump, which is slightly different: the caller modifies the first instruction of the subroutine then jumps to the second. The subroutine exits by jumping to (or through) its first word. There must be pros and cons to both ways.

Quote:
I am at a loss to understand how they might implement any of the ALU’s logical functions by a look-up table.

Yes, I can't quite see it. It's remarkable enough that they add by repeated increment and decrement. Maybe we can get some insight by studying the stats they give for some subroutines:
Attachment:
Screen Shot 2018-12-19 at 21.12.49.png


For example, an 8-byte table to test a bit: that's 16 nibbles, which means you can map from a nibble to a nibble. Still don't quite see how that helps... I suppose with the shift operation, you could always arrange to test bit 0, in which case you use your nibble map to return either a zero or a non zero for each of the 16 values of input. That could work. To test bit 2 you need first to shift twice.

BTW there's an adjacent paper which turns out to be unrelated: Hooper's The minicomputer, a programming challenge - so don't read that as I did, hoping for related insights.


You do not have the required permissions to view the files attached to this post.


Wed Dec 19, 2018 9:25 pm
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Although it's already been posted on this forum, my one-bit computer seems relevant to this thread, both by virtue of having no ALU and because of the discussion upthread about primitive subroutine mechanisms. See One-bit Computing at 60 Hertz (and also the anycpu.org posts here).

-- Jeff

Quote:
In the printing press application, one of the memory bits [ the total RAM comlement is only 2 bits! ] is used to guide subroutine returns. There are two main parts to the program, and they share a few subroutines. At the exit of each subroutine, a memory bit (previously prepared by the caller) is tested to see which of two return addresses to jump to.

_________________
http://LaughtonElectronics.com


Sat Jan 26, 2019 5:17 pm WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1803
A very nice idea and well-executed! I was about to make a particular comment but I see I already made it over in the thread you linked to...


Sat Jan 26, 2019 5:34 pm
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
:) Thx, Ed.

One contrast with the IBM machine is the IBM's "experimental" designation. My machine did real work (albeit at only 60 Hz :roll: ) for an actual client.

Although it wasn't experimental, I admit it *was* a lot of fun! :mrgreen:

_________________
http://LaughtonElectronics.com


Sat Jan 26, 2019 6:27 pm WWW
 [ 8 posts ] 

Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software