Projects

F-CPU

F-Mainboard

F-Tools

Communication

Mailing lists

IRC

Forum

Administrative

Groups & Teams

Voting List

Misc

Design

Developement Principles

FAQ

Old Arch

Original website

f-cpu forum

This is a forum where anybody can comment on the evolution of the f-cpu. The presence of an email will give more credibility to your intervention. If an idea it will might integrated, other idea might end up in the reject category (we'll try to justify why).

64 bit RISC-like
64 registers
32 bit instructions

Post a comment Read the rejected ideas Read the jutifications

Idea from Adam DePrince about "Register Windows?":

The large number of proposed registers may slow context switches. Perhaps the use of register windows (aka Sparc) could help compensate for this delay. I don't belive many are nessesary, we could get along with as few as two. During a context switch execution could begin in the freshly loaded register set while the "old" set is concurrently written to memory. After the old set is discarded we could speculatively load a new set. Which register set is speculatively loaded could be determined automatically or programatically. A copy of kernel registers can be kept around or the next process in the run que could be kept around. This would eliminate load delays for correctly predicted context switches.

Opinion from Adam DePrince about "Instruction Length":

The only reason I can see for long length instructions is to support explicit parallelism via VLIW style instructions (i.e. lots of parameters). Personally I think that the ease of implementation offered by fixed sized instructions and the only minor inconvenience of using memory mapped devices for more complicated operations (VLIW, float) outweights the increased complexity of variable sized instructions. Do we really want to have to support byte aligned jumps?

Opinion from Jeff Davies about "Architecture":

TTA seems to have disappeared off the project,

and I can see the point now that the GNU C++ compiler

cannot in it's standard form optimise the register usage

as the registers are not general purpose.

The M2M architecture would suffer the same problem wouldn't

it? (i.e. would the compiler be able to optimise data cache

pages without significant mods?).

Surely other complex register arrangements (register pages) would

suffer from the same fate.

This leaves a basic rather boring (but proven) RISC architecture.

However, perhaps f-cpu would benefit from as much full speed L1 cache

as possible (this is what AMD are doing).

Opinion from Tony Lovatt about "Instruction Set":

Interesting concept. I like the idea of a free/open hardware platform. Development on an FPGA seems like a good idea, too. Mind you, I'm a programmer, not a hardware designer, so my opinion isn't worth much there.

On the instruction set, though, I have rather more to say (and this bears on such things as the register set, too.) It looks to me like you took a basic Intel architecture, threw away the special-purpose stuff, and hit the rest with a big hammer. I have to say that I don't like the results.

Three-operand instructions? Yeuck! Seriously general-purpose, sure, but the sort of thing that hardware designers do who don't really know how it's going to be used. Check out the Motorola 6800/68000 series for a well-designed instruction-set. They profiled real, working programs, and optimised the instruction set to make the common ones easy, small and fast. The ones that don't get used very much at all, they left to be done by multi-instruction sequences.

Things that are done a LOT in software (and the instructions or modes required to support them) are:

1) Scanning tables or blocks - autoincrement/autodecrement addressing modes.

2) Addressing structures - index registers and offset addressing.

3) Stacks - STACK and POPSTACK instructions (that is, unless you implement a stack machine entirely - they can work really well.)

4) Subroutines and blocks - CALL and RETURN instructions (you need a stack for this) also MARKSTACK to allow parameters to be passed.

5) Linked lists - indirect addressing, and HEAD (CAR) and TAIL (CDR) instructions.

6) Applying identical operations repeatedly to lots of memory addresses - hardware registers.

You've got yourself a nice, simple, general-purpose instruction- and register-set there. And to make it work at all efficiently you're planning to make the CPU MORE THAN HALF CACHE!! With as much thought devoted to the design of the instruction set as you've put into the hardware, you could end up with a smaller (although more complex) CPU that is easier to program and more efficient. Think about it.

Opinion from Jeff Davies about "Profiling of code":

We talked a lot about profiling code on the discussion database in order to optimise the CPU.

It is possible to profile the kernel using the debug mode when compiling it, and gprof from the GNU Tools,

this only gives subroutine level information though. Someone would need to run an emulator or a CPU in single step then

exception mode in order to capture all instructions (including operands to check data size) to a disk file.

This disk file could then be analysed.

Note however, that 68000 were probably profiled to run very very different programs to the GUI programs we run today.

