Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Portable replacement

Reply
Thread Tools

Portable replacement

 
 
Noob
Guest
Posts: n/a
 
      04-28-2008
Hello,

I've rewritten a function (greater_or_equal) that relies on
implementation-defined behavior and availability of exact-width
integers, with the goal of making the new implementation
(greater_or_equal2) portable across any platform.

What do you think of the new implementation?
(Suggestions and comments are welcome.)

int greater_or_equal(uint16_t u, uint16_t v)
{
return (int16_t)(u-v) >= 0;
}

int greater_or_equal2(unsigned u, unsigned v)
{
return ((u-v) & 0xffffU) <= 0x7fffU;
}

<OT>
GCC seems to "understand" the source as it outputs the following code.

greater_or_equal2:
movl 8(%esp), %edx
cmpw %dx, 4(%esp)
setns %al
movzbl %al, %eax
ret
</OT>

Regards.
 
Reply With Quote
 
 
 
 
suresh shenoy
Guest
Posts: n/a
 
      04-28-2008
On Apr 28, 10:38*am, Noob <root@localhost> wrote:
> Hello,
>
> I've rewritten a function (greater_or_equal) that relies on
> implementation-defined behavior and availability of exact-width
> integers, with the goal of making the new implementation
> (greater_or_equal2) portable across any platform.
>
> What do you think of the new implementation?
> (Suggestions and comments are welcome.)
>
> int greater_or_equal(uint16_t u, uint16_t v)
> {
> * *return (int16_t)(u-v) >= 0;
>
> }
>
> int greater_or_equal2(unsigned u, unsigned v)
> {
> * *return ((u-v) & 0xffffU) <= 0x7fffU;
>
> }
>
> <OT>
> GCC seems to "understand" the source as it outputs the following code.
>
> greater_or_equal2:
> * * *movl * *8(%esp), %edx
> * * *cmpw * *%dx, 4(%esp)
> * * *setns * %al
> * * *movzbl *%al, %eax
> * * *ret
> </OT>
>
> Regards.


You still use a 2 byte mask, what if unsigned u represents 32 bits?

Suresh M. Shenoy
 
Reply With Quote
 
 
 
 
thomas.mertes@gmx.at
Guest
Posts: n/a
 
      04-28-2008
On 28 Apr., 19:58, pete <(E-Mail Removed)> wrote:
> Noob wrote:
> > Hello,

>
> > I've rewritten a function (greater_or_equal) that relies on
> > implementation-defined behavior and availability of exact-width
> > integers, with the goal of making the new implementation
> > (greater_or_equal2) portable across any platform.

>
> > What do you think of the new implementation?
> > (Suggestions and comments are welcome.)

>
> > int greater_or_equal(uint16_t u, uint16_t v)
> > {
> > return (int16_t)(u-v) >= 0;
> > }

>
> > int greater_or_equal2(unsigned u, unsigned v)
> > {
> > return ((u-v) & 0xffffU) <= 0x7fffU;
> > }

>
> > <OT>
> > GCC seems to "understand" the source as it outputs the following code.

>
> > greater_or_equal2:
> > movl 8(%esp), %edx
> > cmpw %dx, 4(%esp)
> > setns %al
> > movzbl %al, %eax
> > ret
> > </OT>

>
> I can't help but wonder, what code does it output for:
>
> int greater_or_equal3(unsigned u, unsigned v)
> {
> return u >= v;
>
> }


Maybe the code of the OP will be used in a obfuscated
C contest...

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
Reply With Quote
 
Thad Smith
Guest
Posts: n/a
 
      04-29-2008
Noob wrote:
> Hello,
>
> I've rewritten a function (greater_or_equal) that relies on
> implementation-defined behavior and availability of exact-width
> integers, with the goal of making the new implementation
> (greater_or_equal2) portable across any platform.
>
> What do you think of the new implementation?
> (Suggestions and comments are welcome.)
>
> int greater_or_equal(uint16_t u, uint16_t v)
> {
> return (int16_t)(u-v) >= 0;
> }
>
> int greater_or_equal2(unsigned u, unsigned v)
> {
> return ((u-v) & 0xffffU) <= 0x7fffU;
> }


Neither implementation is correct without an exact definition of what it
does. A function that evaluates greater_or_equal2(60000,0) as 0 would be
surprising to me without a definition to the contrary.

--
Thad
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      04-29-2008
Thad Smith wrote:

> Noob wrote:
>
>> I've rewritten a function (greater_or_equal) that relies on
>> implementation-defined behavior and availability of exact-width
>> integers, with the goal of making the new implementation
>> (greater_or_equal2) portable across any platform.
>>
>> What do you think of the new implementation?
>> (Suggestions and comments are welcome.)
>>
>> int greater_or_equal(uint16_t u, uint16_t v)
>> {
>> return (int16_t)(u-v) >= 0;
>> }
>>
>> int greater_or_equal2(unsigned u, unsigned v)
>> {
>> return ((u-v) & 0xffffU) <= 0x7fffU;
>> }

>
> Neither implementation is correct without an exact definition of what it
> does. A function that evaluates greater_or_equal2(60000,0) as 0 would
> be surprising to me without a definition to the contrary.


