Bones-69 Posted August 12, 2010 Share Posted August 12, 2010 Research and back-ground work continues on my LGB project (which BTW is quickly growing out of hand!). Right now I am working on some of the repetitive subroutines that will be used during the game. One routine in particular is required many times during the game and will be called from a lot of different program line numbers, in fact - it is used everytime a line of text is displayed. This particular subroutine is responsible for reading a text string from DSK1, deciding where to display it, actually displaying the string on the screen (using the CALL HPUT command from RXB), beeping, honking, plus a few other cool functions which also include importing basic graphics to the displayed line when required. Everything is controlled by a single 10 digit variable. A typical example of a variable used would be: S(100)=-1010071012 The logical choice was to use a custom SUB routine which I had defined as "CALL T" and used a single parameter list. An example of this would be; CALL T(S(100)) After fooling around with this idea and improving the routine a few times, it became desirable for my SUB routine to also be able to access existing string variables which were used outside of the SUBroutine in the main program (which is not possible without complicating the subroutine with additional parameters and having to specify each everytime CALL T was used OR I found myself in a situation where I was "double handling" information to get around the problem which just slows things down too much). For this reason I have no real choice but to flick my subroutine and call the entire routine using a GOSUB command - which is more freindly when wanting to use variables specified elsewhere in the main program. My main concern with using a GOSUB command in leu of a SUB routine was the additional program space this would incur - especially when it is being repeated many many times during the program. So to get a feel of how much program space I would loose/waste using this method I did the following basic test; 100 CALL T(S(100)) Using a SIZE command advised this program line used a total of 21 bytes of program space The alternative GOSUB command would need to be specified as follows; 100 A=S(100) : : GOSUB 1000 When listing and compared on screen, the program line with the GOSUB command seems to occupy an 8 additional spaces over the SUBroutine (by spaces I actually mean 8 additional characters). However, when checking this expectation using the CALL SIZE command I was pleasantly surprised to discover that the GOSUB line actually only occupied 1 additional byte of program space. This is really good news for what I need the GOSUB command to do as I am struggling to save every single byte, but it begs the question of what is going on? Why only 1 byte difference between the two lines of code? Obviously my very basic understanding of how the TI stores program data is flawed but I just can't make sense of how two vastly different length lines of program data occupy roughly the same program space. 100 A=S(100) :: GOSUB 1000 100 CALL T(S(100))12345678 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.