I think there may be a considerable difference in the profile between a CPU running with hardware graphics accel and

without. I think the profiling should be done, but not for F1. An agreed benchmark program will be good enough proof that the

thing runs ok, and getting something out before too long is crucial to maintain momentum on the project.

Idea from Moshe Vainer about "Memory access speed":

First a disclaimer:

1. I am a software eng, and never done

anything related to hardware,

so my opinion may be a complete

bullshit.

2. I think it is more related

to the MB design than

to the CPU itself so...

After upgrading my PC at work from Pentium 166

to a new 330Mhz Pentium II, i have noticed, that

although the clock speed was twice as fast,

and a CPU itself was a generation ahead, the

speed gain was not as significant as one might expect.

It occured to me that a slow bus, and a slow access

to memory don't let the cpu to work at it's full load.

A rather simple idea might solve this:

Put a bank of memory Simms,

A fast distributing chip (acting more or less

as an ethernet switch), put this chip

where Level-2 cache is usually located.

Let's say that we run a cpu at 400mhz,

and each simm is capable of 100mhz,

you could easyly use 4 simms, to achieve

a full 400mhz!.

This idea is so obvious, that it was probably

tried already and for some reason rejected,

but anyway....

from about "":

Opinion from F. Javier Mesa about "Some things that needed to be cleared up in this list (from what I have read so far)":

I have seen all these opinions so far, and I am a bit disturbed. Specially since most of the people making the comments are software guys =).

Couple of things I think I had to clear up:

1. VLIW: It does not imply variable instruction length or multiple parameters. Basically VLIW is a cluster of 2 or more RISC instructions put together. The width of the VLIW 'word' is actually fixed, for example a 128bit VLIW inst is actually 4 32bit smaller inst packed together. So the way to think of VLIW is as a 'compiled' superscalar architecture. In normal

super scalar desings that are able to issue several insts at the same time, usually the hw is the one in charge of issuing unrelated instructions to fill up the parallel pipelines (for the several execution units). VLIW does the same thing, but it leaves all the burden to issue several unrelated or independent instructions at the same time to the compiler. I think superscalar will always be superior, since it allows for dynamic scheduling of best combinations of independent instructions, VLIW on the other hand does not quite allow this flexibility, since it is all done at compile time. However, VLIW is easier to implement, since 'smart' HW is expensive in real state on chips, however 'smart' compilers are usually a generation behind than hw. I agree that variable instructions are a big no no. RISC is the way to go, and a CISC approach like the VAX is really difficult to implement in HW, specialy with mostruous differences in inst lengths, make aligning a nightmare on the HW desig side.

2. Register Windows: YES, YES! I think this is a must, since it allows for really fast context switching. However only 2 is not the way to go, since misses in a predictive load would be very costly, you have to flush 2 full register windows, with a penalty double of the non windowed approach. I think sparc V.9 has a very elegant way of keeping its windows happy, I forgot exactly how their approach works, but it is fully documented, and we could take their approach. I think that Sun guys had more means to reach an optimal solution, so we don't have to reinvent the wheel. Register windows are a great performance boost, alveit very expensive in real state on the chip. But they really make the difference when dealing with interrupt servicing, specially when reentrant functions appear (this is very useful for real time systems).

3. Instruction Length: First M68000 is anything but elegant. Efficient with little memory, yes, but elegant nope. The design of such CPU would be too hard, since the multiple addressign modes and instruction length make the pipelining and super scaling of the hw that implements that CISC instruction set a nightmare. It can be done, as intel did with x86, however it is really nasty. The f-cpu does not quite look like an intel design, if anything it looks too MIPSy to me (my favorite architecture!). Which is the most elegant isa you'll ever see. What is wrong with 3 operand instructions? We don't want to deal with memory to memory instructions, do we? This is not the 80's anymore and memory is cheap. Besides the desing has to be as simple as possible, and dealing with the non uniform access times of mem to mem ops would be an overkill, when register to register ops do the job quite good. I don't actually know why it is strange that most of the real state in the chip is actually cache, in most new CPUs the highest transistor count is dedicated to the cache/register files.

