Home > Archive > ASM370 > March 2004 > Last Time NOP Brain Teaser
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Last Time NOP Brain Teaser
|
|
| RFCOMMSYS 2004-03-19, 8:28 pm |
| I'm sure we've all seen a "First Time NOP", typically:
NOP SOMEWHER
OI *-3,X'F0'
On first execution, the NOP falls through to the OI, which changes the NOP to a
B. On subsequent executions, it branches to SOMEWHER. Note that the code
doesn't test any condition or storage external to itself to "know" it's the
first time, nor is it modified by anything outside of itself. This code can be
used in any program, regardless of the specific application. (Let's ignore RENT
considerations for purposes of this discussion).
There's also the FIRST TIME BRANCH:
NOP *+12
OI *-3,X'F0'
B SOMEWHER
Where the branch to SOMEWHER occurs only the first time.
I want to see someone design a LAST TIME NOP (or branch). The rules are that
you can't "cheat" by testing any condition or storage external to the actual
code itself, nor can the code be modified by anything outside of itself. It
should be useable in any application (again, forget RENT stuff). The action
(NOP or BRANCH) can only be taken the LAST TIME the code is executed.
| |
| Binyamin Dissen 2004-03-19, 8:28 pm |
| On 23 Nov 2003 18:50:33 GMT rfcommsys@aol.com (RFCOMMSYS) wrote:
:>I want to see someone design a LAST TIME NOP (or branch). The rules are that
:>you can't "cheat" by testing any condition or storage external to the actual
:>code itself, nor can the code be modified by anything outside of itself. It
:>should be useable in any application (again, forget RENT stuff). The action
:>(NOP or BRANCH) can only be taken the LAST TIME the code is executed.
Other than the trivial cases of clearing storage or loading a wait state PSW,
i.e., the routine setting conditions that it can never be re-executed, it is
impossible without knowledge of what causes the routine to be executed.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
| |
|
| Exactly. You cannot predict the future. The examples listed show knowledge of
the past, not the future.
"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
news:0v02svce1ortusdpds4iivvtq9qsl3kj8t@
4ax.com...
> On 23 Nov 2003 18:50:33 GMT rfcommsys@aol.com (RFCOMMSYS) wrote:
>
> :>I want to see someone design a LAST TIME NOP (or branch). The rules are that
> :>you can't "cheat" by testing any condition or storage external to the actual
> :>code itself, nor can the code be modified by anything outside of itself. It
> :>should be useable in any application (again, forget RENT stuff). The action
> :>(NOP or BRANCH) can only be taken the LAST TIME the code is executed.
>
> Other than the trivial cases of clearing storage or loading a wait state PSW,
> i.e., the routine setting conditions that it can never be re-executed, it is
> impossible without knowledge of what causes the routine to be executed.
>
> --
> Binyamin Dissen <bdissen@dissensoftware.com>
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
| |
| glen herrmannsfeldt 2004-03-19, 8:28 pm |
| xarax wrote:
> Exactly. You cannot predict the future. The examples listed show knowledge of
> the past, not the future.
Consider phase conjugate optics, where given an optical signal a device
will create the time reversed version of the signal.
Also, consider compilers with a COME FROM statement, that does the
opposite of the GO TO statement.
-- glen
| |
| Sven Pran 2004-03-19, 8:28 pm |
|
"RFCOMMSYS" <rfcommsys@aol.com> wrote in message
news:20031123135033.02030.00000736@mb-m16.aol.com...
> I'm sure we've all seen a "First Time NOP", typically:
>
> NOP SOMEWHER
> OI *-3,X'F0'
>
> On first execution, the NOP falls through to the OI, which changes the NOP
to a
> B. On subsequent executions, it branches to SOMEWHER. Note that the code
> doesn't test any condition or storage external to itself to "know" it's
the
> first time, nor is it modified by anything outside of itself. This code
can be
> used in any program, regardless of the specific application. (Let's ignore
RENT
> considerations for purposes of this discussion).
>
> There's also the FIRST TIME BRANCH:
>
> NOP *+12
> OI *-3,X'F0'
> B SOMEWHER
>
> Where the branch to SOMEWHER occurs only the first time.
>
>
> I want to see someone design a LAST TIME NOP (or branch). The rules are
that
> you can't "cheat" by testing any condition or storage external to the
actual
> code itself, nor can the code be modified by anything outside of itself.
It
> should be useable in any application (again, forget RENT stuff). The
action
> (NOP or BRANCH) can only be taken the LAST TIME the code is executed.
>
>
>
Just how do you know that it is the last time?
Sven
| |
| Sven Pran 2004-03-19, 8:28 pm |
|
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:Cgawb.217404$275.810476@attbi_s53...
> xarax wrote:
>
knowledge of[color=darkred]
>
> Consider phase conjugate optics, where given an optical signal a device
> will create the time reversed version of the signal.
>
> Also, consider compilers with a COME FROM statement, that does the
> opposite of the GO TO statement.
>
> -- glen
>
COME FROM is no problem, any decent trouble diagnostics program includes
that for a traceback of the calling sequence leading up to the error.
Reversing time to see what the future will bring seems, well Startrek
technology
some 500 years ahead of us?
Sven
| |
| RFCOMMSYS 2004-03-19, 8:28 pm |
| Sven Pran said ---
>
>
>Just how do you know that it is the last time?
>
>
Ah, how indeed ...
| |
|
| RFCOMMSYS wrote:
> I want to see someone design a LAST TIME NOP (or branch).
LABEL B Read_More_Records
CLOSE (INPUT)
...
INPUT DCB ..., EODAD=EODADRTN
EODADRTN MVI LABEL+1,0 <- NOP the read loop's branch
...
Well, it IS the LAST record read ;-)
--
Dan
| |
| glen herrmannsfeldt 2004-03-19, 8:28 pm |
| RFCOMMSYS wrote:
> Sven Pran said ---
[color=darkred]
> Ah, how indeed ...
There is a question in another newsgroup about how to find the value of
the fifth from the last element of a linked list with one pass through
the list.
-- glen
| |
| Binyamin Dissen 2004-03-19, 8:28 pm |
| On Tue, 25 Nov 2003 05:41:12 GMT glen herrmannsfeldt <gah@ugcs.caltech.edu>
wrote:
:>RFCOMMSYS wrote:
:>> Sven Pran said ---
:>>>Just how do you know that it is the last time?
:>> Ah, how indeed ...
:>There is a question in another newsgroup about how to find the value of
:>the fifth from the last element of a linked list with one pass through
:>the list.
Well.......
You can save the last five values.
Obviously there are more constraints.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
| |
|
| It's a standard M$ interview question. It simply means managing two pointers
that represent a specified span of elements in the linked-list. Just walk the
first pointer for 5 elements, then continue walking both elements. When the
first pointer gets to the end of the list, the other pointer is 5 elements from
the end.
A variation of this technique is used for walking damaged linked-lists to find
the broken element (the one that points incorrectly back into the previous
elements somewhere).
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:YXBwb.221104$mZ5.1690987@attbi_s54...
> RFCOMMSYS wrote:
>
>
>
>
> There is a question in another newsgroup about how to find the value of
> the fifth from the last element of a linked list with one pass through
> the list.
>
> -- glen
>
| |
| Tim Coffey 2004-03-19, 8:28 pm |
| rfcommsys@aol.com (RFCOMMSYS) wrote
> I want to see someone design a LAST TIME NOP (or branch). The rules are that
> you can't "cheat" by testing any condition or storage external to the actual
> code itself, nor can the code be modified by anything outside of itself. It
> should be useable in any application (again, forget RENT stuff). The action
> (NOP or BRANCH) can only be taken the LAST TIME the code is executed.
If this were possible, what path would the following code take:
TOP_LOOP
....
.... some looping process code
....
*
* Use of the grand-spankin new macro - LASTTIME_BRANCH_TO label
*
LAST_TIME_CHECK DS 0H
LASTTIME_BRANCH_TO PARADOX_CODE
B TOP_LOOP
*
PARADOX_CODE DS 0H
B LAST_TIME_CHECK
So, does the macro LASTTIME_BRANCH_TO ever branch? Is the label PARADOX_CODE
ever reached? Is this an infinite loop?
Tim
| |
| Hank Murphy 2004-03-19, 8:28 pm |
| RFCOMMSYS wrote in message <20031123135033.02030.00000736@mb-m16.aol.com>...
<snip>
>I want to see someone design a LAST TIME NOP (or branch).
Well disregarding the effect on the space-time continuum or something of
knowing when the last time is really the last time, your answer is...
BCT
>The rules are that
>you can't "cheat" by testing any condition or storage external to the
actual
>code itself,
Check. I suppose one could split hairs about a register being storage...
>nor can the code be modified by anything outside of itself.
Check.
>It should be useable in any application (again, forget RENT stuff).
Check.
>The action (NOP or BRANCH) can only be taken the LAST TIME the code is
executed.
It becomes a NOP (No branch, actually) the last time.
But wait, you say! No fair! This means that you have to know how many
times the loop will execute!
Precisely.
For the pedants, BXH, BXLE, and BCTR will perform the same among the classic
S/360 instructions.
Next?
Hank Murphy
speaking only for myself
| |
| Charles A. Crayne 2004-03-19, 8:28 pm |
| On Sat, 29 Nov 2003 04:45:04 GMT
"Hank Murphy" <hmurphy@earthlink.newt> wrote:
:Next?
:
:Hank Murphy
:speaking only for myself
Clearly an opportunity for research.
-- Chuck
| |
| Sanghabum 2004-03-19, 8:28 pm |
| Sven Pran:
>Just how do you know that it is the last time?
That would have to be context sensitive.
There is certainly a case for a last-time test in any decent high-level
language.
Consider a common thing to do: formating a list of items. This code is no
particular language pseudocode:
item-list = {"gene" "jan" "jean" "jane" "gene"}
text = ""
foreach item item-list
text = text + item + ", "
endfor
result -- not what we want -- that last time was one comma too many:
"gene, jan, jean, jane, gene, "
But with a HLL last-time test:
foreach item item-list
text = text + item
if not last-time
text = text + ", "
endif
endfor
result -- perfect!
"gene, jan, jean, jane, gene"
Of course, humans have been solving this coding problem in other ways for
generations, but there is always room for improvement in any thing.
Col.
| |
| glen herrmannsfeldt 2004-03-19, 8:28 pm |
| Sanghabum wrote:
> Sven Pran:
>
[color=darkred]
> That would have to be context sensitive.
> There is certainly a case for a last-time test in any decent high-level
> language.
> Consider a common thing to do: formating a list of items. This code is no
> particular language pseudocode:
> item-list = {"gene" "jan" "jean" "jane" "gene"}
> text = ""
> foreach item item-list
> text = text + item + ", "
> endfor
>
> result -- not what we want -- that last time was one comma too many:
> "gene, jan, jean, jane, gene, "
Both C and Java allow an extra comma in initializer lists, probably for
this reason. Well, for C it is nice both because you may have lists
generated by loops in other languages, but also from conditional
compilation (#ifdef) where it would be difficult to remove the extra
comma.
Still, it could be an interesting addition to a language.
-- glen
| |
|
| "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:TVbyb.253406$mZ5.1881171@attbi_s54...
> Sanghabum wrote:
>
>
>
>
>
>
>
> Both C and Java allow an extra comma in initializer lists, probably for
> this reason. Well, for C it is nice both because you may have lists
> generated by loops in other languages, but also from conditional
> compilation (#ifdef) where it would be difficult to remove the extra
> comma.
>
> Still, it could be an interesting addition to a language.
In Java:
{
String[] items = new String[] {"gene", "jan", "jean", "jane"};
String comma = "";
String result = "";
int jj;
int kk;
jj = 0;
kk = items.length;
while(jj < kk)
{
result += comma + items[jj++];
comma = ", ";
}
}
The variable [result] yields: "gene, jan, jean, jane"
--
----------------------------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
303-774-9381
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
|
|
|
|
|