jshaver@APG-5.ARPA.UUCP (05/11/87)
I belive that FRE(0) will force garbage collection on both DOS 3 and PRODOS. I say that because it takes so long to get back from the function call and return to processing.
ahby@meccts.MECC.MN.ORG (Shane P. McCarron) (05/13/87)
In article <153@genat.UUCP>: >FRE(0) will give free space >FRE(" ") will force garbage collection and then give free space > >There is a difference! I am looking at the FRE code, and it reads: fre lda valtyp beq fre1 ; if not a string jsr frestrE ; frestrE frees up tmp fre1 jsr garbag sec lda fretop ; figure out free space sbc strend tay lda fretop+1 sbc strend+1 ; and fall into givayf Valtyp is 0 if a numeric, 0xff if a string. FrestrE is a secondary entry point in frestr that assumes there is a string. Frestr falls into fretmp, which will adjust fretop if the temporary string (" " in this case) is the last string in memory. Since it is most assuredly the last string in memory, fretop will be adjusted. However, it would never have been moved down if a string hadn't been used in the fre() call, so that may not be a great adantage. Regardless of what the argument is, fre executes garbag, which forces a garbage collect. -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby@MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 (C) Copyright 1987 Shane P. McCarron Redistribution allowed only if your recipients can redistribute
dalea@fai.UUCP (05/14/87)
In article <8705111018.aa01214@SPARK.BRL.ARPA> jshaver@APG-5.ARPA (John Science Fiction & Resume Service Shaver) writes: >I belive that FRE(0) will force garbage collection on both DOS 3 and >PRODOS. I say that because it takes so long to get back from the function >call and return to processing. Unless it was changed by Apple, the BASIC.SYSTEM interpreter has it's own version of FRE that is extremely fast. To call it, instead of FRE(0) issue the following ProDOS call: xx PRINT D$;"FRE" : REM Where xx is the line # and D$ is a CONTROL-D This can be called as often as desired but should be often enough that the Applesoft FRE(0) routine be avoided. -- -- Dale M. Arends (Fujitsu America Inc., San Jose, Calif.) seismo!amdahl!fai!dalea The opinions expressed herein do not necessarily reflect those of my employer. They are entirely my own if they make sense and I disavow them if they don't.
ahby@meccts.UUCP (05/16/87)
In article <610@fai.UUCP> dalea@fai.UUCP (Dale M. Arends) writes: >Unless it was changed by Apple, the BASIC.SYSTEM interpreter has it's own >version of FRE that is extremely fast. To call it, instead of FRE(0) issue >the following ProDOS call: > >xx PRINT D$;"FRE" : REM Where xx is the line # and D$ is a CONTROL-D > >This can be called as often as desired but should be often enough that the >Applesoft FRE(0) routine be avoided. Actually, I'm pretty sure that BASIC.SYSTEM is constantly monitoring the bottom of strings/top of arrays area. If it notices them getting too close together, it automatically calls its internal fre() handler. It will also automatically do a fre whenever you open a file, it has to allocate a file buffer. It frees memory by moving the strings down by 1k or so. Also, I was pretty sure that ProDOS would spot a call to fre() and use its internal routine instead of handing it over to Applesoft. However, I haven't taken a close look at that part of BASIC.SYSTEM since its initial beta release in 82(?), so I could be wrong about this. It is interesting to note that BASIC.SYSTEM is really over-zealous in the way it hooks into basic. The link into chrget (I think its chrget) causes a performance loss of something like 4% off of the already slow Applesoft! Also, it has its own internal version of the BASIC token table, so there is no way to supply additional or changed tokens to applesoft. We discovered this when trying to port our version of extended Applesoft (EBASIC) into the ProDOS world. We had defined additional tokens for things like WHILE, CASE, WHEN, ELSE, SELECT, etc - and there was no way to do this under BASIC.SYSTEM. Thanks for another piece of software engineering genius, Apple! If you want a real laugh, take a look at the code inside BASIC.SYSTEM. Or better yet, look at the color screen dump driver that is supplied with the Imagewriter II. Hah! What a mess! (giggle, giggle) -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby@MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 (C) Copyright 1987 Shane P. McCarron Redistribution allowed only if your recipients can redistribute