By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,116 Members | 1,244 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,116 IT Pros & Developers. It's quick & easy.

Procedure for eliminating static variables?

P: n/a
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?

I don't call this code (it's Yacc output), so I can't suppy anything
on the stack.

Cheers

Ed
Aug 1 '05 #1
Share this Question
Share on Google+
27 Replies


P: n/a
Mr. Ed wrote:
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?

I don't call this code (it's Yacc output), so I can't suppy anything
on the stack.


[.. I read it in c.l.c++, so I am replying without cross-posting ..]

How are you going to use the "unique ID"? What does it ID? Which "each
time" is the time when you increment it?

V
Aug 1 '05 #2

P: n/a
Mr. Ed <ab***@[127.0.0.1]> writes:
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?


This is OT here.

It's also a bad method for generating unique IDs. Just as food for
thought, what happens when your program restarts? Do the "unique" IDs
roll back to an already used value?

Aug 1 '05 #3

P: n/a
Giorgos Keramidas wrote:
Mr. Ed <ab***@[127.0.0.1]> writes:
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?

This is OT here.


Where? And why?
[..]

Aug 1 '05 #4

P: n/a
On Mon, 01 Aug 2005 13:34:34 -0400, Victor Bazarov
<v.********@comAcast.net> wrote:
Mr. Ed wrote:
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?

I don't call this code (it's Yacc output), so I can't suppy anything
on the stack.


[.. I read it in c.l.c++, so I am replying without cross-posting ..]

How are you going to use the "unique ID"? What does it ID? Which "each
time" is the time when you increment it?


I was hoping to make the problem general, but this is the context of
my specific problem...

The auto-generated Yacc code calls one of my routines whenever it
finds a specific token. I want to append a rising sequence number to
the token before storing it, so that I can distinguish different
instances of the token. This is trivial enough; I just have a static
counter, and append the count to the token, incrementing the count
each time I get called.

The problem now is that I need to be multi-threaded, so I have to
eliminate my static counter. This is tricky (I think), since I'm not
responsible for calling my own code, so I can't put the count in the
caller, which is the obvious solution.

It seems that I need to find some way to put my count on a stack in
the current instance of the thread somewhere, but it's not obvious to
me that I can do this; hence my request for a "general" method for
eliminating statics.

Many thanks -

Ed
Aug 1 '05 #5

P: n/a
Mr. Ed wrote:
[..]
The auto-generated Yacc code calls one of my routines whenever it
finds a specific token. I want to append a rising sequence number to
the token before storing it, so that I can distinguish different
instances of the token. This is trivial enough; I just have a static
counter, and append the count to the token, incrementing the count
each time I get called.

The problem now is that I need to be multi-threaded, so I have to
eliminate my static counter. This is tricky (I think), since I'm not
responsible for calling my own code, so I can't put the count in the
caller, which is the obvious solution.

It seems that I need to find some way to put my count on a stack in
the current instance of the thread somewhere, but it's not obvious to
me that I can do this; hence my request for a "general" method for
eliminating statics.


I don't think I can be of much help, unfortunately. I would probably
simply keep the static, and to make sure it's now safely multithreaded,
I'd make the whole function a critical session. However, multithreading
is not part of the C++ language specification, so you might be better off
asking, say, in 'comp.programming.threads'.

Since you just want the token name made unique (instead of counting how
many of them were in any particular thread), keeping a static and making
it count _every_ call regardless what thread it was made from, should be
sufficient.

V
Aug 1 '05 #6

P: n/a
Mr. Ed wrote:
The auto-generated Yacc code calls one of my routines whenever it
finds a specific token. I want to append a rising sequence number to
the token before storing it, so that I can distinguish different
instances of the token. This is trivial enough; I just have a static
counter, and append the count to the token, incrementing the count
each time I get called.
The problem now is that I need to be multi-threaded, so I have to
eliminate my static counter. This is tricky (I think), since I'm not
responsible for calling my own code, so I can't put the count in the
caller, which is the obvious solution.


