Self modifying code, lambda calculus - Re: ENIAC programming
Rod Smallwood
rodsmallwood52 at btinternet.com
Sun Sep 20 07:21:13 CDT 2015
On 20/09/2015 11:52, Liam Proven wrote:
> On 19 September 2015 at 19:53, tony duell <ard at p850ug1.demon.co.uk> wrote:
>> A lot of disk-based BASICs had a statement that would merge a program from
>> disk in this way. Sometimes the program had to be saved in ASCII, not tokenised,
>> the BASIC interpretter then essentially read the file as if you were typing it on the
>> keyboard. So program lines would indeed replace those with the same line number.
> OK, that I've seen, yes. Even, very carefully, used it.
>
> But the examples I've seen do not behave as you describe. Note, I am
> not saying it's impossible or never happens, merely that it does not
> match the behaviour I've seen.
>
> In ever BASIC interpreter I've ever used, the LOAD command loads a new
> program in from $MEDIUM. This implicitly gets rid of the program
> previously in memory. It is not the same as a NEW command, which
> usually also resets all variables etc.
>
> If you want to keep the existing program in memory *and* load
> additional lines from storage, there was a different command: MERGE.
>
> But in everything from ZX BASIC to BBC BASIC to GWBASIC, loading a
> program erases all lines of code in interpreter RAM and replaces the
> whole program with the one loaded from disk, but leaves variables etc.
> intact.
>
> This means that, in effect, the program modules being loaded are
> overlays: you can pass state (a whole set of initialised variables and
> their values) from one module of code to another. I maintained a large
> MS-DOS payroll program written this way: it consisted of 18-30+
> sub-64kB modules of code. (How many depended on the client's
> requirements.) The first module initialised all the variables in
> memory and drew a menu. The menu LOADed the other modules, many of
> which LOADed each other to handle the task. All the variables
> remaining in place in RAM, all effectively globals, as GW-BASIC didn't
> offer local variables, named procedures etc.
>
> The reason was that you couldn't have a program of >64kB on GW-BASIC.
> The original developer taught me to think of each chunk as a
> procedure, and all the variables as globals. The code was extensively
> commented to explain what variables it expected to find in place, what
> they held, which ones it would modify etc.
>
> Once I understood it, I found it really elegant.
>
> I don't think I've *ever* seen a program that MERGEd in code during
> execution, though. That sounds terrifying!
>
>
>> One of the extension ROMs for HPL on the HP9825 (a BASIC-like language) had
>> a command to store a string as a program line. It could be used within a program,
>> thus leading to an official way to have self-modifying code.
> Nifty!
>
>
I'm trying to remember (O Nemisis thy name is Altzhimer) where I used it.
It may have been a project done on a Northstar Horizon running C/PM and
CBASIC
I used Wordstar as a programmers editor.
I'd love a Northstar for old times sake but they are too heavy to ship
from the US and you just do not see them in the UK.
Rod
--
Wanted : KDJ11-E
M8981 KK8-E
M8300 KK8-E
M8310 KK8-E
M8320 KK8-E
M8330
More information about the cctech
mailing list