This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN 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]

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


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