Date: Fri, 12 Jan 2001 08:09:07 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Matthew Jacob <mjacob@feral.com> Cc: Warner Losh <imp@harmony.village.org>, Matt Jacob <mjacob@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/alpha/include bus.h Message-ID: <20010112080906.I91029@gsmx07.alcatel.com.au> In-Reply-To: <Pine.BSF.4.21.0101102224020.4758-100000@beppo.feral.com>; from mjacob@feral.com on Wed, Jan 10, 2001 at 10:24:26PM -0800 References: <20010111163029.B91242@gsmx07.alcatel.com.au> <Pine.BSF.4.21.0101102224020.4758-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Jan-10 22:24:26 -0800, Matthew Jacob <mjacob@feral.com> wrote:
>On Thu, 11 Jan 2001, Peter Jeremy wrote:
>
>> On 2001-Jan-09 22:04:03 -0800, Matthew Jacob <mjacob@feral.com> wrote:
>> >
>> >
>> >> In message <200101091817.f09IHng10622@freefall.freebsd.org> Matt Jacob writes:
>> >> : me that BUS_SPACE_UNRESTRICTED should b ~0UL, not ~0.
>> >>
>> >> Would this impact the 10E6 uses of ~0 in the bus_alloc_resource calls
>> >> we have?
>> >
>> >int foo()
>> >{
>> > bar(~0);
>> >}
>> >int zoo()
>> >{
>> > bar1(~0UL);
>> >}
>> ...
>> >Sorta looks the same to me....
>>
>> I don't think that's a valid test. A more reasonable test would be
>> something like
>Why isn't it a valid test? This is exactly the test case that Warner was
>worrying about?
There are no prototypes (visibly) in scope for either bar() or bar1().
This means that the only possible promotions are char or short to int -
ie, bar() is passed a signed int and bar1() is passed an unsigned long.
In the case of the Alpha, (the first few) parameters are passed to
functions in registers and registers are always 64-bits, hence there
was a promotion to 64 bits. A signed promotion is done presumably
because that is the easiest. Note that the following is also passed
as 0xffffffffffffffff, though ANSI-C (at least) promotion would result
in 0x00000000ffffffff (having experimented, it seems the callee will
explicitly clear the top 32 bits if an argument is being used in
an unsigned context).
void abc()
{
def(~0u);
}
This implicit "promotion to long" is an implementation detail on the
Alpha and another 32/64-bit architecture may not behave the same
(especially if function arguments are passed on the stack).
Note that the following code is in error (in the absence of a prototype
for bar() preceeding foo()) because foo() will pass an int, not a long
to bar():
void foo()
{
bar(~0);
}
void bar(long x)
{
...
}
>> unsigned long foo, bar;
>>
>> fun()
>> {
>> foo = bar & ~0;
>> }
>>
>> Unfortunately, I don't have a functional FreeBSD/Alpha box right now,
>> but both Compaq CC and gcc-2.8.1 generate "foo = bar". I'm not sure
>> that this behaviour makes sense.
Having thought about it on my way home yesterday (and carefully studied
K&R2 - since I don't have the actual standards), I agree with the
statements that Warner and Garrett made - the behaviour does make
sense.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010112080906.I91029>