Re: How did BASIC-XL's FAST work?
- From: "Will Hartung" <redrocks@xxxxxxxxxxxxx>
- Date: Sat, 13 May 2006 01:19:59 GMT
"Anders Skelander" <ansk@xxxxxxxxxxx> wrote in message
news:e41dh1$tgo$1@xxxxxxxxxxxxxxxxxxxxxxxxx
Maybe I am ignoring some fact that has already been presented
somewhere in the thread, but don't you think that break and edit
simply invalidates the state, so the program is no longer
considered precompiled and "fast" by the run-time environment?
That's all well and good, but the question is basically where did they store
that information. It's easy to reset the "run FAST" bit in the interpreter
after every code change. Then you would mark the FAST buffer as "dirty" so
it could be overwritten.
The problem is that this information cost (minimally) 2 bytes for the actual
pre-computed address.
If you store the information in a seperate area of RAM, then you need at
least 4 bytes (2 bytes for the line number, 2 bytes for the address).
So, if I have a 500 line BASIC program, that information is 2K of data. We
may laugh at 2K of data today, but that's over 4% of the RAM available on a
48K machine.
It doesn't seem space efficient for the speedup. However, by leveraging the
6 bytes that normally consume a line number, that's the perfect place to put
the precomputed information.
Actually, now that I think about it, I think this would be the way to do it.
You store a "FAST" bit someplace in RAM. After the FAST command is done
pre-compiling, you set this bit to 1. Whenever a change is made to the
program, that bit is reset to 0.
In the GOTO statement, for example, you look at the 6 bytes that contain the
line number ala classis Atari Basic. When FAST is run, it converts those 6
byte into a flag byte (telling us that it's in the new FAST format), 2 bytes
for the original destination line number, and 2 bytes for the calculated
address.
When the GOTO statement executes, it checks the line number. If the flag
byte is there, that means that it was pre-compiled (at some point) by FAST.
It then checks the FAST bit. If that bit is 1, is assumes that the address
there is valid, and then jumps to the address. If the bit is 0, that means
that FAST was run at some time here, but the address is no longer accurate,
so it just grabs the line number from the 2 bytes, and runs the old
behavior.
When a new line is entered, it uses the original Atari format. When a
program is saved, it converts back any FAST compiled lines to the original
format.
That seems like a clever way to handle this. It even handles programs that
run FAST, but then create new code on the fly, since the code change will
reset the FAST bit.
Now, I don't know if this is how it works, but it sounds pretty good.
Regards,
Will Hartung
.
- Follow-Ups:
- Re: How did BASIC-XL's FAST work?
- From: stephensheppard
- Re: How did BASIC-XL's FAST work?
- References:
- How did BASIC-XL's FAST work?
- From: Will Hartung
- Re: How did BASIC-XL's FAST work?
- From: Larry
- Re: How did BASIC-XL's FAST work?
- From: Will Hartung
- Re: How did BASIC-XL's FAST work?
- From: Anders Skelander
- How did BASIC-XL's FAST work?
- Prev by Date: Re: Atari 5200 & 400
- Next by Date: Re: How did BASIC-XL's FAST work?
- Previous by thread: Re: How did BASIC-XL's FAST work?
- Next by thread: Re: How did BASIC-XL's FAST work?
- Index(es):
Relevant Pages
|
