From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6389 invoked by alias); 27 Feb 2002 14:03:07 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6265 invoked from network); 27 Feb 2002 14:03:00 -0000 Received: from unknown (HELO malonne.lifl.fr) (134.206.10.29) by sources.redhat.com with SMTP; 27 Feb 2002 14:03:00 -0000 Received: from lifl.lifl.fr (lifl.lifl.fr [134.206.10.18]) by malonne.lifl.fr (8.9.3/jtpda-5.3.3) with ESMTP id PAA27985 for ; Wed, 27 Feb 2002 15:02:59 +0100 (MET) Received: from localhost.localdomain (gnurou@bruyere [134.206.11.7]) by lifl.lifl.fr (8.9.3/jtpda-5.3.3) with ESMTP id PAA04438 for ; Wed, 27 Feb 2002 15:02:59 +0100 (MET) Subject: Re: Porting GCC to a register-less, stack-less architecture From: Alexandre Courbot To: GCC List In-Reply-To: References: <1014814467.18242.28.camel@bruyere> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: Wed, 27 Feb 2002 06:56:00 -0000 Message-Id: <1014819880.19524.64.camel@bruyere> Mime-Version: 1.0 X-SW-Source: 2002-02/txt/msg01646.txt.bz2 > How are function calls handled? Calls are performed by the Invok instruction, which takes the function arguments as a parameter (might seems weird for an assembly language, but it use less ressources than pushing, which is important for this architecture). Arguments are taken back in the function body by '.Arguments' declarations. For example, the following lines: .Arguments CardTB256 arg1 .Arguments CardByte arg2 .Arguments CardByte arg3 Would be the first lines of a function that takes 3 arguments. There is also a return mechanism. Others operations are quite classic. Arithmetic operations takes 3 arguments for example, which is just fine with GCC. The architecture by itself might look a bit weird, but apart from the fact it doesn't use a stack (which is only *absolutely* needed for argument passing on others architectures anyway, right?) or hardware registers, it's quite similar to others. > Is all program storage statically declared? You can declare new local variables with the .local statement. Note however that my goal here isn't to have the libc working (no need for mallocs and so on) but only to get GCC working ;) But if you asked whether you allocate memory at the beginning of a block for example, the answer is yes. > Where are you planning on allocating compiler temporaries (e.g., if everything's a > memory-memory operation, how do I compute > > a = (b + c - d*a); > > (You can't use 'a' as the target without great difficulty (you'll have to write an optimization pass....)) > Are you going to use static variables as temps? I would use some local variables for this, as I can "dynamically" allocate and de-allocate them. > I'd think about defining a minimal set of "dummy" registers - just to keep the > compiler happy with the SP and FP. And so that you have SOMEWHERE to allocate > compiler temporaries. (or you could just reserve a small number of memory locations, > call them "registers" and let the compiler do the "register allocation" for those locations > to treat them as temporaries.) Assuming you have enough memory registers, you'll never > spill until you get to a complex program - and maybe your users won't write complex code :-) >From what I understand, GCC use pseudo registers for temporaries, which number isn't limited, right? So this is something I shouldn't have to worry about, I guess. Unless I missed something. :) > Then, assuming that I expect to never support function calls, I can map my "stack" onto a range of static > variables when I emit the assembly language. Anything that ends up "using" my pseudo registers in > "funny ways" (like a _builtin_alloca_ would be defined with a DEFINE_INSN that prints an error message > instead of emitting an instruction to the .s file... Well, emulating a stack shouldn't be too hard on this arch anyway. But if there is a way to do without (theorically it is possible, but I don't know how much GCC likes such architectures) I'm taking it. :) > Good strategy. I'd pick a MD for a machine that you thoroughly understand, so you can see what it's > doing and figure out if there's a correspondence to your architecture. Off hand, I can't think of any > machine that shares the characteristics of your architecture. My knowledge is limited to the i386 architecture, which description is quite complex (and which isn't as a "simple" architecture as I would like). What I'm looking for is the most minimalist MD file you can set up to get GCC to compile. Even if written for a different kind of architecture, or a simple architecture I don't know yet, that's not a problem - that would simply help me understanding GCC's mechanisms. All in all, a .h and .md machine description files, the shortest possible, which allows GCC to compile, would be paradise for me! :) See you and thanks for the answer, Alex. -- http://www.gnurou.org