Commodore Free #82 PRIMM

User avatar
Posts: 25
Joined: Fri Aug 22, 2014 3:52 pm
Location: Minnesota

Commodore Free #82 PRIMM

Post by Heart »

Last edited by Heart on Thu Oct 23, 2014 8:52 am, edited 1 time in total.


Re: Commodore Free #82 PRIMM

Post by satpro »

Hi Heart,

Thanks for reading the article and for showing interest enough to start this conversation. PRIMM is one of those routines that can be written in many different ways to solve any number of string-related programming tasks. I have seen it used in some very clever ways; it really is sort of a "Swiss Army knife" type of function . In this article we looked at the basics, leaving the reader with a foundation with which to build upon and experiment with.

As to the question of whether saving registers is necessary or not, one of the programming rules I live by is sort of an offshoot of the old "You break it, you buy it" line, and it goes like this: "A procedure shall return all registers, the stack, and the status register to the state it encountered them, unless specifically designed not to do so." This rule is very practical, flexible in that it gives the programmer exceptional leeway, and is guaranteed to keep one out of "hidden-bug" trouble. Nowhere does it imply "save all registers" but instead advises to leave them the way you found them. It's an easy-enough habit to pick up, and it shows people you know what you're doing.

Some guy (maybe YOU) is using your procedure (sub-routine) in a loop, and his counter is the .X Register. Now, because your procedure fails to save a register it modifies (.X), this poor guy (again, maybe YOU) is sitting there wondering where the bug is in his program -- and it isn't exactly staring him in the face. Eventually he (again? --> maybe YOU!) is going to realize that the .X Register is coming back altered by your routine. He is then going to call (maybe YOU) an "MFer" and is going to re-write his loop so that it saves the counter (which was in a register for speed) before calling your routine. Now his loop is slower, larger, and more complicated, and all of it could have been avoided by simply spending a few cycles to save a register YOUR procedure modified.

As you get into more complicated scenarios this rule becomes more and more necessary. Short and simple: fix what you break.

Self-modifying code is always a lightning rod. I guess it's one of those "personal choice" items. Some guys use the heck out of it, while others use it only in certain situations; some avoid it completely. I tend to fall into the second category, but relate more to the third category. There are a few distinct scenarios where there is almost no choice but to use SM code. One involves the MVN/MVP instructions, and the other is a calculated-jump table -- a pointer (or table) that is filled as you go. I suppose you could come up with a few more. Advanced programmers generally don't use self-modifying code. It is considered sloppy (and lazy) programming by many, and those who consider it sloppy will argue the old "code goes by code, data goes by data" line. They will also argue the code is non-relocatable, hard to debug, and not scalable. As for lazy, from what I have seen self-modifying code is generally used as a way to avoid using a proper table or pointer and indexing it, and rarely as a tool. Wanna know an instant turn-off? Try reading someone else's self-modifying code.

Just to note: the routine I compared with is from the C-128 ROM and was used to demonstrate a few ideas for the article. Thanks for showing interest.

Post Reply Previous topicNext topic

Who is online

Users browsing this forum: No registered users and 1 guest