(I agree that I have given these functions unintuitive names, but
I didn't ask whether the two implementations were correct.)

What matters to me is whether the two implementations are equivalent.
That is, given identical input, do they produce identical output?
(The range of legal values for u and v is that of an uint16_t,
i.e. 0 to 65535.)

I should have named the two functions foo1 and foo2, and asked:
"Are foo1 and foo2 equivalent? and is foo2 portable?"

int foo1(uint16_t u, uint16_t v)
{
return (int16_t)(u-v) >= 0;
}

int foo2(unsigned u, unsigned v)
{
return ((u-v) & 0xffffU) <= 0x7fffU;
}

For those wondering what they're supposed to compute, I provided
more details in an earlier thread.

Message-ID: <480f0d58$0$5410$(E-Mail Removed)>
http://groups.google.com/group/comp....eeb7c981bf2113

For example, 2 is considered "greater than" 65530, because there is
a high probability that 2 is, in fact, 65538 in disguise.

Regards.
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      04-29-2008
Suresh wrote:

> Noob wrote:
>
>> I've rewritten a function (greater_or_equal) that relies on
>> implementation-defined behavior and availability of exact-width
>> integers, with the goal of making the new implementation
>> (greater_or_equal2) portable across any platform.
>>
>> What do you think of the new implementation?
>> (Suggestions and comments are welcome.)
>>
>> int greater_or_equal(uint16_t u, uint16_t v)
>> {
>> return (int16_t)(u-v) >= 0;
>> }
>>
>> int greater_or_equal2(unsigned u, unsigned v)
>> {
>> return ((u-v) & 0xffffU) <= 0x7fffU;
>> }

>
> You still use a 2 byte mask,


I think you wrote "byte" where you meant "octet"

> what if unsigned u represents 32 bits?


I don't understand the question. What did you mean?

The range of legal values for u and v is that of an uint16_t
i.e. 0 to 65535.

Regards.
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      04-29-2008
pete wrote:

> Noob wrote:
>
>> I've rewritten a function (greater_or_equal) that relies on
>> implementation-defined behavior and availability of exact-width
>> integers, with the goal of making the new implementation
>> (greater_or_equal2) portable across any platform.
>>
>> What do you think of the new implementation?
>> (Suggestions and comments are welcome.)
>>
>> int greater_or_equal(uint16_t u, uint16_t v)
>> {
>> return (int16_t)(u-v) >= 0;
>> }
>>
>> int greater_or_equal2(unsigned u, unsigned v)
>> {
>> return ((u-v) & 0xffffU) <= 0x7fffU;
>> }
>>
>> <OT>
>> GCC seems to "understand" the source as it outputs the following code.
>>
>> greater_or_equal2:
>> movl 8(%esp), %edx
>> cmpw %dx, 4(%esp)
>> setns %al
>> movzbl %al, %eax
>> ret
>> </OT>

>
> I can't help but wonder, what code does it output for:
>
> int greater_or_equal3(unsigned u, unsigned v)
> {
> return u >= v;
> }


Why are you wondering?

greater_or_equal3:
movl 8(%esp), %edx
cmpl %edx, 4(%esp)
setae %al
movzbl %al, %eax
ret

But this is irrelevant, as greater_or_equal3 is /not/ equivalent
to greater_or_equal2. (It doesn't deal with wrap-around.)

Consider u=65000 and v=10

greater_or_equal2(65000, 10) returns 0.
greater_or_equal3(65000, 10) returns 1.

Regards.
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      04-29-2008
Thomas Mertes wrote:

> Maybe the code of the OP will be used in a obfuscated C contest...


It is real code, used in a production environment.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      04-29-2008
Noob <root@localhost> writes:
<snip>
> I should have named the two functions foo1 and foo2, and asked:
> "Are foo1 and foo2 equivalent? and is foo2 portable?"
>
> int foo1(uint16_t u, uint16_t v)
> {
> return (int16_t)(u-v) >= 0;
> }
>
> int foo2(unsigned u, unsigned v)
> {
> return ((u-v) & 0xffffU) <= 0x7fffU;
> }


There is one difference (which I though had already been pointed out,
but I may be miss-remembering) which is that in foo1, u-v may not be
representable as in int16_t, so the conversion is either undefined or,
implementation defined depending on which C standard one is using.

--
Ben.
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      04-29-2008
Ben Bacarisse wrote:

> Noob wrote:
>
>> I should have named the two functions foo1 and foo2, and asked:
>> "Are foo1 and foo2 equivalent? and is foo2 portable?"
>>
>> int foo1(uint16_t u, uint16_t v)
>> {
>> return (int16_t)(u-v) >= 0;
>> }
>>
>> int foo2(unsigned u, unsigned v)
>> {
>> return ((u-v) & 0xffffU) <= 0x7fffU;
>> }

>
> There is one difference (which I though had already been pointed out,
> but I may be miss-remembering) which is that in foo1, u-v may not be
> representable as in int16_t, so the conversion is either undefined or,
> implementation defined depending on which C standard one is using.


I've already pointed out that foo1 relies on impl-defined behavior.
In fact, that is the very reason why I wrote foo2.

The problem statement was:

<quote>
I've rewritten a function that relies on implementation-defined
behavior and availability of exact-width integers, with the goal
of making the new implementation portable across any platform.
</quote>

On a related subject, I don't think the conversion to int16_t is
ever undefined. (AFAIU, both C89 and C99 say it is impl-defined.)

Regards.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Portable Python - free portable development environment ! perica.zivkovic@gmail.com Python 7 01-13-2007 11:19 AM
portable (VHDL) vs. non-portable (altera LPM) approaches to signed computations Eli Bendersky VHDL 1 03-01-2006 02:43 PM
Ultra Mini Portable Disk Enclosure Review @ PC Modding Malay Silverstrand Front Page News 0 07-01-2005 01:33 AM
Portable alloca() replacement? Freejack C Programming 9 01-19-2005 08:18 AM
Replacement Floppy for Portable? DemoDisk Computer Support 2 10-20-2004 01:39 AM



Advertisments