Ask an old kerword "entry"

L

Lung.S.wu

Hi all,

It is a history question.

Recently, I read the book "C A reference manual, third edition".
In this book, it list all C language keyword, and one is "entry".
I know it is omitted from ANSCI C, but I hope I can find any data
about it.

Doea any one know how to use it, before?
Thanks
 
M

mark_bluemel

Hi all,

It is a history question.

Recently, I read the book "C A reference manual, third edition".
In this book, it list all C language keyword, and one is "entry".
I know it is omitted from ANSCI C, but I hope I can find any data
about it.

Doea any one know how to use it, before?

The original Kernighan and Ritchie book says that it was reserved as a
keyword, but not implemented by any compiler - they don't give any
more detail. They presumably had a feeling that they might need such a
keyword, and some idea what they would use it for, but the need never
actually materialized.
 
K

Keith Thompson

The original Kernighan and Ritchie book says that it was reserved as a
keyword, but not implemented by any compiler - they don't give any
more detail. They presumably had a feeling that they might need such a
keyword, and some idea what they would use it for, but the need never
actually materialized.

I think some versions of Fortran have an "entry" keyword, allowing
more than one entry point to be specified for a subroutine. (I don't
know whether this survived into modern Fortran.) For example,
in pseudo-C:

void foo(void)
{
printf("FOO ");
entry bar:
printf("BAR\n");
}

Calling foo() would print "FOO BAR"; calling bar() would print "BAR".
(Presumably there would be some declaration syntax to make the name
"bar" visible to the caller.)

I've seen a more realistic example that combines sin() and cos() into
a single function. Calling it through the primary entry point would
adjust the argument; the remainder of the function, after the
secondary entry point, would compute the sine of the (possibly
adjusted) argument, which happens to be the cosine of the unadjusted
argument.
 
M

Martin Ambuhl

Keith said:
I think some versions of Fortran have an "entry" keyword, allowing
more than one entry point to be specified for a subroutine. (I don't
know whether this survived into modern Fortran.)

ENTRY is part of modern Fortran (at least through F95). F77 relaxed the
restrictions on its use, making it even more common than F66. The
current syntax has added a RESULT clause that it did not have earlier.

F2C and g77 both compiled a separate copy for each entry, so your
pseudo-C example, if it were the equivalent Fortran,
void foo(void)
{
printf("FOO ");
entry bar:
printf("BAR\n");
}

would be compiled as it it were written
void foo(void)
{
printf("FOO ");
printf("BAR\n");
}
void bar(void)
{
printf("BAR\n");
}
 
F

Francine.Neary

Keith Thompson wrote:
would be compiled as it it were written
void foo(void)
{
printf("FOO ");
printf("BAR\n");
}
void bar(void)
{
printf("BAR\n");
}

That's crazy! Why not one function, an extra argument (or global
variable), and an if or switch at the start of the function?
 
K

Keith Thompson

That's crazy! Why not one function, an extra argument (or global
variable), and an if or switch at the start of the function?

(There's some context missing here; I didn't write any of the quoted
material.)

The use of the "entry" keyword, assuming the compiler doesn't
duplicate code as described above, allows a small improvement in code
size and speed. You don't have the overhead of passing the extra
argument or of doing a test on entry, and you don't have two copies of
what might be a substantial amount of code. There have been
situations where that might be significant, such as early Fortran
systems, where using Fortran (or any high-level language) was a
sometimes controversial alternative to hand-coded assembly language
(or even machine language).

The functionality that "entry" would provide is something that can be
expressed straightforwardly in assembly language; that's probably why
it was included in Fortran.

The implementation that Martin describes might just have been the
easiest way to implement it, for the purpose of supporting old code
that depended on it (but that, if it's running on modern hardware,
isn't affected by the limitations that existed when it was first
written).

Note, however, that the authors of the C standard apparently agreed
with you (and with me) that it's not worthwhile; the "entry" keyword
was never implemented and did not survive past K&R1.
 
K

Kevin Handy