I am however in favor of 64bit instructions, not 32bits. So far the design looks like a 64bit R3000 to me, and I would like the design to be as irreverent as possible. With 64bits we could have larger OpCode fields, that allows for a larger ISA, and include extra cool ops for gfx or multimedia, or simply allow growth room for future instructions that people can think of. I would also like to see support on the HW for multiprocessing, like communication hooks, and that would requite instructions that have estra information fields. For example, I can think of an parallel add in which we could have 4 fields, reg1, reg2 (operands) reg3 (destination register) pointer (points to which processor's reg3 the information is sent to, it doesn't have to be a register in the local processor). I know this is an open flame, I am not saying that in any way that instruction is any efficient, but something of that short. Also I would like some short of vector instruction. I think that if we are going to design a CPU for Linux, and most of the linux community is somehow related to scientific environmnents. But then again, that might be an overkill.

Just my 2 cents.......

Opinion from Peter P. Eiserloh about "instruction width":

There is no need for 64 bit instructions. Why would

anyone want that many instructions, we already have

an 8-bit opcode allowing 256 different opcodes, of

which we currently have defined 39 (as of draft 0.19990608)

Lots of growth potential.

The F-CPU does not look like an intel processor.

MIPS maybe, but the since the FCPU teams closest

thing to a 'bible' is Hennessy & Patterson's

"Computer Architecture: a Quantitative Approach",

I imagine that it looks more like a DLX processor

than anything else. But since their research led

to the development of MIPS, they are very similar.

Peter

Opinion from Josh Fender about "Vector Processing":

First off I'll just say I'm not 100% familar with your project but just from the short trip here and viewing of the forum I figured I'd add my bit.

Some people seem to be leaning towards vector processing or other "multimedia" flavours. I believe that these are important parts for fast processing but should not be including in the cpu core.

The Nintendo 64 is a good example of this. The N64 has a MIPS processor running the core but slaves off alot of work to a secondary vector processor using a highspeed Rambus.

This solution executes very quickly providing limited advantages to placing the vector functions directly in the core. Because of this I think it would complicate things to much to include such things. Instead I would suggest designing a chip that had facilities to handle highspeed transfers to coprocessors and only focus on a tight, and fast, instruction set.

Well I must admit I didn't say much but thats my opinion.

Opinion from Ryan about "RAID like RAM striping":

I know that I really don't belong on a page like this {Because

I am neither I Engineer nor a Programmer-I am a High School

Student :-} } But the Idea with the RAM acting as L2 cache

seems a good idea. It would allow good scalability of

proccesing power {note: 5 100mhz DIMM's would not actually

allow 500mhz FSB} But the nice thing about striping the data across

the RAM is that you still have full access to all the RAM

i.e. you have 5 128Meg sticks you still have 640 Megs at your beck

and call. Because the data isn't copied to every stick of RAM

It is just copied piece by piece to each different one.

I think that that is a VERY good idea.

Just my $.02 Ryan

Opinion from Marko Schuetz about "'An Architecture for Combinator Graph Reduction'":

I recently found this on the net at

http://www.cs.cmu.edu/~koopman/tigre/index.html.

My opinion is that with the increased popularity of

functional languages it would be a very good idea to

examine the design from this perspective and to make

sure that the minor requirements for efficient excution

of combinator graph reduction are indeed provided by the

cpu.

Marko

Idea from Rares Marian about "Cache hit booster.":

Disclaimer: I'm just a guy who gets ideas and I have a

taste for architecture.

I'm thinking of inverse operations. For example you have

a thread that does a lot of reading and you have another

thread that does a lot of writing.

I think the instructions cached from one thread should in

some way be cache hits for the other thread.

1. Some or all of the encoded instructions should be given codes like:

#define write 0000

#define read FFFF

2. Sequenced pairs on the way in.

3. Straight on the way out.

Two ways:

Optimize read operations:

cache write

cache-----(sequencer)----(splitter)--------cache read

************|*******************|

************|--------(xor FFFF gate)

Pros: Hit doubled (maybe).

Common sense says that opposite operations are the farthest

from each other. Also they may also occur more often.

New coding methodology: easy inverse functions, backtracking,,

application code half as large because most functions might

be reversible. Encryption code would benefit greatly.

Opitimize cache writes:

cache read

cache-----(sequencer)----(splitter)--------cache write

************|*******************|

************|--------(xor FFFF gate)

Cons: Cuts your memory in half.

Opinion from Rares Marian about "Multithreading/processing/tasking needs help":

Threads need to be able to bounce from processor to

processor easily.

Also locking mechanisms wreak havoc on interactive real-time

operations when say the harddrive is busy.

