replacing builtin_expect with normal code

S

Skybuck Flying

Hi,

if (__builtin_expect (!buffer->__init, 0))
{
buffer->__a = 0x5deece66dull;
buffer->__c = 0xb;
buffer->__init = 1;
}

I am using visual c 6 and this code doesn't compile, it's probably not
supported.

How do I replace this code with normal code... I would also like to port
this code to some other language in the future so it need to replaced
anyway.

Apperently this function is for branch prediction.

It indicates that we don't expect the field buffer->init to be zero. How do
I have to interpret that to change it to normal code ?

Maybe this:

if (buffer->__init == 0)
{
buffer->__a = 0x5deece66dull;
buffer->__c = 0xb;
buffer->__init = 1;
}

Yeah, probably since it sets init to 1 afterwards ;)

Keep it simple :D

Would this complex code do the same I wonder:

if (!buffer->__init != 0)

Bye,
Skybuck.
 
J

Jens.Toerring

Skybuck Flying said:
if (__builtin_expect (!buffer->__init, 0))
{
buffer->__a = 0x5deece66dull;
buffer->__c = 0xb;
buffer->__init = 1;
}
I am using visual c 6 and this code doesn't compile, it's probably not
supported.
How do I replace this code with normal code... I would also like to port
this code to some other language in the future so it need to replaced
anyway.

Noone here can tell you since there's no real information in your
post what that function does and it's not a standard C function.
Having identifiers start with an underscore indicates that you're
dabbling with stuff that is extremely system/compiler dependend
and thus off-topic here. If this is something you picked from
visual c's header files ask in a group that discusses that com-
piler, one of the millions of MS groups should do. If it's from
somewhere else ask in the corresponding newsgroup or mailing list.
Here's the wrong place.
Regrads, Jens
 
S

Skybuck Flying

Noone here can tell you since there's no real information in your
post what that function does and it's not a standard C function.
Having identifiers start with an underscore indicates that you're
dabbling with stuff that is extremely system/compiler dependend
and thus off-topic here. If this is something you picked from
visual c's header files ask in a group that discusses that com-
piler, one of the millions of MS groups should do. If it's from
somewhere else ask in the corresponding newsgroup or mailing list.
Here's the wrong place.

It was from code written on unix ?!

The weird thing is... it seems 1. very old code... and 2. very new code ???
or maybe 2 is not true.

Since this function is for AMD64's bit processor branch prediction...

At least that's what I believe and read at a google ;)

It's C code how can it possible be off topic ? :)

Skybuck.
 
J

Jens.Toerring

It was from code written on unix ?!
The weird thing is... it seems 1. very old code... and 2. very new code ???
or maybe 2 is not true.

Compilers and libraries have to deal with legacy code, so the code
usually looks rather ugly and is hard to understand.
Since this function is for AMD64's bit processor branch prediction...

Nobody cares here. It could equally well be XYZ123 blurb exdecition code
or code to control the Marsian water supplies (at least that would make
it a bit more exciting;-)
At least that's what I believe and read at a google ;)
It's C code how can it possible be off topic ? :)

Because this newsgroup isn't about all possible programs that can be
written in C and extensions to it etc., but about programming in
standard, portable C. If the guys that wrote the program you're
struggling with had written it in standard C you wouldn't have the
problems you seem to have know, because then you just could copy this
program to some other system, compile it and be done with it. So,
everything related to certain processors or compilers or hardware
aspects is off-topic here (maybe unless when used in examples why one
shouldn't do certain things you can do in C but better don't).

And you should better stop trying to get that ugly, necessarily system
dependend code to work but should try to figure out the algorithm
that's used (which you can even read up on on the net) and re-implement
it in a clean fashion. You would learn something useful that way.

Regards, Jen
 
S

Skybuck Flying

Compilers and libraries have to deal with legacy code, so the code
usually looks rather ugly and is hard to understand.


Nobody cares here. It could equally well be XYZ123 blurb exdecition code
or code to control the Marsian water supplies (at least that would make
it a bit more exciting;-)



Because this newsgroup isn't about all possible programs that can be
written in C and extensions to it etc., but about programming in
standard, portable C. If the guys that wrote the program you're
struggling with had written it in standard C you wouldn't have the
problems you seem to have know, because then you just could copy this
program to some other system, compile it and be done with it. So,
everything related to certain processors or compilers or hardware
aspects is off-topic here (maybe unless when used in examples why one
shouldn't do certain things you can do in C but better don't).

Well since I am not a real C programmer... how do I know what is ansi
c/portable c and what's not ?

Also this code is from unix... C was created for/from unix ?

I can see how unix libraries etc have evolved... and I can understand that
nrand48() is not part of the ansi C standard.

However... how about __builtin_expect this has to do with branch prediction
apperently etc.. so I can see how this might evolve into an ANSI C
standard...

Or is the ANSI C standard completely frozen ? :)

None the less, I also totally don't care about the implementation of builtin
expect... I do care about how to replace the concept in portable/ansi C :)
And you should better stop trying to get that ugly, necessarily system
dependend code to work but should try to figure out the algorithm
that's used (which you can even read up on on the net) and re-implement
it in a clean fashion. You would learn something useful that way.

