So, like, the other day Segher Boessenkool mumbled:
The first option. Anywhere a number can be used, "d# xxx"
would mean decimal.
When you would say <d# 1234 5678>, 1234 is decimal and
5678 is hexadecimal.
Where do the tokens end? Is "d#1234" valid and equal to "d# 1234"?
Or is "d#" an independent token? And are there other bases to
this model? Like, maybe, "b#", "o#" and "h#" as well?
jdl
quoted
The first option. Anywhere a number can be used, "d# xxx"
would mean decimal.
When you would say <d# 1234 5678>, 1234 is decimal and
5678 is hexadecimal.
Where do the tokens end? Is "d#1234" valid and equal to "d# 1234"?
Or is "d#" an independent token?
In OF, there has to be whitespace inbetween.
And are there other bases to
this model? Like, maybe, "b#", "o#" and "h#" as well?
o# d# h# are standard defined; b# exists on many implementations.
Neither b# nor o# is frequently used but there's no harm in
including them I suppose.
Segher
=20
-----Original Message-----
From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
[mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
On Behalf Of Segher Boessenkool
Sent: Thursday, February 15, 2007 8:57 AM
To: Jon Loeliger
Cc: linuxppc-dev@ozlabs.org; David Gibson
Subject: Re: [PATCH 15/16] Add device tree for Ebony=20
=20
quoted
quoted
The first option. Anywhere a number can be used, "d# xxx"
would mean decimal.
When you would say <d# 1234 5678>, 1234 is decimal and
5678 is hexadecimal.
Where do the tokens end? Is "d#1234" valid and equal to "d# 1234"?
Or is "d#" an independent token?
=20
In OF, there has to be whitespace inbetween.
=20
quoted
And are there other bases to
this model? Like, maybe, "b#", "o#" and "h#" as well?
=20
o# d# h# are standard defined; b# exists on many implementations.
1275 specifies whitespace inbetween, but isn't this due to=20
the way they are describing things for the forth / stack-based
operations?
I would prefer in the DTS files to have no whitespace in=20
between-- <d#1234 #h5678> seems much more readable
than <d# 1234 #h 5678>.
Or even better-- just use standard C notation
<1234 0x5678>
That is very readable. Why bring unnecessary complexity into
this?
Stuart
Yoder Stuart-B08248 wrote:
1275 specifies whitespace inbetween, but isn't this due to
the way they are describing things for the forth / stack-based
operations?
I would prefer in the DTS files to have no whitespace in
between-- <d#1234 #h5678> seems much more readable
than <d# 1234 #h 5678>.
Or even better-- just use standard C notation
<1234 0x5678>
That is very readable. Why bring unnecessary complexity into
this?
Decimal-by-default C notation would break compatibility (undetectably,
in the case of hex constants that don't happen to use digits above 9)
with current DTS files which are hex-by-default -- and besides, most of
the values are going to be hex.
I agree that allowing the space to be omitted would be a good thing.
-Scott
1275 specifies whitespace inbetween, but isn't this due to
the way they are describing things for the forth / stack-based
operations?
Sure, since for true OF d# etc. are Forth words and thus
are whitespace delimited.
I would prefer in the DTS files to have no whitespace in
between-- <d#1234 #h5678> seems much more readable
than <d# 1234 #h 5678>.
[h# not #h] Sure, make it optional, that should work just fine.
Or even better-- just use standard C notation
<1234 0x5678>
Right now no prefix means hexadecimal. So you need a prefix
that means decimal, and C has none.
That is very readable. Why bring unnecessary complexity into
this?
It's all historical accident I suppose. Since the DTS
format tries to look like C it should have used 0x all
along. It's not too late too change btw, the DTS is not
the actual interface, the binary blob that is passed
around doesn't care what number base you used in the
source code.
Segher