Re: Use of DI mode on 32-bit hosts

[Doug Evans <dje at transmeta dot com>]

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.

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.

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).

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" :-)]