I tried understanding the algorithm... Unfortunately for me all the
documentation that I found is very hard to understand and doesn't even talk
about pseudo code etc...

So I am better off trying out some already made code... seeing if it
works... seeing how it works...

Currently I am interesting to see

1. How the programs work with files.. ?
2. If it is able to recover from errors.
3. Then I can go try and understand the code a bit better
4. Then I can go reverse engineer it =D
5. Then I might make a new clean implementation or convert some stuff to my
favorite language which I won't mention here lol :D

Skybuck.
 
J

Jens.Toerring

Skybuck Flying said:
Well since I am not a real C programmer... how do I know what is ansi
c/portable c and what's not ?

You can find out what ANSI C functions are by looking them up e.g.
in a reasonably good book on C (or by buying the standard, but
since it's written in a rather difficult to understand language,
you're probably better of with a book). If you have some UNIX
system these function are also usually marked in the "CONFORMING
TO" section of the man page as conforming to standard C (either the
"old" C89 standard or/and the "new" C99 standard).
Also this code is from unix... C was created for/from unix ?

There are probably millions of programs written for UNIX that
are not written in standard C but using some system specific
extensions. These then are to be discussed in for example
comp.unix.programmer.
I can see how unix libraries etc have evolved... and I can understand that
nrand48() is not part of the ansi C standard.
However... how about __builtin_expect this has to do with branch prediction
apperently etc.. so I can see how this might evolve into an ANSI C
standard...

"Branch prediction" is something that is relevant for only a subset
of all existing processors. But standard C tries to stay as far as
humanly possible from any system specific stuff, so you probably
will never see anything related to "branch prediction" in the standard.
Actually, "branch prediction" is something that might or might not
become relevant in the _implementation_ of a C compiler for a specific
platform. But the C standard is just about the language, not how it
is actually realized on a certain system. It's like the difference
between some electronic circuitry you draw on some piece of paper
and what you solder together according to that schematics. When you
draw the circuitry you usually don't give too much thought to the
resistance of the wires connecting the parts or some stray capacitances
or impedances. These problems usually come into play only when you
really start soldering stuff together ("implement" the circuitry).
Or is the ANSI C standard completely frozen ? :)

Yes, of course. But some people are probably already working on
a new version.
None the less, I also totally don't care about the implementation of builtin
expect... I do care about how to replace the concept in portable/ansi C :)
I tried understanding the algorithm... Unfortunately for me all the
documentation that I found is very hard to understand and doesn't even talk
about pseudo code etc...
So I am better off trying out some already made code... seeing if it
works... seeing how it works...

Well, the algorithm is rather simple and is described in

http://www.opengroup.org/onlinepubs/009695399/functions/drand48.html

When you have an element X_n of the series of pseudo-random numbers
you get the next one, X_n+1, by applying the formula

X_n+1 = ( a * X_n + c ) mod m n >= 0

That's what's called a "linear congruential algorithm". The numbers
a, c and m are (at least for nrand48())

a = 0x5DEECE66D = 0273673163155
b = 0xB = 013
m = 2^48

where numbers starting with '0x' are in hexadecimal and numbers starting
with just '0' are in octal. 2^48 means 2 to the power of 48. All the
X_n's are 48-bit numbers and the value returned by the function is X_n+1
after taking the top-most 31 bits and shifting them right by 17 bits.
Unless you seed the ramdom generator (using seed48()) it will start with
X_0 being 0.

The important part now is that the calculations have to be done in a
way in which you don't lose (too many) bits by integer overflows. That
could be the difficult part of it. As far as I can see, the code you
showed don't really care about overflows - it does the multiplication
without much regard for possible overflows when using 64-bit wide
variables, making things rather simple (but I don't know if every
implementation of nrand48() deals with this in the same way, so you
might find out that your version of nrand48() delivers a different
sequence of random numbers than the nrand48() function from some other
machine.)

Actually, I am still not convinced that you really need any special
properties of nrand48() but would guess that any reasonable pseudo-
random generator delivering numbers in the interval [0,2^31) (i.e.
between 0 and 2^31 - 1) would also do. Probably the rand() function
would do just fine...
Regards, Jens
 
S

Skybuck Flying

None the less, I also totally don't care about the implementation of
builtin
:)



Well, the algorithm is rather simple and is described in

http://www.opengroup.org/onlinepubs/009695399/functions/drand48.html

When you have an element X_n of the series of pseudo-random numbers
you get the next one, X_n+1, by applying the formula

Oh, I thought you ment the LDPC algorithm... That's what I am interesting in
:)

I am not really interested in random number generator algorithms...

I just need nrand48() to work so I can see how the LDPC code/algorithm works
:D

Bye,
Skybuck.
 
E

Emmanuel Delahaye

In 'comp.lang.c', (e-mail address removed)-berlin.de wrote:

Actually, I am still not convinced that you really need any special
properties of nrand48() but would guess that any reasonable pseudo-
random generator delivering numbers in the interval [0,2^31) (i.e.
between 0 and 2^31 - 1) would also do. Probably the rand() function
would do just fine...
Regards, Jens

I admire your patience.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top