Make your own instruction set for your own made up processor. How many bits can it access? What kind of tasks will it be used for? Bonus points for making an implementation in sepples, FIOC, lisp, or other GENERAL PURPOSE SCALABLE COST-EFFECTIVE ENTERPRISE QUALITY PROGRAMMING LANGUAGES(such as java)
My processor shall contain a single memory location, BUFFA, and its instruction set shall support the following primitives: a, b, c, d, r, n, $, | and ;.
It can be used for any imaginable computation.
Name:
Anonymous2008-11-29 19:17
>>4
That seems oddly familiar... [spoiler]Are you that guy from that thread?[spoiler]
aLANGUAGEis onlyturingCOMPLETE if it can implement itself.
Name:
Anonymous2008-11-29 19:35
subtract and branch if negative bitch.
Name:
Anonymous2008-11-29 19:43
My instruction set would include the ability to create classes and subclasses, and duck typing will be enabled by default. Everything would be an object. The code would need to be indented one tab for everything, except branches. If you don't indent properly, the program will throw an exception (Yes, my instruction set includes throwing exception capabilities).
If the community (Yes, my instruction set would be super popular and the website for it would have forums and a chatbox so that the community can decide, Instruction Set 2.0, if you will) wants Monad support, I will add support for monads too.
Name:
Anonymous2008-11-29 20:00
>>8
That would make one damn expensive processor. my instruction set will only contain addjump and and.
Name:
Anonymous2008-11-29 20:06
Mine will be a complete implementation of ANSI sepples. only entirely interpreted.
Name:
Anonymous2008-11-29 20:08
AnonX86 will fully conform to the IA32 standard, ignoring the stuff about multibyte instructions. Also, registers will be dynamically sized to hold whatever the user enters, rather than enforcing archaic hard-coded limits. It will run faster than the bloated Core2 and be implemented in only 7 transistors.
Name:
Anonymous2008-11-29 20:37
Mine will be completely based on interrupts, where everything is an interrupt.
>>11
I've always wondered what it'd be like to write code for a processor with bit-level variable-length instructions. You could pick the opcodes of the most common instructions to be the shortest, and the least commonly used to be the longest.
Name:
Anonymous2008-11-29 22:51
>>14
Your C compiler for this CPU would look like ass
My dream processor is a CPU with an insane number of cores, like 2048 or 4096, that are however extremely simple and can be dynamically combined in any way.
Each core has something like 8 local registers, and 8 "addressors." Each instruction targets an addressor, further instructions can determine whether this addressor is connected to a local register of that core, a local register of another core, cache RAM, external RAM, or I/O space.
One addressor is always connected to a local register. This is known to the core as the accumulator, or A. Another is always zero and is known to the core as Z.
The operations on each core are extremely simple, like only: OR, XOR, AND, NAND, INC, DEC which perform the operation on 2 addressors and send it to a third. Each instruction can be performed either unconditionally, or only be performed if another addressor is 0. A third modifier determines how the core gets its next instruction; either the address specified in an addressor or the address pointed to by an addressor. Such address is optionally incremented after control is passed to it.
The bit width of the addressors determines the maximum addressable memory space of the CPU.
Operands can be an addressor or immediate data.
Addressors are written as A0-A7. Accumulator is just A.
So you have basic op OR, XOR, AND, NAND, NOT, INC, DEC + 3 operands, optional conditional specifier, and next instruction modifier.
OR.A3z[A4] A0,A1>A2
OR addressors A0 and A1 and send result to A2 IF A3 is zero, get next instruction from addressor A4
DEC[A4] A2>A3
Decrements addressor A2 and sends it to A3 unconditionally, get next instruction from addressor A4
XOR[@A4] A5,A6>A
Exclusive OR's addressors A5 and A6 and sends result to accumulator. Fetches value pointed to by A4 and gets next instruction from it
JUNCT A3>resource,which_of_resource
Junctions a addressor to a resource. Resources are implementation dependent but 0 is always core local registers. 1 may be RAM, 2 may be I/O space, etc.
JUNCT A3,0,3
Connects addressor A3 to local register 3.
JUNCT A3,1,2205
If 1 represented system RAM, A3 is now connected to it.
JUNCT A3,4097,2
If 4097 represented core #2's register set, A3 is now connected to core #2's local register 2.
SP
Sets protection mode. A lower-numbered core cannot connect local registers to this core.
CP
Clears protection mode. Any core can connect local registers to this core.
Synchronization between cores is achieved by connecting a register or two to local registers of other cores
My instruction set would include support for matrices. And in addition to the regular registers, there will be matrix registers (3x3 or 4x4) and matrix operations built in.
Name:
Anonymous2008-11-30 0:09
My instruction set would include instructions for generating rounded corners and stripping the last vowels out of strings.
>>36 case A: for(i=0,w=0;i< W_SIZE;i++){if(dm[i])w+=1<< i; dm[i]=false;}; pc++;break;
I don't GET IT
Name:
Anonymous2008-11-30 20:12
Instruction set: S, K.
Bits: limited only by available RAM, but you've got to implement Peano arithmetic first.
Tasks: computation.
Implementation: only shit languages need a software implementation. Real languages like SK combinators can be evaluated on pen-and-paper.
Name:
Anonymous2008-12-01 1:07
The ultimate processor needs only a single instruction: YHBT
Name:
Anonymous2008-12-01 1:29
As fortune would have it, I already have one at hand:
BBW Branch Both Ways
BEW Branch Either Way
BH Branch and Hang
BMR Branch Multiple Registers
BOB Branch On Bug
BPO Branch on Power Off
BST Backspace and Stretch Tape
CLBR Clobber Register
CLBRI Clobber Register Immediately
CM Circulate Memory
CMFRM Come From
CPPR Crumple Printer Paper and Rip
CRN Convert to Roman Numerals
DMPK Destroy Memory Protect Key
DO Divide and Overflow
EPI Execute Programmer Immediately
EROS Erase Read Only Storage
HCF Halt and Catch Fire
IBP Insert Bug and Proceed
INSQSW Insert into queue somewhere (for FINO queues [First in never out])
PDSK Punch Disk
PI Punch Invalid
PVLC Punch Variable Length Card
RASC Read And Shred Card
RTAB Rewind tape and break
RWDSK rewind disk
SPSW Scramble Program Status Word
WBT Water Binary Tree
a set of 256 stacks, shared between 16 cores.
each stack element is 128 bits, and can be used as the real and imaginary parts of a complex number (64-bits each), a single 128-bit signed integer or floating point value, or a machine instruction. each core pops and executes the instruction on top of it's instruction stack, which is stack 0 for core 0, stack 1 for core 1, etc. the instruction set is as follows: 0x00000000 000000xx 00000000 00000000
clear x removes all elements from x (stack). 0x00000001 000000xx yyyyyyyy yyyyyyyy
drop x y removes the top y (64-bit unsigned integer) elements from x (stack). 0x00000002 00xx00yy zzzzzzzz zzzzzzzz
cdrop x y drops the top z (64-bit unsigned integer) values from x (stack) if the top two values on y (stack) are equal, otherwise does nothing. the top two values on y are popped and discarded. 0x00000003 00xx00yy zzzzzzzz zzzzzzzz
move x y z copies z (64-bit unsigned integer) elements from x (stack) to y (stack). 0x00000004 00xx00yy zzzzzzzz zzzzzzzz
copy x y z copies z (64-bit unsigned integer) elements from x (stack) to y (stack). 0x00000005 00xx00yy 00000000 00000000
swap x y swap x (stack) and y (stack). 0x00000006 000000xx yyyyyyyy yyyyyyyy
dup x y duplicates the top y (64-bit unsigned integer) elements on x (stack). 0x00000007 000000xx yyyyyyyy yyyyyyyy
rot x y rotates the top y (64-bit unsigned integer) elements on x (stack). 0x00000008 00xx00yy zzzzzzzz zzzzzzzz
uadd x y z pops and sums (as unsigned integers) the top z (number) elements from x (stack) and pushes the result onto x. if an overflow occurs, pushes the value 1 onto y (stack), otherwise pushes the value 0 onto y. 0x00000009 00xx00yy zzzzzzzz zzzzzzzz
usub x y z like uadd, but with subtraction instead of addition, and underflow instead of overflow. 0x0000000A 00xx00yy zzzzzzzz zzzzzzzz
umul x y z like uadd, but with multiplication. 0x0000000B 000000xx yyyyyyyy yyyyyyyy
udiv x y like uadd, but with division, and no possibility of underflow or overflow. 0x0000000C 00xx00yy zzzzzzzz zzzzzzzz
sadd x y z like uadd, but with signed integers instead of unsigned. if an underflow occurs, -1 is pushed onto y. 0x0000000D 00xx00yy zzzzzzzz zzzzzzzz
ssub x y z like usub, but with signed integers. if an overflow occurs, -1 is pushed onto y 0x0000000E 00xx00yy zzzzzzzz zzzzzzzz
smul x y z like sadd, but with multiplication. 0x0000000F 000000xx yyyyyyyy yyyyyyyy
sdiv x y like udiv, but with signed integers. 0x00000010 000000xx yyyyyyyy yyyyyyyy
fadd x y like sadd, but with floating point numbers instead of signed integers and no possibility of overflow. 0x00000011 000000xx yyyyyyyy yyyyyyyy
fsub x y like ssub, but with floating point numbers and no possibility of overflow. 0x00000012 000000xx yyyyyyyy yyyyyyyy
fmul x y like smul, but with floating point numbers and no possibility of overflow. 0x00000013 000000xx yyyyyyyy yyyyyyyy
fdiv x y like sdiv, but with floating point numbers. 0x00000014 000000xx yyyyyyyy yyyyyyyy
cadd x y like fadd, but with complex numbers instead of floating point numbers. 0x00000015 000000xx yyyyyyyy yyyyyyyy
csub x y like fsub, but with complex numbers. 0x00000016 000000xx yyyyyyyy yyyyyyyy
cmul x y like fmul, but with complex numbers. 0x00000017 000000xx yyyyyyyy yyyyyyyy
cdiv x y like sdiv, but with floating point numbers. 0x00000018 000000xx yyyyyyyy yyyyyyyy
and x y pops the top y (64-bit unsigned integer) values from x (stack), performs a bitwise AND on them, and pushes the result onto x. 0x00000019 000000xx yyyyyyyy yyyyyyyy
or x y like and, but with OR instead of AND. 0x0000001A 000000xx yyyyyyyy yyyyyyyy
xor x y like and, but with XOR. 0x0000001B 00xx00yy zzzzzzzz zzzzzzzz
pushm x y z pops a memory location from x (stack), and pushes z (64-bit unsigned integer) values at that location onto y (stack). 0x0000001C 00xx00yy zzzzzzzz zzzzzzzz
popm x y z pops a memory location from x (stack), then pops z (64-bit unsigned integer) values from y (stack) and stores them at that memory location.
Name:
Anonymous2008-12-01 3:07
>>43
Did you give any thought to synchronization at all? How are you supposed to do process management and content switches when your code's on a stack?
Name:
Anonymous2008-12-01 4:38
>>43
i'm not sure what you mean by "content switches"... and how would having the code on a stack possibly make it any more difficult? are you one of those people who doesn't understand stacks?
Name:
Anonymous2008-12-01 5:17
>>45
*context switches, but never mind. I was thinking the stacks would use memory at a fixed location, which doesn't need to be the case. Though then it'd be harder to cache the top of each stack in core registers, without which it'd run like a slow ass.
And while you're wasting bits on stack element count, literals and offsets seem ignored to such a degree that even basic memory access requires elaborate trickery. Slow, slow, slow.
To further assert my belief that the ISA is far too stacky, I shall now commit the fallacy of guilt by association;
You know who else uses stacks? That's right, Java does! And if he were alive, why, Hitler would as well. Nothing like pushing on a couple of jews with your good friend Qosling and popping them into the ovens, is there, you fucking Nazi‽
Though then it'd be harder to cache the top of each stack in core registers, without which it'd run like a slow ass.
it makes a lot more sense to have a large (maybe about 64MB) cpu cache to hold all of the stacks. 16384 128-bit stack elements per stack should be more than enough for most purposes. and you'd only need 28 128-bit registers to hold all the stack element counts. since we're talking about made up processors, why not have, say, 512 registers? that'd be plenty to cache the top few elements from stacks that are used a lot, and even elements that aren't cached in registers would be pretty fast to access since they're always in the cpu cache. certainly a lot faster than a machine with fewer than 32 registers.
also, read this: http://en.wikipedia.org/wiki/Burroughs_large_systems#Stack_speed_and_performance
literals and offsets seem ignored to such a degree that even basic memory access requires elaborate trickery.
yeah, sure, adding numbers is "elaborate trickery". and literals aren't ignored. literals can be handled like so (puts four literal values onto stack 16): move s0 s16 4
.data ( 0x48000000650000006c0000006c
0x6f0000002c0000002000000057
0x6f000000720000006c00000064
0x21000000000000000000000000 )
>>11
Dynamically sized registers are tricky to implement in hardware, since each bit in the register corresponds to a digital circuit, so you could say, that all resources in a CPU are preallocated(once you decide what they are, they become a fixed number of cells when synthethized). So effectively, you'll have to compromise to a maximum register size such as 32,64,128,... If you'd want to have more than the default, you'll need to emulate the operations(for example using some specific microcode and some RAM), this will probably end up incredibly slow, and the additional needed circuitry would pobably lower the speed, that said, most of Intel's CPUs(including the Core2 line) are quite the custom design where everything is hand optimized to achieve the needed performance, and it's quite unlikely (if not almost impossible) you can make something given your specs, similar to the complex x86 CPU and get better speeds than Intel, if you use the same manufacturing tech. You could achieve better speeds with a much simplified RISC architecture w/ many optimizations, full custom design, and rely on a good compiler to generate fast code.
Name:
Anonymous2009-02-26 22:49
>>59
Yep. And my magic CPU would have a functional assembly (as hinted by somebody else above) with hardware garbage collection.
Name:
Anonymous2009-02-26 23:55
>>15
He meant variable bit-length instructions, not variable bit-length registers. Sort of like how offsets/lengths in plain LZ12/4 compression are always 12 and 4 bits, but the actual data is bit-level packed.
Name:
Anonymous2009-03-06 11:53
The Desert of Indentation Wars between the Guidans and THE peculiarities of each architecture down to a grinding halt?