This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Virtual processor design ideas


While you're giving microprocessor design advice ... :-)

For a while now, I've played a bit with creating a gcc port to a virtual  
CPU. Never got very far, mainly because of being rather unsure about  
design choices.

The idea would be to ultimately have just a simulator; the goal is mainly  
to get better understanding of gcc. (As such, it certainly should support  
all languages!)

My current ideas are to have a 64 bit CPU, with 128 bit long double and,  
at least theoretically/optionally, support for decimal FP. (But I expect  
that as far as the gcc port is concerned, that's essentially something  
like one bit in the FP opcodes, or maybe somewhere on the side of  
registers holding FP values.) However, presumably a first version should  
just use soft FP.

So ... what kind of design would GCC most like to see here? (I already  
understand many GPRs and sane condition code handling, as explained in the  
other thread; but presumably much other advice isn't quite appropriate for  
a "big" CPU instead of a "small" one ... nor are silicon area or  
scheduling issues very relevant here :-))

Oh, given the nature of the beast, I expect I'll need zero I/O operations  
but a sensible interface for calling support routines implemented in the  
simulator. Presumably "sensible" means "takes standard calling  
conventions" but uses either a special instruction or special addresses.

Hmm. Vector ops on GPRs or better separate regs? Same question for FP.

Oh yeah. What is a sensible set of addressing modes?

Three-address operations worth the effort?

MfG Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]