Spinlocking works but you have to be careful you don't

endanger data integrity.

Idea from Jeffrey Blumstein about "F-CPU ISA":

I should state first that I am only just starting in computer engineering, but I have some ideas about the Instruction Set Architecture for the F-CPU:

1) I notice that you don't use Instruction Format 4 in arithmetic, logic, or store/load operations. As I see it, you need these instructions in a Format 4 type. What If I just want to load immediate value 0xAAAA into $1 (In MIPS this is "li $1,0xAAAA")!? This requires a 16-bit immediate format for load: "li $register, imm16", and if I just want to add a 16-bit immediate I need "addi $register, imm16", and some logic, like "ori $register, imm16"

2) I don't see any organization in the register file, I mean if you're gonna have a working processor, you need to specify which registers can be used only by which parts of a system. For example: let 0-31 be integer registers ($0 always contains 0), and let registers 32-63 be floating point registers. Give the OS a few reserved registers. Allocate some temporary registers, some argument registers, and some return registers. It doesn't have to be this way, but without a standard organization to the file, you end up with applications that conflict with each other and the OS.

3) This is just a stylistic suggestion, but I would suggest changing the convention for writing the instructions so that the destination register is listed first. For example, use the instruction "add $destination, $source1, $source2" instead of "add $source1, $source2, $destination" This is definitely less important than the others.

Opinion from Ben about "Time":

Not that I doubt the abilitys of the people working on this project but a modern CPU is something that isnt exactly easy to design when group communication is based on direct face to face contact (in Intel or AMD or IBM). It seems to me that your best option would just be to lobby Sun to change the license on the microcode for its current cpus (which is publicly available). I am not sure, you may actually be able to fab sparc risc chips without paying Sun.

I don't really see the point in GPL'ing everything. For one thing the GPL contains a lot of software specific things which wouldnt work for hardware or documentation. The Open Content license it better for that kind of stuff. Another thing is that things like the micro-code on your cpu arent exactly things that would/can be easily updated and improved upon like normal software.

I hope your project is a success.

Ben.

Question from Kenneth Peiruza about "Devices":

First of all excuse me, 'cause probably I'll say some incongruency or this terms should have been solved yet, but i didn't readed about them anyplace.

Has anyone described what buses are being implemented?

Think there's a lot of cards around the world using many different buses (PCI is, perhaps, the most extended one). And we shouldn't expect manufacturers doing lots of changes in order to make their win-alike products into an autist Linux-based platform.

By the way I know, PCI is very well used on Alpha -PC systems, and the way of building mainboards is very commented too. So... why don't using that kind of (I decline) nasty bus for compatibility reasons?

Remember that most people who's using Linux aren't scientists nor sysadmins, so enabling this pretty new boxes to play Quake with a 3DFX card should be a good bet.

Also think in how many data-adquisition cards should become into garbage for this new boxes. PCI and ISA should be there.

Agreing with a previous post I should say that contacting SUN should be good. They don't make great business with their processors, they do with their "solutions". Breaking down monopolistic areas seems to be one of Sun's entertainments :-)

See you soon with a 64-bit RISC Free-Processor!

Idea from Guy Dunphy about "Assorted points":

A free CPU design is definately a key weapon in the battle against corporate

restrictions on the evolution of computing, and the ownership of knowledge.

As a software/hardware embedded design engineer, I've been watching with

pleasure the growing availability of VHDL cores for everything from UARTS to

full CPUs. There are a few points I'd like to make:

* It seems most thought here assumes a goal of a final chip mask and fabrication.

This is perhaps unwise. Much better to plan on early generations using pure

standard FPGA's. These are getting bigger and cheaper fast (as expected.)

The F1 design is likely to converge with availability of suitable, affordable

FPGA (if not already feasible.)

'On the fly' reconfigurable hardware is the way of the future - not some

probably buggy, custom, single production-run chip.

I'd be happiest to see the completed F1 design only ever exist as a

freely downloadable file: VHDL source, and fitting data for suitable

FPGAs.

* Direct competition with the performance of leading edge commercial CPUs is

also not a wise goal. Nice if you can do it, but far better to concentrate

on the advantages that you can provide as a freeware, non-corporate-originated

processing platform.

- No CPU-ID numbers. (They can stick their stupid fascist CPUs)

- User-modifyable (always a cool thing)

- Which allows for custom anti-viral measures.

