Larry

From Esolang
Jump to navigation Jump to search

Larry (created by User:ArsenicCatnip) is a class of processor based on the works of Larry Tesler, inventor of the cut, copy, and paste commands. The basic idea behind it is that instead of designing an entire processor and figuring out how to connect all of the pieces, the designer starts with a Claaaaaaw containing a clipboard and a controller (which contains the program counter, program rom, peripheral selector, and clock), and the clipboard can cut, copy, and paste data from other pieces called peripherals. The designer gets to design the peripherals themselves without having to worry about how it communicates with other pieces, since all information is moved using the clipboard in The Claaaaaaw.

The computer is based on two specs: immSize and wordSize. wordSize is the size of the clipboard, and immSize is the size of data that can be loaded to the clipboard on a given command. The default values are wordSize=8 and immSize=4.

Various design information is found in this google drive folder, including example simulations, physical implementation guides, and a bill of materials. When this article is detailed enough and no longer needs to be expanded, most of the information on this google drive will be available in this wiki page [citation needed].

The Claaaaaaw

The Claaaaaaw requires the following pieces:

piece name type specs recommended piece(s)
clipboard register <wordSize> bits wide 74xx377 (x1)
program counter counter <wordSize> bits wide, has reset to 0 button, can load input address 74xx161 (x2)
program rom rom <2^wordSize> x <2+immSize> bits minimum (default is 256x6 bits minimum) AS6C1008 (x1)
peripheral selector decoder <immSize> bit select input with enable 74xx154 (x1)
buffer buffer <wordSize> bits with high-z deactive state 74xx244 (x2)
clock oscillator 1 bit output 555 timer (x1)
1uf capacitor (x1)
220Ω resistor (x2)
1MΩ potentiometer (x1)
led (x1)
slide switch (x1)
pushbutton (x1)


Peripherals

this list is incomplete, you can help by expanding it. You can expand it by creating your own peripherals and listing them here. Someone might eventually build a Larry processor using it.

program counter

!! The only required peripheral is the program counter.

action response
copy the clipboard gets the address of the copy instruction
paste the program counter jumps to whatever address is pasted to it, and the instruction at that address will be executed next, if and only if the Jump Enable line is active.
neither the program counter increments

The jump enable line can be tied active or inactive, or connected to another peripheral. All three options allow for Turing Completeness.

spare register

submitted by User:ArsenicCatnip. Implemented in simulation.

action response
copy the clipboard gets whatever data was last pasted to the spare register
paste the spare register gets whatever data is in the clipboard
neither the spare register retains its value

spare register but it might randomly catch fire

submitted by User:ArsenicCatnip. Not yet implemented.

action response
copy the clipboard gets whatever data was last pasted to the spare register, then the spare register decides at random whether to catch fire.
paste the spare register gets whatever data is in the clipboard, then the spare register decides at random whether to catch fire.
neither the spare register decides at random whether to retain its value or catch fire. It may do both but leading experts on Larry processors doubt anyone can make something like that. feel free to prove leading experts on Larry processors wrong.

Commands

Cut

The cut instruction left-shifts the clipboard by <immSize> bits, takes an immediate value that is <immSize> bits wide, and adds that to the clipboard. The instruction will likely look something like one of the following in assembly code:

  • cut <value>
  • X <value>
  • Some new numbers just came in. They're <value>. Go give 'em to the boss, he'll know what to do with 'em.
  • CUT <value>
  • ctrl-x <value>
  • LDI <value>


The order of events for a cut command is as follows:

  1. (also step 3 of previous instruction) Clock signal goes to active state
    1. (previous instruction is presumably executed)
    2. program counter points to the current instruction
    3. current instruction's machine code is loaded from the program rom
    4. all of the selector's select lines become inactive if they were not already
    5. The buffer is loaded with the last <wordSize-immSize> bits of the clipboard, concatenated with the given value. For example, let's say you're working with a Larry processor with
      • immSize = 16 and wordSize = 32
      • the clipboard contains 0xDEADBEEF
      • and the value you're loading is 0xF00D.
      • The value loaded to the output of the buffer will be 0xBEEFF00D
  2. Clock signal goes to inactive state.
  3. (also step 1 of next instruction) Clock signal goes to active state
    1. The clipboard's value is set to whatever is on the output of the buffer
    2. program counter points to the next instruction
    3. etc...

