Memory-mapped devices

[Twisol]

Hallo again!

This set of commits covers mapping external devices into CPU-accessible memory. The most obvious change here is the removal of the GET opcode. In order to accept input, all that's needed is a device mapped into memory with a get callback.

With the removal of GET, I've modified the demo to mount a non-standard input device at 0x7FFF (that is, one word before the output device).

cpu.mapDevice(0x7FFF, 1, input);

To use this device, just use SET A, [0x7FFF] to read a character into the A register. To place it straight into the output region, you can use SET [0x8000], [0x7FFF].

I suspect this will be exactly how networking and other peripherals will be done in 0x10c itself. (I mean, Notch is already using a memory-mapped device for his screen...)

[mappum]

Sweet. And again, thank you.

Time to map some sweet non-standard things (pubnub networking for multiple CPUs?

[Twisol]

How about /dev/rand? :)

var dev_rand = (function() {
  var max = 2;
  return {
    get: function(idx) {
      if (idx === 1)
        return max;
      else if (idx === 0)
        return Math.floor(Math.random()*2);
    },

    set: function(idx, val) {
      if (idx === 1)
        max = val;
    }
  };
})();

cpu.mapDevice(0x7FFD, 2, dev_rand);

[Twisol]

Something I really really want to try next is make device reads asynchronous. That would allow for things like waiting on user input, and even things like message queues (which Notch was talking about too). Basically the CPU would need to pause on an instruction while it waits for the input. I think the gains would be enormous though!

[mappum]

Are you sure we shouldn't store values written to device mapped memory? How you have it currently, they just stay at 0, but onSet is called.

[mappum]

Nevermind, I forgot they have a get callback, too. I'll change the text dump to indicate what is mapped, because it doesn't make sense to show a bunch of 0's that aren't used.

[Twisol]

I don't particularly see the utility of storing values at onSet, and if it's a dual read/write word, there's nothing stopping what you get back being different from what you put in. A network device would be a good example - you can both read and write to it, but what you get out of it is almost certainly not what you put in (unless you're talking to an echo server).

[Twisol]

Careful! Reading from the devices at memory-mapped locations is only safe if the read is idempotent. But with input devices and network devices (and my example random device), one read can and will affect the next.

I would tread very carefully here.

[mappum]

I wonder when someone will write TCP for this. At the speed that all these resources are being developed, it should be within the next few days,

[Twisol]

Unless Notch plans on implementing unreliable connections - okay, it's possible - I'd rather use UDP. Much simpler packet structure.

[mappum]

I don't mean I will display what is in the device addresses, I will just indicate that it's not just normal empty memory.

[mappum]

I have a joke about TCP for 0x10c, but you wouldn't get it.

[mappum]

I feel like this conversation is semantically wrong to be on a Pull Request discussion. Maybe we should communicate elsewhere?

[Twisol]

I'd message you some contact info, but GitHub says I can't (apparently you haven't given them an e-mail address). We could requisition #0x10c on AfterNet.