Bison has options to generate reentrant parsers, and you can add parameters
to the lexer and parser calls. You can switch to bison, usually is
compatible enough to addapt the yacc grammar file with no effort.

--
Salu2
Aug 1 '05 #7

P: n/a

Mr. Ed wrote:
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?


Assuming you're not using threads and just need to support recursive
calls,
why wouldn't this work?

int get_unique_id() { static int id; return ++id }

Aug 1 '05 #8

P: n/a
In article <1h********************************@4ax.com>,
Mr. Ed <ab***@[127.0.0.1]> wrote:
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?

I don't call this code (it's Yacc output), so I can't suppy anything
on the stack.


Yacc output is normally not re-entrant; you may have larger
problems than you realize.

If you are using a threading library, then there is probably
a mutex function available. If you are *not* using a threading
library then all forms of C re-entrancy would be compatible
with a single non-recursive function that increments a static
variable.

In another message you indicated that the uniqueness is only
needed during the lifetime of the program. An alternative way
of achieving this is to use the addresses of the objects as the
"unique" thing.
--
7842++
Aug 1 '05 #9

P: n/a
Victor Bazarov <v.********@comAcast.net> writes:
Giorgos Keramidas wrote:
Mr. Ed <ab***@[127.0.0.1]> writes:
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?

This is OT here.


Where? And why?


I realized I failed to specify "where". I meant in comp.lang.c, because
there is no explicit notion of "reentrancy" in the standard.
Aug 1 '05 #10

P: n/a
Giorgos Keramidas wrote:
Victor Bazarov <v.********@comAcast.net> writes:
Giorgos Keramidas wrote:
Mr. Ed <ab***@[127.0.0.1]> writes:
This should be easy, but I can't immediately see what the answer is...

I have some code which needs to be re-entrant. It also needs to create
a unique identifier. The obvious way to create a unique ID is to
maintain a static counter, and to increment it each time it's needed.
Any ideas on how to do this in a re-entrant way?

This is OT here.


Where? And why?

I realized I failed to specify "where". I meant in comp.lang.c, because
there is no explicit notion of "reentrancy" in the standard.


I am not sure what you consider "explicit". The C standard does say that
library functions are not reentrant, for example. From that I can only
conclude that the concept of "reentrancy" is considered _external_ to the
C Standard (and to C++ Standard AFAICT).

V
Aug 1 '05 #11

P: n/a
Wow - I hadn't realised that my use of a forbidden word would stir up
such a hornet's nest. Perhaps I could rephrase the problem in an
acceptable manner. Assume that I have a routine that does this:
int get_unique_id() { static int id; return ++id }


Now, also assume that for ideological reasons, I don't like to use
static variables. If you like, you can also imagine that I am
executing in an environment in which the keyword 'static' ensures that
this code won't work; it doesn't matter whether this is actually the
case, or why it won't work if this does happen to be the case.

Problem: is there a way to reformulate 'get_unique_id' so that:

1) 'id' is not in static storage; it should be on the stack somewhere

2) 'id' retains a memory of its value between function calls

3) The interface to 'get_unique_id' is unchanged

At first sight, this doesn't seem to be possible. The only obvious
solution is for the caller to save the current 'id' on their own
stack, and for 'get_unique_id' to increment it, but this isn't
possible because of constraint (3).

Any ideas?

Cheers

Ed
Aug 1 '05 #12

P: n/a
I don't think I can be of much help, unfortunately. I would probably
simply keep the static, and to make sure it's now safely multithreaded,
I'd make the whole function a critical session. However, multithreading
is not part of the C++ language specification, so you might be better off
asking, say, in 'comp.programming.threads'.

Since you just want the token name made unique (instead of counting how
many of them were in any particular thread), keeping a static and making
it count _every_ call regardless what thread it was made from, should be
sufficient.


Thanks Victor; I think you're probably right. I just wanted to check
that there wasn't a simpler fix. My code is already multithreaded so I
suppose an extra mutex isn't really a big deal.

Cheers

Ed
Aug 1 '05 #13

