This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: Use of DI mode on 32-bit hosts
On Mon, Jun 02, 2003 at 01:43:51PM -0700, Doug Evans wrote:
> Michael Meissner writes:
> > 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.
>
> Ah, that helps.
> You are talking about target word size.
>
> This is unfinished business but I can easily finish it asap.
>
> The ia64.cpu port is trying to use `eval' to hack in a solution.
> It shouldn't have to of course, and I'm guessing ia64.cpu either
> used a private copy of cgen or hasn't been tried in awhile and
> the reader has been tightened up to only accept what it should.
> i.e. `(eval mumble)' is not a valid entry in a .cpu file and that's
> what's causing the "unknown entry type" error.
> If you replace (eval mumble) in ia64.cpu with #.(mumble) that
> might achieve the desired result (suitably tweaked to get it to work
> as I haven't tried it). Clearly it's still a hack though.
Yeah, I suspect the ia64 port may have suffered bitrot.
> The end of mode.scm had the beginnings of my solution but I ran
> into difficulties of knowing when to call it. Specifically:
>
> (if #f
> ; ???: Something like this would be nice if it was timed appropriately
> ; redefine WI/UWI/AI/IAI for this target
> (case (cpu-word-bitsize (current-cpu))
> ((32) (begin
> (display "Recognized 32-bit cpu.\n")))
> ((64) (begin
> (display "Recognized 64-bit cpu.\n")
> (set! WI (mode:add! 'WI (mode:lookup 'DI)))
> (set! UWI (mode:add! 'UWI (mode:lookup 'UDI)))
> (set! AI (mode:add! 'AI (mode:lookup 'UDI)))
> (set! IAI (mode:add! 'IAI (mode:lookup 'UDI)))))
> (else (error "Unknown word-bitsize for WI/UWI/AI/IAI mode!"))))
>
> i.e. defer setting these until it's known what value to use.
> (or, more precisely, set a default, and then change it as appropriate).
>
> Here's my proposed solution for WI,UWI,AI,IAI
> (setting aside the orthogonal issue of what to do with U-modes):
>
> 1) Change mode.scm to no longer provide a default for WI,UWI,AI,IAI.
> The value will be left as #f and the code will issue some sort of
> error message if a proper value isn't set before it's used.
>
> 2) Provide one or more functions an app can call to set WI/UWI/AI/IAI.
> - an opcodes like app might just want the biggest value (e.g. for
> architectures that have both 32 and 64 bit variants use 64)
> - a simulator like app would want just one value (and different copies
> of the code would be generated for each value (e.g. separate 32 and
> 64 bit versions) - or not, it's up to the app to decide.
Something like c99's inttypes.h (which has types for give me an integer that is
exactly 32-bit longs, and give me an integer that is at least 32-bits long, but
could be larger depending on the local conditions).
> 3) The application will be responsible for calling one of the functions
> to set WI/UWI/AI/IAI as appropriate.
>
> 4) This doesn't address INT/UINT. Ideally it would remain 32 bits
> (i.e. a portable int).
Or maybe they should be slated to be removed.
> I'll begin implementing this tonight if there are no objections.
> Won't take more than a day.
>
> Is that acceptable?
>
> [I realize you don't want to trip over too many of these.
> But these are issues that do need to be worked through
> and if the response time is acceptable, "thank you for your support" :-)]
It looks reasonable. Thanks by the way.
I dunno what we should do about the SIMD vector types (ie, V2QI, V8DI, etc.).
Most machines these days do have MMX/VIS/SSE/SSE2/etc. type instructions. The
machine I'm targetting has a rather complete set of these instructions.
--
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org