To Split or not to split...?

[1333david]

Hi, When I write a program on the Psion and it gets long and unwieldy to edit I consider whether I should split the program into separate procedures. For example a main program which calls a setup proc and a gameover proc. However, I’m not sure of all advantages and disadvantages of this approach on the Psion. Is it more efficient to have the whole program in memory? Sometimes I split the program during editing and put it back to one procedure. I was wondering if there is a best approach. It’s certainly nicer to have one file on the pack rather than lots of files and I’ve noticed calling a proc located at the end of a large datapack can slow down the program considerably. Any advice from more experienced programmers than me would be welcome, thank you.

[Martin]

Hi Dave

You are right that there is a 'locating' time issue on the large capacity packs that are now available... BUT mainly it is a memory issue if you have a program divided up into small routines then as one of these small routine is finished the memory is freed up for the next one. Whereas a large program is loaded into the 'working space RAM' and has to stay there until it is finished. Also as you start to develop 'additional' programs you will find that you can write a routine once and call it from different 'programs'. Classically this would include the file opening and closing routine, maybe the comms routine... If you find yourself repeating code in different parts of your program then this is a candidate for creating a (sub) routine or a user defined function. If you use use the MENU command then each item on the menu is a candidate for a routine.

The memory issue is highlighted in the 'Using Large Capacity Packs' paper (here). Generally if you have an XP (16K) or an LA (32K) or LZ (32K) and you use a Flash pack, Spread sheet and Comm Link then half of your memory is used up supporting these 'devices'.
.

MemoryUsedImage.png

Sincerely Martin

PS how much memory is 'free'

Code: Select all

RAM:
Local D%,D$(6)
REM LZ routine
UDG 1,16,18,20,24,20,18,0,31
UDG 2,0,0,0,0,0,0,0,31
CLS
DO
 AT 1,1
 PRINT CHR$(0);REPT$(CHR$(2),14)
 CLOCK(1)
 AT 1,2 : PRINT "Free Memory in?"
 AT 1,3 : D%=MENUN(1,"A:,B:,C:,Quit")
  IF D%=0 or D%=4 : RETURN :ENDIF
  AT 1,4
  D$=CHR$(64+D%)+":MAIN"
  IF EXIST(D$)
   OPEN D$,A,A$
   PRINT LEFT$(D$,2);" Free ";space;" K"
   CLOSE
  ELSE
   PRINT "No memory on ";LEFT$(D$,2)
  ENDIF
UNTIL D%=0
GET
RETURN

[Daren]

Very useful info in there Martin, I never considered that a larger program would tie up ram more than one broken into separate procedures, but now that you mention it, it makes perfect sense.

I guess the balance is choosing between bigger file size and convenience, or performance and a bit of clutter with multiple procedures. I think that a notepad index of what OPL programs and procedures go together is a good idea, especially when using datapaks, index on the pak with the contents and details.

Sorry to derail the topic slightly but I got a menu working very nicely, not a proper thing yet, just a proof of concept, and been having some fun doing a bit more programming, sometimes just trying things out like testing how random RND is, and experimenting with the OFF command (hint: good for timers!) great fun

[amenjet]

The details about OPL overlaying is in the technical manuals. Martin is correct, OPL procedures are loaded as a unit, executed, and then dicarded. The OPL is loaded as compiled QCodes onto the execution stack, it is then linked in to the global and external variables that have been loaded by other procedures. There's no way (in standard OPL execution) to hold a procedure in memory other than it being a 'top level' procedure that then calls other procedures and then exits itself. Every time a procedure is loaded there will be a delay as the QCodes are read from somewhere,this can only really be circumvented by having a big procedure with everything in it and not loading sub procedures.
It's a flexible system and allows programs larger than the available RAM to be run by loading parts of it as procedures. Or, if the programmers wants to they can load the whole program in one lump.

[1333david]

This is really interesting information. Thank you for your replies. I have one 256k flashpack with programs stored in the order as follows :
Prog1.ob3
Prog2.ob3
Database.odb (100k+)
Prog3.ob3
Prog4.ob3
Prog5.ob3

Prog1 and prog2 use the database file.
When I use prog3/4/5 they are really slow to load. I assume it's because of the large database file located on the pack before them. I was planning to re-arrange the pack (using Jaap's OPK Editor) to put the database file at the end. I assume prog3/4/5 will be faster to access but I guess prog1/2 which use the database file will then slow down slightly. Would a large ram pack speed up the access times too?

[Martin]

Hi David

You are right it is a compromise.. Speed vs Capacity... I bet the lads in the 1990's would have loved to have an inexpensive large capacity Flash or Ram pack..

Some thoughts

- If to are constantly accessing the database then putting it first speeds up the searches at the expense of 'slower' OPL (OB3) loads.
- If really want the program to 'skip' along then those routines should be first with the database at the end..

Remember also that the Organiser searches (all of)
A: then B: before looking on C: So if you have something in B: that is seldom used swap it into C:
.

FL01.jpg

'
Example - For example in HamLog I've created a function [FromLst$:(FName$,Cat$,Df$)] that presents the user with a list of data that they can select from for that particular data entry (why see below). For this to be 'slick' the data list which in an ODB needs to be on the screen immediately. Not the slight pause you were mentioning above. So when MAKEing the Pack the 'list' database files are at the top or the pack followed immediately with the FromLst$.OB3 then the remaining OB3's followed by the not used so often Morse Code Database and ITU Call Sign Database and bringing up the rear the NotePad (OB7) help files. There is an example (HamLogJP) that works in Jape (here) if you want to have a look.

Finally as you have a Flashpack and access to Jaap's OPK Editor you can try all different combinations until you find what suits you best. This was a long winded process in the past when we had to UV format 128K datapaks.

And finally finally... If you want to 'show it off' I'd be interested in having a look at the utility you are developing..

Sincerely and in good faith
Martin

----------------------------

Why bother presenting a 'list of options' to a user. Firsly it looks 'slick'. But mainly to ensure that the data entry into a database file is consistent which is then easier to search for and make lists from... This helps to prevent - in the example above 135kHz LF - 1350HzLF - 135 etc.

Why not 'hard code' the option iist into the program? - Then it is difficult to 'update' the options in the list
.