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...