Tokenizer (fcode-utils 1.0.2) support for 64-bit constants.

[Asif Haswarey]

Hi,

I have been using the tokenizer "toke" fcode-utils version 1.0.2 from:
http://www.openfirmware.info/FCODE_suite

I found out recently that toke does not support 64-bit constants.
It simply truncates the upper 32-bits.

Do we want 64-bit constant support?

- Äsif

[Blue Swirl]

On 4/17/09, Asif Haswarey  wrote:
> Hi,
>
> I have been using the tokenizer “toke” fcode-utils version 1.0.2 from:
>
> http://www.openfirmware.info/FCODE_suite
>
> I found out recently that toke does not support 64-bit constants.
>
> It simply truncates the upper 32-bits.
>
> Do we want 64-bit constant support?

I don't use tokenizer at all for now, but I can imagine we may want to
generate Sparc64 FCode for device ROMs some day. So I'd say yes.

Tokenizer (fcode-utils 1.0.2) support for 64-bit constants.

[Tarl Neustaedter]

Blue Swirl wrote:
> [...]
> > Do we want 64-bit constant support?
>
> I don't use tokenizer at all for now, but I can imagine we may want to
> generate Sparc64 FCode for device ROMs some day. So I'd say yes.

My recollection is that Sun's own tokenizer doesn't support 64-bit 
constants, and generates code which forces partial 32-bit behaviour 
(like 32-bit truncating values before testing). I recall having to 
create 64-bit values with two separate constants and lxjoin - I'll check 
on Monday to make sure this is still the case.

In other words, I'm not clear providing 64-bit constant support buys you 
much in terms of SPARC64 support.

[Stefan Reinauer]

On 17.04.2009 5:41 Uhr, Asif Haswarey wrote:
> Hi,
>
> I have been using the tokenizer “toke” fcode-utils version 1.0.2 from:
>
> http://www.openfirmware.info/FCODE_suite
>
> I found out recently that toke does not support 64-bit constants.
>
> It simply truncates the upper 32-bits.
>
> Do we want 64-bit constant support?

Dear Äsif,

welcome back!

I think 64bit constants won't work on architectures with a 32bit cell
size, so FCode using them will not be platform independent.

Nevertheless, if that's a feature that helps users of toke, we should
definitely support it.

Can you give a usage example of 64bit constants? I would assume it's not
BARs as those can be read from PCI config space?

What's the expected output of the tokenizer? put two 32bit constants on
the stack, shift one by 32bit and OR them?

To be sure, we could add a command line option for enabling 64bit
constants support and print a warning or an error in case it is not set.
Does that sound reasonable?

Best regards,
Stefan

[Segher Boessenkool]

> I think 64bit constants won't work on architectures with a 32bit  
> cell size, so FCode using them will not be platform independent.

An FCode driver can check for 64-bit support at runtime and skip over
some code if it's not there.
> Can you give a usage example of 64bit constants? I would assume  
> it's not BARs as those can be read from PCI config space?

Some devices have 64-bit MMIO registers that should not be accessed as
(pairs of) 32-bit registers.
> What's the expected output of the tokenizer? put two 32bit  
> constants on the stack, shift one by 32bit and OR them?

32-bit-const-1 32-bit-const-2 lxjoin

Note that 32-bit consts are sign-extended on 64-bit systems.
> To be sure, we could add a command line option for enabling 64bit  
> constants support and print a warning or an error in case it is not  
> set. Does that sound reasonable?

Sure.  Error please.

Segher

Tokenizer (fcode-utils 1.0.2) support for 64-bit constants.

[Asif Haswarey]

After the responses to my post about the utility of 64-bit
constant support and talking to David Paktor (the one who
did a major re-implementation of (de)toke), I am not sure
if it's worthwhile. 64-bit constants is not currently clearly
supported in the OpenFirmware std.
I originally used 64-bit constants in my fcode as part of a
data-structure scheme. I then modified portions of the toke
source to support 64-bit constants and did very minimal tests.
It seems to produce the same image as Sun Microsystem's tokenizer
would produce.
For now I simply re-implemented my fcode's data-structure scheme
using 32-bit constants and it's fine.
My major partially related concern is the limited token-number size as
defined in the OpenFirmware spec, although, toke does allow a
way to "re-use" token numbers by placing a tokenizer-directive
in strategic points in the fcode.
I original data-structure design scheme was to minimize the use of
token numbers.

Thanks very much for your responses, everyone!

-Asif

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Segher Boessenkool
Sent: Saturday, April 18, 2009 3:52 AM
To: The OpenBIOS Mailinglist
Subject: Re: [OpenBIOS] Tokenizer (fcode-utils 1.0.2) support for 64-bit constants.
> I think 64bit constants won't work on architectures with a 32bit  
> cell size, so FCode using them will not be platform independent.

An FCode driver can check for 64-bit support at runtime and skip over
some code if it's not there.
> Can you give a usage example of 64bit constants? I would assume  
> it's not BARs as those can be read from PCI config space?

Some devices have 64-bit MMIO registers that should not be accessed as
(pairs of) 32-bit registers.
> What's the expected output of the tokenizer? put two 32bit  
> constants on the stack, shift one by 32bit and OR them?

32-bit-const-1 32-bit-const-2 lxjoin

Note that 32-bit consts are sign-extended on 64-bit systems.
> To be sure, we could add a command line option for enabling 64bit  
> constants support and print a warning or an error in case it is not  
> set. Does that sound reasonable?

Sure.  Error please.

Segher