Keith said:
I think some versions of Fortran have an "entry" keyword, allowing
more than one entry point to be specified for a subroutine. (I don't
know whether this survived into modern Fortran.) For example,
in pseudo-C:

void foo(void)
{
printf("FOO ");
entry bar:
printf("BAR\n");
}
The 'bar' function here has no prototype. How is it
supposed to handle parameters?

You can use the following, which gives you the same functionality

void foo(void)
{
printf("FOO ";
bar();
}
void bar(void)
{
printf("BAR\n");
}

which should work on all current C compilers, and does
exactly what you are trying to do. And if you later
need to create a "FUU BAR" message, you can just add

void fuu(void)
{
printf("FUU ";
bar();
}

Many compilers can optimize the jump from foo to bar
using a "jump" instead of a "call", automatically
dealing with any parameters passed.
Calling foo() would print "FOO BAR"; calling bar() would print "BAR".
(Presumably there would be some declaration syntax to make the name
"bar" visible to the caller.)

I've seen a more realistic example that combines sin() and cos() into
a single function. Calling it through the primary entry point would
adjust the argument; the remainder of the function, after the
secondary entry point, would compute the sine of the (possibly
adjusted) argument, which happens to be the cosine of the unadjusted
argument.

You can handle it as above, or, you can deal with it
as a #define or an inline function

#define cos(x) = sin((x) + PI/4)

(or whatever the proper transformation is.)
 
K

Keith Thompson

Kevin Handy said:
The 'bar' function here has no prototype. How is it
supposed to handle parameters?

I don't know. The snippet above, as I said, is pseudo-C, intended to
represent an old Fortran feature that I'm not very familiar with. But
since the "entry" keyword in C died before the ANSI standard was
written, presumably prototypes wouldn't have been required.

But if the feature were to be implemented in C, the obvious semantics
would be that bar() would share the same prototype as foo().
You can use the following, which gives you the same functionality [snip]
Many compilers can optimize the jump from foo to bar
using a "jump" instead of a "call", automatically
dealing with any parameters passed.

Certainly. The "entry" keyword, as I understand it, was intended to
support a particular micro-optimization, something that's probably
easy to implement in assembly language but difficult to express
directly in C.

[...]
You can handle it as above, or, you can deal with it
as a #define or an inline function

#define cos(x) = sin((x) + PI/4)

(or whatever the proper transformation is.)

Yes, the "entry" keyword is unnecessary; that's why it's no longer in
the language. I was merely trying to explain it; I certainly wasn't
advocating it.
 
R

Richard Harter

Kevin Handy said:
The 'bar' function here has no prototype. How is it
supposed to handle parameters?

I don't know. The snippet above, as I said, is pseudo-C, intended to
represent an old Fortran feature that I'm not very familiar with. But
since the "entry" keyword in C died before the ANSI standard was
written, presumably prototypes wouldn't have been required.

But if the feature were to be implemented in C, the obvious semantics
would be that bar() would share the same prototype as foo().
You can use the following, which gives you the same functionality [snip]
Many compilers can optimize the jump from foo to bar
using a "jump" instead of a "call", automatically
dealing with any parameters passed.

Certainly. The "entry" keyword, as I understand it, was intended to
support a particular micro-optimization, something that's probably
easy to implement in assembly language but difficult to express
directly in C.

[...]
You can handle it as above, or, you can deal with it
as a #define or an inline function

#define cos(x) = sin((x) + PI/4)

(or whatever the proper transformation is.)

That, perhaps, is an illustration of the benefits of "entry". The proper
transformation can be encapsulated in the routine body.
Yes, the "entry" keyword is unnecessary; that's why it's no longer in
the language. I was merely trying to explain it; I certainly wasn't
advocating it.

It is not so much that it is unnecessary as it is that it inconsistent with
how C is typically implemented. Languages with multiple entry point
routines usually presuppose that the data for a call is in a fixed location
rather than on a stack. The original fortran was like that; recursion was
impossible.
 

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

Forum statistics

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

Latest Threads

Top