P: n/a
Mr. Ed wrote:
Wow - I hadn't realised that my use of a forbidden word would stir up
such a hornet's nest. Perhaps I could rephrase the problem in an
acceptable manner. Assume that I have a routine that does this:

int get_unique_id() { static int id; return ++id }

Now, also assume that for ideological reasons, I don't like to use
static variables. If you like, you can also imagine that I am
executing in an environment in which the keyword 'static' ensures that
this code won't work; it doesn't matter whether this is actually the
case, or why it won't work if this does happen to be the case.

Problem: is there a way to reformulate 'get_unique_id' so that:

1) 'id' is not in static storage; it should be on the stack somewhere


If it's on the stack, the only way to get to it would be to have its
address passed to this function. The "somewhere" makes it impossible
to do otherwise. However, that would go against the requirement 3 (the
interface is unchanged).
2) 'id' retains a memory of its value between function calls
That requires its location to be outside of any memory area that can
inadvertently be affected by functions being called or returning to
their caller. That essentially puts it _outside_ the stack. Now your
two requirements (1 and 2) are conflicting.
3) The interface to 'get_unique_id' is unchanged

At first sight, this doesn't seem to be possible. The only obvious
solution is for the caller to save the current 'id' on their own
stack, and for 'get_unique_id' to increment it, but this isn't
possible because of constraint (3).

Any ideas?


Nope.

You could have a bit more sophisticated mechanism if you needed counting
within each thread, but that falls outside the scope of the language since
it would require to obtain a thread id or some other thread-specific value
which you could use to store/retrieve the counter values in/from some kind
of a hash table (which itself will need to be static+dynamic).

V

P.S. I left the cross-posting to conjure the help of the colleagues from
the c.l.c group (which I don't visit any more). If that's contrary to the
rules, I apologize.
Aug 1 '05 #14

P: n/a
Mr. Ed wrote:
Now, also assume that for ideological reasons, I don't like to use
static variables. If you like, you can also imagine that I am
executing in an environment in which the keyword 'static' ensures that
this code won't work; it doesn't matter whether this is actually the (...) Any ideas?


The better idea may be to not imagine nonsenses and tell what the real
problem is. And if it is off-topic, to ask in other place.

--
Salu2
Aug 1 '05 #15

P: n/a


Mr. Ed wrote:
Wow - I hadn't realised that my use of a forbidden word would stir up
such a hornet's nest. Perhaps I could rephrase the problem in an
acceptable manner. Assume that I have a routine that does this:

int get_unique_id() { static int id; return ++id }

Now, also assume that for ideological reasons, I don't like to use
static variables. If you like, you can also imagine that I am
executing in an environment in which the keyword 'static' ensures that
this code won't work; it doesn't matter whether this is actually the
case, or why it won't work if this does happen to be the case.

Problem: is there a way to reformulate 'get_unique_id' so that:

1) 'id' is not in static storage; it should be on the stack somewhere

2) 'id' retains a memory of its value between function calls

3) The interface to 'get_unique_id' is unchanged

At first sight, this doesn't seem to be possible. The only obvious
solution is for the caller to save the current 'id' on their own
stack, and for 'get_unique_id' to increment it, but this isn't
possible because of constraint (3).

Any ideas?


How about an idea for an impossibility proof? Would that
make you happier? Here's a sketch:

Because the function is forbidden to use static variables
(by which I assume you mean "objects with static storage
duration, whether or not the `static' keyword is used"), it
can only access its own arguments and its own `auto' and
`register' variables. By constraint (3) there are no arguments,
and the other two possibilities do not meet the requirements
of constraint (2).

Dynamically-allocated storage won't help, because to make
use of its persistence (until freed) you'd need to communicate
a pointer value from one function invocation to another. The
argument above shows that no suitable channel exists -- and
besides: we know you're looking for re-entrancy, and malloc()
is not re-entrant. Nor, for that matter, are time() and clock()
and getc() and getenv() and any other Standard C library functions
you might use to query the state of the universe. No, not even
rand() is available.

You could form a pointer to an `auto' variable and try to
deduce something about the state of the stack. However, the C
Standard doesn't guarantee that `auto' variables reside on "the"
stack, nor even on "a" stack (although it's common implementation
practice). Besides, the only thing you can do with a pointer to
an `auto' variable is use it to refer to that variable, and do
a little simple arithmetic on the pointer -- the moment you start
trying to probe outside the `auto' variable itself, you're in the
land of undefined behavior. You certainly cannot use a pointer
to an `auto' variable to somehow locate a variable that belongs
to some caller somewhere.

So: Are you going to look for other approaches (several
have been suggested, but you're being so coy about your intent
that it's hard to choose between them), or are you going to
keep on trying to pound nails with a hacksaw?

--
Er*********@sun.com

Aug 1 '05 #16

P: n/a
In article <6q********************************@4ax.com>,
Mr. Ed <ab***@[127.0.0.1]> wrote:
int get_unique_id() { static int id; return ++id }


Problem: is there a way to reformulate 'get_unique_id' so that:

1) 'id' is not in static storage; it should be on the stack somewhere

2) 'id' retains a memory of its value between function calls

3) The interface to 'get_unique_id' is unchanged

Any ideas?


On many architectures the stack exists as plain old memory. You could
create a function that scans for a pre-arranged pattern of bytes lower
on the stack. When it finds the pattern, it looks immediately above
that for the counter. Not exactly efficent, or conforming, or
anything. Merely possible.
--
7842++
Aug 1 '05 #17

P: n/a
In article <1h********************************@4ax.com>,
Mr. Ed <ab***@[127.0.0.1]> wrote:
I have some code which needs to be re-entrant. It also needs to create
a unique identifier.


Standard C does not support re-entrancy except in a very limited way
using signals. It does however provide an integer type sig_atomic_t
which can be accessed atomically. This is sufficient to implement a
locking mechanism using for example Peterson's algorithm.

At the expense of some memory, you could malloc a small object and use
its address as a unique identifier, assuming your standard C library
supports re-entrancy.

-- Richard
Aug 2 '05 #18

P: n/a
In article <dc***********@pc-news.cogsci.ed.ac.uk>, I wrote:
Standard C does not support re-entrancy except in a very limited way
using signals. It does however provide an integer type sig_atomic_t
which can be accessed atomically. This is sufficient to implement a
locking mechanism using for example Peterson's algorithm.


Oops, this doesn't work for your case, because Peterson's algorithm
needs a shared variable for each process that might want to acquire
the lock. I'm not sure whether all similar algorithms have this
requirement.

-- Richard
Aug 2 '05 #19

P: n/a
Mr. Ed wrote:
Wow - I hadn't realised that my use of a forbidden word would stir up
such a hornet's nest. Perhaps I could rephrase the problem in an
acceptable manner. Assume that I have a routine that does this:
int get_unique_id() { static int id; return ++id }
Now, also assume that for ideological reasons, I don't like to use
static variables. If you like, you can also imagine that I am
executing in an environment in which the keyword 'static' ensures that
this code won't work; it doesn't matter whether this is actually the
case, or why it won't work if this does happen to be the case.

Problem: is there a way to reformulate 'get_unique_id' so that:

1) 'id' is not in static storage; it should be on the stack somewhere

2) 'id' retains a memory of its value between function calls


These two points are contradictory. You cannot change the lifetime of
automatic objects, so that rules out local objects.
3) The interface to 'get_unique_id' is unchanged


But you can change the implementation, can you?

I don't have much experience with threads, so I can be completly wrong
here. But here's a suggestion.

What about a global variable? If the function is responsible for
synchronizing access, it should be possible, no? Or a Singleton which
does not use a static instance (not "Meyer's singleton")?

But if no one proposed this solution, it is probably because it's
wrong. If it is, I'd like to know why.
Jonathan

Aug 2 '05 #20

P: n/a
On 1 Aug 2005 18:22:41 -0700, "Jonathan Mcdougall"
<jo***************@gmail.com> wrote:
What about a global variable? If the function is responsible for
synchronizing access, it should be possible, no? Or a Singleton which
does not use a static instance (not "Meyer's singleton")?

But if no one proposed this solution, it is probably because it's
wrong. If it is, I'd like to know why.


This basically just moves the problem. A global variable is fine, if
you're willing to take the hit of synchronising access to it from
multiple threads (the variable needs to be incremented, or changed in
some way, so access to it must be protected). I was hoping to find
some way of avoiding this overhead, but it doesn't seem to be
possible.

Thanks

Ed
Aug 2 '05 #21

P: n/a
On Mon, 01 Aug 2005 17:32:29 -0400, Eric Sosman <er*********@sun.com>
wrote:
So: Are you going to look for other approaches (several
have been suggested, but you're being so coy about your intent
that it's hard to choose between them), or are you going to
keep on trying to pound nails with a hacksaw?


I wasn't intending to be coy; I was trying to find out if anyone knew
of a simple, generalised, language-conformant mechanism to replace
statics which are required to keep persistent data when making code
thread-safe. But, I agree, this seems to be impossible.

Given that, the actual solution(s) are simple, though hardly
efficient. The first is to use thread-specific data (for pthreads,
pthread_key_t/etc.); and the second is to synchronise access to
critical variables.

Cheers

Ed
Aug 2 '05 #22

P: n/a
On Mon, 01 Aug 2005 17:32:29 -0400, Eric Sosman wrote:

....
we know you're looking for re-entrancy, and malloc()
is not re-entrant. Nor, for that matter, are time() and clock()
and getc() and getenv() and any other Standard C library functions
you might use to query the state of the universe. No, not even
rand() is available.


That may not matter. Just because access to an object is concurrent
in a program doesn't imply creation of that object is. And in an
environment that supports threads malloc() and other standard functions
are likely to be guaranteed reentrant.

Lawrence

Aug 2 '05 #23

P: n/a
Mr. Ed wrote:
On Mon, 01 Aug 2005 17:32:29 -0400, Eric Sosman <er*********@sun.com>
wrote:

So: Are you going to look for other approaches (several
have been suggested, but you're being so coy about your intent
that it's hard to choose between them), or are you going to
keep on trying to pound nails with a hacksaw?


I wasn't intending to be coy; I was trying to find out if anyone knew
of a simple, generalised, language-conformant mechanism to replace
statics which are required to keep persistent data when making code
thread-safe. But, I agree, this seems to be impossible.

Given that, the actual solution(s) are simple, though hardly
efficient. The first is to use thread-specific data (for pthreads,
pthread_key_t/etc.); and the second is to synchronise access to
critical variables.


"Hardly efficient ..." Y'know, spraying water on a burning
house isn't very efficient either. A lot of energy could be
saved by not running all those heavy-duty water pumps, a lot of
distress and danger could be avoided by not sending the fire
engines through the streets at high speeds, a lot of tax money
could be put to better uses if it weren't squandered on fire
brigades. Let's hear it for efficiency!

In other words, it is an error to consider "efficiency" a
make-or-break criterion. Begin with "efficacy" instead: Does
the method solve the problem? "Efficiency" is one of several
measures that you might use to choose among different methods
that solve the problem, but it is pointless to use it to compare
solutions to non-solutions.

Here, for your reading pleasure, is the World's Most Efficient
Program for factoring numbers of six million bits:

int main(void) {
return 0;
}

There are one or two minor omissions in the output, but surely
the blinding speed and overall efficiency more than compensate.

--
Eric Sosman
es*****@acm-dot-org.invalid
Aug 2 '05 #24

P: n/a
Eric Sosman wrote:

Mr. Ed wrote:
On Mon, 01 Aug 2005 17:32:29 -0400, Eric Sosman <er*********@sun.com>
wrote:

So: Are you going to look for other approaches (several
have been suggested, but you're being so coy about your intent
that it's hard to choose between them), or are you going to
keep on trying to pound nails with a hacksaw?


I wasn't intending to be coy; I was trying to find out if anyone knew
of a simple, generalised, language-conformant mechanism to replace
statics which are required to keep persistent data when making code
thread-safe. But, I agree, this seems to be impossible.

Given that, the actual solution(s) are simple, though hardly
efficient. The first is to use thread-specific data (for pthreads,
pthread_key_t/etc.); and the second is to synchronise access to
critical variables.


"Hardly efficient ..." Y'know, spraying water on a burning
house isn't very efficient either. A lot of energy could be
saved by not running all those heavy-duty water pumps, a lot of
distress and danger could be avoided by not sending the fire
engines through the streets at high speeds, a lot of tax money
could be put to better uses if it weren't squandered on fire
brigades. Let's hear it for efficiency!

In other words, it is an error to consider "efficiency" a
make-or-break criterion. Begin with "efficacy" instead: Does
the method solve the problem? "Efficiency" is one of several
measures that you might use to choose among different methods
that solve the problem, but it is pointless to use it to compare
solutions to non-solutions.

Here, for your reading pleasure, is the World's Most Efficient
Program for factoring numbers of six million bits:

int main(void) {
return 0;
}

There are one or two minor omissions in the output, but surely
the blinding speed and overall efficiency more than compensate.


We could really make that efficient in assembly language :-)

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Aug 2 '05 #25

P: n/a
CBFalconer <cb********@yahoo.com> writes:
Eric Sosman wrote:

[...]
Here, for your reading pleasure, is the World's Most Efficient
Program for factoring numbers of six million bits:

int main(void) {
return 0;
}

There are one or two minor omissions in the output, but surely
the blinding speed and overall efficiency more than compensate.


We could really make that efficient in assembly language :-)


Nah, implement it in special-purpose hardware.

And since we already know the result, we can optimize it further by
not building the hardware.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Aug 2 '05 #26

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
CBFalconer <cb********@yahoo.com> writes:
Eric Sosman wrote:
Here, for your reading pleasure, is the World's Most Efficient
Program for factoring numbers of six million bits:
int main(void) {
return 0;
}
We could really make that efficient in assembly language :-)
Nah, implement it in special-purpose hardware. And since we already know the result, we can optimize it further by
not building the hardware.


You -have- to build it -- the bugs in the design documents will
require multiple iterations to resolve.
I cannot find the reference at the moment, but in comp.risks several
years ago, there was a brief discussion of the old IBM 360/370
library's "null subroutine". One correspondant reported that it
had gone through a number of versions for bug fixes. For example,
apparently it was in place for a number of years before anyone noticed
that it failed to set the return code properly...
--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD
Aug 2 '05 #27

P: n/a
>>>> Here, for your reading pleasure, is the World's Most Efficient
Program for factoring numbers of six million bits:
int main(void) {
return 0;
} We could really make that efficient in assembly language :-)

Nah, implement it in special-purpose hardware.

And since we already know the result, we can optimize it further by
not building the hardware.


You -have- to build it -- the bugs in the design documents will
require multiple iterations to resolve.
I cannot find the reference at the moment, but in comp.risks several
years ago, there was a brief discussion of the old IBM 360/370
library's "null subroutine". One correspondant reported that it
had gone through a number of versions for bug fixes. For example,
apparently it was in place for a number of years before anyone noticed
that it failed to set the return code properly...


There was a related "null program" called IEFBR14. Or perhaps
this is what was being referred to. The original code for it was
BR 14
(branch to the return address in register 14).
There was the problem with the return code, and lots of arguments
over the correct and fastest way to fix it. Add one of the instructions:
LA 15,0 (load immediate value of 0)
XR 15,15 (zero register with exclusive-or)
SR 15,15 (zero register with subtract)
but which one? On different models the tradeoffs were different.

This program was actually useful since you could use DD JCL
statements to delete scratch files and such (sometimes
conditionally). An interesting problem with it was that
if you gave it a region of memory smaller than something
like 8K, it would fail and dump core (onto the printer).
I actually used it in the early 70's.

Gordon L. Burditt
Aug 2 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.