- Fully documented and open source (and therefore trustable.)

- Excellent learning tool. (Unlike the Intel so-called architecture,

which is a ghastly morrass of seemingly infinite complexity.)

- No stupid legacy architectural baggage (see above.)

- Clean, simple (hopefully) design (see above.)

- Scalable (?) downwards to small embedded systems, as well as upwards.

- Ability to upgrade functionality on a stable hardware platform (if

using FPGAs.)

- Free. (Watch Linux beat the crap out of Windows 2000! Woo Hoo!)

- Governments cannot lean on the development. So, why not build in

hardware strong public key encryption?

This is a very significant point. Computing is power over information,

which is a highly political issue. There are already many points of

conflict between existing power structures, and the interests of

the (still?) free people. Copyrights, censorship, private currency

systems and taxation (or not), news media control, mechanisms for

implementing true, direct democracy, MP3 vs the music industry, etc.

Commercial development bodies are generally both disinclined and

legally unable to buck the wishes of their (our) political and

economic masters.

World wide co-operative freeware developers, on the other hand,

can do as they dammed well please. And if the product is infinitely

copyable, intangible data, _it_ cannot be controlled either.

* Patents. I don't see this said very much, and not sure if its because most

are afraid to say it, or because the idea is unpopular. But with freeware

designs that exist only as digital information, it seems to me that the

entire issue of patents can be simply ignored. And a good thing too.

As those who follow the patents field know (ref: maillists such as PATNEWS),

the entire structure of the patents system (laws, patents offices and attournys)

has been corrupted by power and money from a once noble idea, into an evil

mechanism for the control and repression of ideas. Including ideas and methods

that many would consider to be essential foundations of our civilisation.

Software and 'methods' patenting trends are becoming particularly worrying,

as large corporations amass huge portfolios of patents covering just about

every conceivable (and even stupid) way of doing anything. They then use

these portfolios as hammers to crush any startup company that appears to

have a chance of competing on its merits.

Anyway - as a freeware, co-operative development process, I don't see why

the F1 design should not simply incorporate any ideas appropriate; patents

be dammed. Who are they going to sue? It may be that freeware development

of all kinds will be the only method of fighting the 'technology freezing'

effect such legalistic control is already exhibiting.

This is another strong argument against the manufacture of physical F1 chips.

In being manufactured, and sold (unavoidable, due to the cost of manufacture),

they become succeptible to patent infringement lawsuits.

* Another future wave that F1 can catch: interpreted scripting/system languages

such as TCL and Java. Platform independence is a prize worth any effort, and

is another finger raised in the direction of those who would control computing.

Interpreted languages are at their most human-friendly when there is _no_

compilation stage- the code remains as plain text always. This has the execution

handicap of requiring continual token recognition and translation to dictionary

entry address. Hence a really useful CPU feature would be some sort of hashing

lookup cache or content addressible memory, optimised to speed up this aspect

of interpreter engines. Present an ascii token/string and get back a pointer.

* I also suspect the quest for ever wider data and address busses is something

of a mistake. Very much processing still requires just 8 or 16 bit data chunks,

and wide busses incur all sorts of alignment and memory wasteage problems, not

to mention higher power consumption, board areas, pincounts, EMI radiation, etc.

It would be interesting to investigate the possibility of using very small busses

(ie 8 bits and a few control lines), but running them _very_ fast (optical?).

This would open up a possibility for the CPU (and peripherals) to operate directly

on a single data type, comprised of variable length sequences of bytes. These

could contain internal typing information (eg so a 'number' could encompass the

full range of mathematical entities, would have _no_ size bounds, but would

still be economical in storage for small integers.)

This idea overlaps another, involving the creation of an operating system kernel

written _in_ an interpreted scripting language, that also exposed the interpreter

engine and dictionaries as a user scripting language for control of the OS, and

implementation of application code. In other words, to see how much of the entire

system could be implemented in one common syntax/engine. There are _many_

advantages to this approach. (Anyone interested in discussing this?)

I'm still a rank beginner at VHDL. But learning. Good luck with the F1 project,

and hopefully, I'll soon be on my VHDL feet enough to be useful.

Oh, and a big punch to the stomach of whoever is to blame for there being

_both_ 'VHDL' and 'Verilog HDL'. Sheesh!

Guy Dunphy

6 Oct 1999

guyd@spam_me_not.zip.com.au.I_really_mean_it

http://everist.org