Post Reply 
What's wrong with your HEAD?
10-19-2018, 01:52 AM (This post was last modified: 10-20-2018 06:06 PM by DavidM.)
Post: #20
RE: What's wrong with your HEAD?
(10-10-2018 05:41 PM)3298 Wrote:  A library could win against TAIL if you copy the TAIL code and store the library in port 0, because that port gets favorable treatment.
...

All of this discussion about HEAD and TAIL prompted me to try something I've wanted to do for a while now. Note: this isn't a realistic approach to a TAIL replacement, but was done more out of satisfying a curiosity than anything else. I could perhaps see doing something like this in a very specific application, but not for general use (reasons will be shown below):

Code:
!NO CODE
!RPL
::
   CK1NOLASTWD
   CK&DISPATCH1
   list ::
      ROMPTR2 ~INTEMPOB? ITE
      ( list is in TEMPOB )
      CODE
         % save RPL registers
         SAVE
         
         % D0 -> first list element OR SEMI if empty list
         A=DAT1 A
         R1=A A      % R1.A -> SL1 object (initially the source list)
         AD0EX
         D0+5
         
         % exit with no change if list is empty
         A=DAT0 A
         LC(5)SEMI
         ?A=C A ->{ LOADRPL }
         
         % C.A = size of first list element
         GOSBVL =SKIPOB
         CD0EX
         A=R1 A
         A+5 A
         C-A A
         
         % move first element back 5 nibbles
         D0=A
         A-5 A
         D1=A           
         GOSBVL =MOVEDOWN
         
         % write the new list header
         LC(5)DOLIST
         DAT1=C A
         
         % R2.A -> TAIL list
         AD1EX
         R2=A A
         
         % load original RPL registers
         LOAD
         
         % update SL1 pointer to point to new list header
         A=R2 A
         DAT1=A A
         
         % return to RPL
         RPL
         
      ENDCODE
      ::
         ( list is NOT in TEMPOB - use standard method )
         DUPNULLCOMP? ?SEMI
         CDRCOMP
      ;
   ;
;
@

The above code can be summarized as follows:

Code:
If list argument is in TEMPOB:
   If list is empty:
      exit with no changes
   else (list has at least one element):
      swap the first element and the original list prologue
      update the SL1 pointer to reference the new location of the list prologue
else (list is NOT in TEMPOB):
   perform normal SysRPL TAIL function

This only provides a benefit if the list argument is in TEMPOB, otherwise it simply does something similar to the regular TAIL command. Objects reside in TEMPOB when they have been created/edited solely as stack entities and haven't been saved into a global variable yet. Further, this doesn't provide any benefit vs. TAIL unless the element count in the source list is big enough -- I don't have a real 50g to test this on at present so I'm not sure where the breakeven point is. An emulated 50g on my laptop shows that it reaches parity with TAIL when the element count reaches about 10 elements, but I would think the count is actually lower than that on real hardware. The execution time is more dependent on the size of the first list element than on the actual count of list elements, which is where its true advantage comes into play. TAIL slows down as the list element count increases, but the above program should execute at near constant speed regardless of the list size.

So why is this not practical? Because it commits a cardinal sin: it alters the list object in place. This is a big no-no for general RPL commands, and breaks some expected functionality such as LASTARG/UNDO, saved stacks, and error recovery constructs. Perhaps one of the most likely problems that could result from this type of operation is that any other references to the original list (usually in the form of stack duplicates) will now simply have the value of the first element instead of the original list. This is clearly not what most would expect to happen, and as such I wouldn't recommend trying something like this except in a very controlled situation.

This was an interesting exercise, though. Unfortunately the TEMPOB check is another ROMPTR, so that negates some of the potential benefit that the program would have otherwise.

Edit:
I tried replacing the ROMPTR ~INTEMPOB? with another embedded code segment, and found that the above program with that change was indeed faster than TAIL for all tests (at least on the emulator -- still don't have access to my 50g).

Also, the SysRPL handler for non-TEMPOB lists doesn't need the null comp test, since CDRCOMP gives that result anyway. So the "DUPNULLCOMP? ?SEMI" line can be removed entirely, which in turn negates the need to encapsulate CDRCOMP in a secondary. Double the savings! Smile
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
What's wrong with your HEAD? - John Keith - 10-07-2018, 02:47 PM
RE: What's wrong with your HEAD? - 3298 - 10-07-2018, 08:55 PM
RE: What's wrong with your HEAD? - pier4r - 10-07-2018, 09:19 PM
RE: What's wrong with your HEAD? - DavidM - 10-08-2018, 03:54 AM
RE: What's wrong with your HEAD? - 3298 - 10-08-2018, 10:06 AM
RE: What's wrong with your HEAD? - DavidM - 10-08-2018, 03:36 PM
RE: What's wrong with your HEAD? - pier4r - 10-08-2018, 05:24 PM
RE: What's wrong with your HEAD? - DavidM - 10-08-2018, 04:12 PM
RE: What's wrong with your HEAD? - pier4r - 10-08-2018, 09:55 AM
RE: What's wrong with your HEAD? - Werner - 10-08-2018, 11:03 AM
RE: What's wrong with your HEAD? - pier4r - 10-08-2018, 02:08 PM
RE: What's wrong with your HEAD? - 3298 - 10-08-2018, 05:55 PM
RE: What's wrong with your HEAD? - DavidM - 10-08-2018, 07:47 PM
RE: What's wrong with your HEAD? - pier4r - 10-10-2018, 11:07 AM
RE: What's wrong with your HEAD? - DavidM - 10-10-2018, 02:56 PM
RE: What's wrong with your HEAD? - 3298 - 10-10-2018, 05:41 PM
RE: What's wrong with your HEAD? - DavidM - 10-19-2018 01:52 AM
RE: What's wrong with your HEAD? - pier4r - 10-20-2018, 05:37 PM



User(s) browsing this thread: 1 Guest(s)