Hello,
I just rushed through the F-CPU architecture guide and this is what I think looks ok to me. The existing command set looks pretty reasonable. When trying to figure out how easy is would be to write a software emulator for the impatient (like me ;) I came to the conclusion that the opcode flags could be on a fixed positions thus making hardware and software design a lot easier:
Field type |
Position in instruction |
Size in bits |
Instruction select |
0 |
5 |
Instruction format |
5 |
2 |
- reserved - |
7 |
1 |
Flag type |
Position in instruction |
Size in bits |
operand size |
8 |
2 |
hl (SIMD packing) |
8 |
1 |
loadcons shift |
10 |
1 |
endianess |
10 |
1 |
no IEEE req'd (float) |
10 |
1 |
operation subselect |
10 |
4 |
SIMD packed |
11 |
1 |
shift direction |
11 |
1 |
negate 2nd operand |
12 |
1 |
none/zero/sign extend |
12 |
1 |
signedness |
13 |
1 |
rounding mode |
14 |
3 |
The architecture guide was far from answering all questions of mine, but I couldn't wait any longer. So the next thing I've done is to put the instructions into an opcode table a way I think the hardware can be realized quite easily, and I added a few instructions in case someone of you might want them. They're marked with an asterisk (*). Many rows could be handled by single ALUs for the according operations - just fed differently using format flags: (Commands using subselects got braces)
F3 |
F2 |
F1 |
F0 | |
00 |
(add/sub) |
(addi/subi) |
nop* | |
01 |
mul |
muli |
||
02 |
div |
divi |
||
03 |
mod |
modi |
||
04 |
shift |
shifti |
||
05 |
rot |
roti |
||
06 |
load |
loadi |
loadcons |
|
07 |
store |
storei |
loopentry |
|
08 |
test |
testi* |
||
09 |
(logic) |
(logici) |
||
0a |
mov |
|||
0b |
mix |
expand |
||
0c |
(get/put) |
(geti/puti) |
||
0d |
syscall |
|||
0e |
trap |
|||
0f |
halt |
|||
10 |
jmpa |
jmpr |
||
11 |
calla* |
callr* |
||
12 |
jmpi |
rfe |
ret* | |
13 |
int* |
|||
14 |
in* |
ini* |
||
15 |
out* |
outi* |
||
16 |
blit* |
flushg |
lock* |
blitwait* |
17 |
mset* |
preftchu |
unlock* |
|
18 |
(fadd/fsub) |
(faddi/fsubi)* |
||
19 |
fmul |
fmuli* |
||
1a |
fdiv |
fdivi* |
||
1b |
fmod |
fmodi* |
||
1c |
finv |
|||
1d |
fsqrt |
|||
1e |
finvsqrt |
|||
1f |
(int2f/f2int) |
I really missed 'call' and 'ret' as well as port instructions (in,out) to use existing motherboards and chipsets. The advantage of doing so would be *BIG* because an emulator would help the programmers to set up software even before any hardware was realised. A lock command that'd just switch to the next task until it's unlocked the next time it's executed (using a ref. counter) would be great, too...and then it came to my mind that programs sometimes need to blit huge amounts of data. As far as I know SUN implemented blitting operations that work in the backround. (blit for logical ops, mset for stupid fills and blitwait if someone has to)
Will there be register/task/memory/io maps? I got the impression that much cache would be a good way to handle potential bottlenecks...I mean no one needs to access register maps (except setting up tasks?) if one has to, why not force him to use the flush command. Maybe the bit left in the opcode could hold a probability value?
Anyway, there're so many opcodes left that including more floating-point or vector instructions or anything else that is supposed to increase graphics speed or size of paychecks ;^) etc should be no problem later on. I say "later on" because getting the basics sorted will take ages anyway, and we're still talking about RISC, aren't we? :^)
This is a fantastic project and I believe that there'll be a nice processor coming up. I won't bother if it's not the fastest available - because it'll be free. A dream going to come true. So thats it. I hope this little contribution helped a bit and I'd like to do some more (like that software emu I was talking about).
btw.: if you need netspace (web/commercial free mailing list or things like that) just state your needs, we got enough left at dev/con.
Best regards,
Sven Klose.
p.s.: Nathaniel Downes' and Aidan Kealy's mail links are broken...