Use of DI mode on 32-bit hosts

Use of DI mode on 32-bit hosts

[Michael Meissner]

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?

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

Use of DI mode on 32-bit hosts

[Doug Evans]

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?

Re: Use of DI mode on 32-bit hosts

[Michael Meissner]

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

Re: Use of DI mode on 32-bit hosts

[Doug Evans]

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

Re: Use of DI mode on 32-bit hosts

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

Hi -

dje wrote:
> [...]
> Here's my proposed solution for WI,UWI,AI,IAI
> [... and INT/UINT]

Can you explain what these types might be useful for,
as distinct from the plain target types of SI/DI/etc.?

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Use of DI mode on 32-bit hosts

[Doug Evans]

Frank Ch. Eigler writes:
 > dje wrote:
 > > [...]
 > > Here's my proposed solution for WI,UWI,AI,IAI
 > > [... and INT/UINT]
 > 
 > Can you explain what these types might be useful for,
 > as distinct from the plain target types of SI/DI/etc.?

Abstraction and simplicity.  For "normal" architectures they're not
distinct and map directly to SI/DI/etc.

INT/UINT are treated separately.  They're for host values
where one doesn't care about target sizes.

Re: Use of DI mode on 32-bit hosts

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

Hi -

dje wrote:
>  > Can you explain what these types might be useful for,
>  > as distinct from the plain target types of SI/DI/etc.?
> 
> Abstraction and simplicity.  For "normal" architectures they're not
> distinct and map directly to SI/DI/etc.

I guess I don't see the abstraction and simplicity this
indirection is to provide.  Do you have an example?

> INT/UINT are treated separately.  They're for host values
> where one doesn't care about target sizes.

In what circumstances do you consider it reasonable for cgen
model files to deal with host data types/sizes?


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Use of DI mode on 32-bit hosts

[Michael Meissner]

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

Re: Use of DI mode on 32-bit hosts

[Doug Evans]

Frank Ch. Eigler writes:
 > I guess I don't see the abstraction and simplicity this
 > indirection is to provide.  Do you have an example?

- I'd rather have one version of "add" for sparc 32/64
- I'd rather write 'IAI in the .scm sources when refering to 'pc
  than doing something else

[for example]

 > > INT/UINT are treated separately.  They're for host values
 > > where one doesn't care about target sizes.
 > 
 > In what circumstances do you consider it reasonable for cgen
 > model files to deal with host data types/sizes?

Don't say "deal with host data types/sizes".  That'll trigger arguments
that go off on tangents.  Each host has lots of data types/sizes.

What I meant was integers not tied to particular widths,
and for pragmatic sake one can assume the application will have available
at least a 32 bit integral type to use.

Sometimes the code will need a mode but imposing a specific
width muddies the waters.  If one wanted to write some rtl
that looped over something, picking one of QI/HI/SI/DI
may be less appealing than "just give me a big enough int".
How many in C-land write "for (unsigned i = 0; mumble; mumble)
vs "for (uint32_t i = 0; mumble; mumble)"?

