public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Michael Meissner <cgen-mail@the-meissners.org>
To: cgen@sources.redhat.com
Subject: Re: Use of DI mode on 32-bit hosts
Date: Mon, 02 Jun 2003 19:22:00 -0000	[thread overview]
Message-ID: <20030602192217.GA7082@tiktok.the-meissners.org> (raw)
In-Reply-To: <16091.36137.249864.565465@casey.transmeta.com>

On Mon, Jun 02, 2003 at 10:45:13AM -0700, Doug Evans wrote:
> Michael Meissner writes:
>  > Where is the decision made about the sizes of integer (particularly whether DI
>  > mode is available on 32-bit systems)?  Is it in the scheme interpreter or is it
>  > in the scm code?  Is there any configure option to say assume we are using GCC
>  > and that long long (or __attribute__((__mode__(__DI__)))) is available?
> 
> I'm guessing you're refering to host tool issues instead of
> target architecture issues.
> Assuming that's the case ...
> 
> It's up to each application to choose how it wants to do this.
> cgen proper does not get involved.
> 
> To pick an arbitrary example of the m32r simulator in src/sim,
> the code generators just always emit DI for the type, and then leave it
> to other code to decide whether to make DI an integral type or a struct.
> DI_FN_SUPPORT gets defined if the host compiler doesn't have a suitable
> integral mode for DI's, which in turn is based on HAVE_LONGLONG.
> 
> >From cgen-types.h:
> 
> #ifdef __GNUC__
> #define HAVE_LONGLONG
> #undef DI_FN_SUPPORT
> #else
> #undef HAVE_LONGLONG
> #define DI_FN_SUPPORT
> #endif
> 
> And in cgen-ops.h different versions of the DI mode operations
> get used depending on ifdef DI_FN_SUPPORT.
> 
> No claim is made that the !ifdef version is well tested recently.
> I do remember it working way back when though.
> 
> Which application did you have in mind?


Basically I'm trying to build the gas tables at present, though the simulator
will be next after I get gas/bfd/ld working.  My machine is sort of like the
IA-64 in that it is a 64-bit machine with a 64-bit address space, and the
instructions are encoded as 3 instructions within a 128-bit field.  I see the
error when trying to use the ia64 machine as a reference port:

--> /home/meissner/fsf-src/uberbaum/cgen --prefix=/home/meissner/tools/linux --target=ia64-linux
--> make GUILE=~/install/guile-1.4.1/bin/guile opcodes
rm -f tmp-opc.h tmp-itab.c
rm -f tmp-asm.in tmp-dis.in tmp-ibld.h tmp-ibld.in
/home/meissner/install/guile-1.4.1/bin/guile -s /home/meissner/fsf-src/uberbaum/cgen/cgen-opc.scm \
-s /home/meissner/fsf-src/uberbaum/cgen \
-v \
-f " opinst" \
        -m all -a ia64 \
        -O tmp-opc.h -P tmp-opc.c -Q tmp-opinst.c \
        -B tmp-ibld.h -L tmp-ibld.in \
        -A tmp-asm.in -D tmp-dis.in
Skipping slib/sort, already loaded.
Skipping slib/random, already loaded.
cgen -s /home/meissner/fsf-src/uberbaum/cgen/cgen-opc.scm -s /home/meissner/fsf-src/uberbaum/cgen -v -f " opinst" -m all -a ia64 -O tmp-opc.h -P tmp-opc.c -Q tmp-opinst.c -B tmp-ibld.h -L tmp-ibld.in -A tmp-asm.in -D tmp-dis.in 
Setting option `opinst' to "".
Loading cpu description /home/meissner/fsf-src/uberbaum/cgen/cpu/ia64.cpu
Including file simplify.inc ...
ERROR: /home/meissner/fsf-src/uberbaum/cgen/cpu/ia64.cpu:55: unknown entry type:
 (eval (begin (set! INT (mode:add! (quote INT) (mode:lookup (quote DI)))) (set! UINT (mode:add! (quote UINT) (mode:lookup (quote UDI)))) (set! WI (mode:add! (quote WI) (mode:lookup (quote DI)))) (set! UWI (mode:add! (quote UWI) (mode:lookup (quote UDI)))) (set! AI (mode:add! (quote AI) (mode:lookup (quote UDI)))) (set! IAI (mode:add! (quote IAI) (mode:lookup (quote UDI))))))
No backtrace available.
make: *** [opcodes] Error 1

If I just do a (mode:lookup (quote DI)) it gives the same error message.

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org

  reply	other threads:[~2003-06-02 19:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-02 17:32 Michael Meissner
2003-06-02 17:45 ` Doug Evans
2003-06-02 19:22   ` Michael Meissner [this message]
2003-06-02 20:44     ` Doug Evans
2003-06-02 20:50       ` Frank Ch. Eigler
2003-06-02 21:26         ` Doug Evans
2003-06-02 21:32           ` Frank Ch. Eigler
2003-06-02 22:04             ` Doug Evans
2003-06-03 15:19               ` Frank Ch. Eigler
2003-06-02 21:33       ` Michael Meissner
2003-06-02 22:10         ` Doug Evans
2003-06-02 22:16           ` Doug Evans
2003-06-04 20:27         ` Doug Evans
2003-06-05 11:51           ` Michael Meissner
2003-06-05 13:34             ` Ben Elliston
2003-06-05 15:41               ` Doug Evans
2003-06-05 16:04             ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030602192217.GA7082@tiktok.the-meissners.org \
    --to=cgen-mail@the-meissners.org \
    --cc=cgen@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).