What is the meaning of the term open coded in the following extract

[parag_paul]

I was looking into the following page
http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html
Here there is a term open-coded , why to ?

And I saw the following definition for long long
5.8 Double-Word Integers

ISO C99 supports data types for integers that are at least 64 bits
wide, and as an extension GCC supports them in C89 mode and in C++.
Simply write long long int for a signed integer, or unsigned long long
int for an unsigned integer. To make an integer constant of type long
long int, add the suffix `LL' to the integer. To make an integer
constant of type unsigned long long int, add the suffix `ULL' to the
integer.

You can use these types in arithmetic like any other integer types.
Addition, subtraction, and bitwise boolean operations on these types
are open-coded on all types of machines. Multiplication is open-coded
if the machine supports fullword-to-doubleword a widening multiply
instruction. Division and shifts are open-coded only on machines that
provide special support. The operations that are not open-coded use
special library routines that come with GCC.

There may be pitfalls when you use long long types for function
arguments, unless you declare function prototypes. If a function
expects type int for its argument, and you pass a value of type long
long int, confusion will result because the caller and the subroutine
will disagree about the number of bytes for the argument. Likewise, if
the function expects long long int and you pass int. The best way to
avoid such problems is to use prototypes.

 

[Walter Roberson]

I was looking into the following page
http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html
Here there is a term open-coded , why to ?

http://sbcl.sourceforge.net/manual/Open-Coding-and-Inline-Expansion.html


When a function call is open coded, inline code whose effect is
equivalent to the function call is substituted for that function
call. When a function call is closed coded, it is usually left as
is, although it might be turned into a call to a different
function with different arguments.


That is, if something is open-coded, there is no actual function
call made, just equivilent code dropped into place; close-coded
results in a call to -some- function.

 

[Chris Torek]

[This has nothing to do with C, really, except insofar as those
who assume compilers map source code one-to-one onto the "obvious"
equivalent assembly code get surprised. Of course, such assumptions
are not guaranteed by Standard C.]

http://sbcl.sourceforge.net/manual/Open-Coding-and-Inline-Expansion.html

When a function call is open coded, inline code whose effect is
equivalent to the function call is substituted for that function
call. When a function call is closed coded, it is usually left as
is, although it might be turned into a call to a different
function with different arguments.

That is, if something is open-coded, there is no actual function
call made, just equivilent code dropped into place; close-coded
results in a call to -some- function.

In compiler circles, the phrase "open coded" is even more general
than that. For instance, some machines have a fancy instruction
to do several steps of some computation, such as a POLY instruction
to calculate polynomials, or an INDEX instruction to use array
subscripts (sometimes with build-in builds-checking).

As it turns out, on some particular of the given architecture, it
is faster to execute a series of multiple simpler instructions than
to use the fancy instruction. This used to occur more often with
microcoded systems with optional acceleration hardware -- for
instance, INDEX might micro-code a multiply, taking dozens of clock
cycles, while a simpler MUL and then ADD uses the hardware multiplier
and hence finishes in only a few clock cycles. These days it tends
to happen instead with parallel-issue microprocessors: for instance,
the x86 ENTER instruction is slower, on some x86 CPUs, than the
equivalent sequence of instructions. (This is especially true if
the compiler can omit several steps due to some specific knowledge,
e.g., "we know there is no need for separate stack and frame
pointers, nor for any stack adjustment, in this leaf function".)

Compiler folks will say things like "we open coded the function entry
and exit" when they avoid using the slow ENTER and EXIT instructions.

 

[parag_paul]

hi Chris,
When you say build-in builds checking, You mean built in builds
checking.
Is that correct? Look at your comments below

That is, if something is open-coded, there is no actual function
call made, just equivilent code dropped into place; close-coded
results in a call to -some- function.

In compiler circles, the phrase "open coded" is even more general
than that. For instance, some machines have a fancy instruction
to do several steps of some computation, such as a POLY instruction
to calculate polynomials, or an INDEX instruction to use array
subscripts (sometimes with build-in builds-checking).

 

[santosh]

hi Chris,
When you say build-in builds checking, You mean built in builds
checking.
Is that correct? Look at your comments below

I may be wrong but I think Chris meant to write "built-in bounds-checking."