[
And actually I was incomplete.  INT/UINT are also used for varying
width values, whereas SI/DI have explicit widths.
So actually, I should have two separate forms of INT/UINT,
but the distinction has yet to be needed.

From doc/rtl.texi:
@example
@code{(immediate mode)}
@code{(immediate (mode bits))}
@end example

The second form is for values for which a mode of that size doesn't exist.
@samp{mode} for the second form must be one of @code{INT} or @code{UINT}.
Since these two modes don't have an implicit size, they cannot be used
for the first form.

??? There's no real reason why a mode like SI can't be used
for odd-sized immediate values.  The @samp{bits} field indicates the size
and the @samp{mode} field indicates the mode in which the value will be used,
as well as its signedness.  This would allow removing INT/UINT for this
purpose.  On the other hand, a non-width specific mode allows applications
to choose one (a simulator might prefer to store immediates in an `int'
rather than, say, char if the specified mode was @code{QI}).

[and I should rephrase that to say that imposing one width with SI
on a value (e.g. immediate) of a different width is confusing]
]

Re: Use of DI mode on 32-bit hosts

[Doug Evans]

Michael Meissner writes:
 > 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).

Something along those lines, though I try to approach these things
by only adding as warranted.

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

Except that I missed the part about them also being used to represent
arbitrary width types.

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

Well, a minimalist approach could be taken and say they aren't needed
(and neither is SF/DF/etc. btw), the argument being the same as for the
(intended) absence of USI in .cpu files: it's the operation that specified the
type, not the data.
OTOH, they can simplify things downstream ....

Re: Use of DI mode on 32-bit hosts

[Doug Evans]

Doug Evans writes:
 > Except that I missed the part about them also being used to represent
 > arbitrary width types.

pedantic: s/arbitrary width/width-accompanies-alongside/

Re: Use of DI mode on 32-bit hosts

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Hi -


On Mon, Jun 02, 2003 at 03:04:21PM -0700, Doug Evans wrote:
>  > I guess I don't see the abstraction and simplicity this
>  > indirection is to provide.  Do you have an example?
> 
> - I'd rather have one version of "add" for sparc 32/64

I would rather use macros that expand to SI or DI as appropriate
for the two different targets, or perhaps use DI only (and rely
on implicit truncation for 32-bit hardware registers).

> - I'd rather write 'IAI in the .scm sources when refering to 'pc
>   than doing something else

Likewise -- the PC register is likewise an inherently target-sized
quantity.

This whole argument sounds like going backward from the SI-vs-USI
issue from a few weeks ago.  It encodes in the type some notion of
purpose, or even a deliberate lack of specificity, instead of
leaving these solely in the operators.


>  > In what circumstances do you consider it reasonable for cgen
>  > model files to deal with host data types/sizes?
> 
> [...]
> Sometimes the code will need a mode but imposing a specific
> width muddies the waters.  If one wanted to write some rtl
> that looped over something, picking one of QI/HI/SI/DI
> may be less appealing than "just give me a big enough int". [...]

Not to me...  Given the low level nature of modelling semantics
in rtl, I don't consider it natural to pick "a big enough" int.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Use of DI mode on 32-bit hosts

[Doug Evans]

Michael Meissner writes:
 > > [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.

Patch checked in.  Let me know if you need anything more.

Re: Use of DI mode on 32-bit hosts

[Michael Meissner]

On Wed, Jun 04, 2003 at 01:26:17PM -0700, Doug Evans wrote:
> Michael Meissner writes:
>  > > [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.
> 
> Patch checked in.  Let me know if you need anything more.

Thanks.  Now I can get cracking.

By the way, what is the way to configure cgen?  The toplevel makefile doesn't
seem to go into the cgen directory, and if I configure cgen directly from the
subdirectory, I get the following in the tmp-desc.h file:

#ifndef @ARCH@_CPU_H
#define @ARCH@_CPU_H

Obviously this is a minor annoyance, but I'm wondering if I shouldn't be
invoking it from the toplevel Makefile.

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

Re: Use of DI mode on 32-bit hosts

[Ben Elliston]

Michael Meissner <cgen-mail@the-meissners.org> writes:

> By the way, what is the way to configure cgen?  The toplevel
> makefile doesn't seem to go into the cgen directory, and if I
> configure cgen directly from the subdirectory, I get the following
> in the tmp-desc.h file:

I believe configuring from the top-level was removed because it was
thought that cgen didn't need configuring -- it runs entirely from the
source tree, via Makefile targets in other build directories, like
opcodes.

It was concluded that this is incorrect, though, because it is needed
to build the documentation at the very least.  I don't know if the
top-level gear was put back or not.

Ben

Re: Use of DI mode on 32-bit hosts

[Doug Evans]

Ben Elliston writes:
 > I believe configuring from the top-level was removed because it was
 > thought that cgen didn't need configuring -- it runs entirely from the
 > source tree, via Makefile targets in other build directories, like
 > opcodes.
 > 
 > It was concluded that this is incorrect, though, because it is needed
 > to build the documentation at the very least.  I don't know if the
 > top-level gear was put back or not.

Not to mention the loss of Hobbit support.  Boo hoo hoo ....

Re: Use of DI mode on 32-bit hosts

[Doug Evans]

Michael Meissner writes:
 > By the way, what is the way to configure cgen?  The toplevel makefile doesn't
 > seem to go into the cgen directory, and if I configure cgen directly from the
 > subdirectory, I get the following in the tmp-desc.h file:
 > 
 > #ifndef @ARCH@_CPU_H
 > #define @ARCH@_CPU_H
 > 
 > Obviously this is a minor annoyance, but I'm wondering if I shouldn't be
 > invoking it from the toplevel Makefile.

You don't need to configure cgen to generate files.
Cgen use to get configured but that part got removed.
It's still needed to build the docs of course so that part
has to get put back.

When you configure the entire tree, add --enable-cgen-maint.
Also, add your cpu to opcodes/Makefile.am.
Grep for the other cgen cpu files in there and cut-n-paste.

Then when you go to build in opcodes, the dependencies there
will invoke cgen as appropriate.

And if you want to just generate the files and not build anything

bash$ make stamp-<cpu>

[Perhaps that's what you're doing already.
Though I'm then at a loss to explain why @ARCH@ didn't get substituted.]