Copy

The copy instruction takes a peripheral name and copies its output value to the clipboard. The instruction will likely look something like one of the following in assembly code:

  • copy <peripheral name or index>
  • C <peripheral name or index>
  • Hey you! you see that value over there in <peripheral name>? The boss wants it. Get it for him.
  • CPY <peripheral name or index>
  • ctrl-c <peripheral name or index>
  • LDR <peripheral name or index>


The order of events for a copy command is as follows:

  1. (also step 3 of previous instruction) Clock signal goes to active state
    1. (previous instruction is presumably executed)
    2. program counter points to the current instruction
    3. current instruction's machine code is loaded from the program rom
    4. the selector changes the output so the given peripheral's copy select line is active. All other select lines are inactive.
  2. Clock signal goes to inactive state.
    1. At this point, the selected peripheral's output MUST be outputted to the copy bus.
      This can happen at any point between steps 1.4 and 2.1, but cannot happen before step 1.4. The output MUST be disabled before step 1.4 and after step 3.4.
      The only case where the output doesn't have to be disabled before step 1.4 is if the previous instruction is the exact same instruction as this one.
  3. (also step 1 of next instruction) Clock signal goes to active state
    1. The clipboard's value is set to whatever is on the copy bus
    2. program counter points to the next instruction
    3. etc...

Paste

The paste instruction takes a peripheral name and sends the value in the clipboard to that peripheral. The instruction will likely look something like one of the following in assembly code:

  • paste <peripheral name or index>
  • V <peripheral name or index>
  • The boss has a delivery to make. Send this value to <peripheral name>. Get it done by the next clock cycle or you'll lose more than just your job.
  • PST <peripheral name or index>
  • ctrl-v <peripheral name or index>
  • STR <peripheral name or index>


The order of events for a paste command is as follows:

  1. (also step 3 of previous instruction) Clock signal goes to active state
    1. (previous instruction is presumably executed)
    2. program counter points to the current instruction
    3. current instruction's machine code is loaded from the program rom
    4. the selector changes the output so the given peripheral's paste select line is active. All other select lines are inactive.
  2. Clock signal goes to inactive state.
  3. (also step 1 of next instruction) Clock signal goes to active state
    1. the peripheral does whatever it needs to do with the value. It should be done by now but really that's up to the peripheral. You could have a peripheral that *starts* a process when it has data pasted to it, then continues that process on successive clock cycles, even if it's not actively being selected for anything.
    2. program counter points to the next instruction (unless you just pasted to the program counter, in which case it will go to that address instead)
    3. etc...

No Operation

The no operation instruction allows a clock cycle to pass. The instruction will likely look something like one of the following in assembly code:

  • nop
  • NOP
  • This town is full of live ones, isn't it. The more they do the more we make. Maybe it's time to just sit back for a while. At least until the next clock cycle, y'know?
  • ctrl-

The order of events for a no operation command is as follows:

  1. (also step 3 of previous instruction) Clock signal goes to active state
    1. (previous instruction is presumably executed)
    2. program counter points to the current instruction
    3. current instruction's machine code is loaded from the program rom
    4. all of the selector's select lines are inactive.
  2. Clock signal goes to inactive state.
  3. (also step 1 of next instruction) Clock signal goes to active state
    1. etc...

Implementations

74Larry

This google drive folder contains a couple simulations and a few videos about a physical implementation of a Larry processor, called the "74Larry". It uses 74 series chips. It also includes an assembler and programmer for 74Larry.

Claaaaaaw for simulator.io

this link takes you to an implementation of a Larry Claaaaaaw on simulator.io, designed to be forked and used as desired.