#ABasiC program size
12 messages in this thread
I've come to the startling conclusion that my C64 is bigger than my Amiga. A
few little test programs consisting of a variety of assignment statements,
gOSUBS, simple functions, etc. were written for the 64 and also entered into
the Amiga. The value of FRE(0)noprogram-FRE(0)program was compared for the
two machines. (a) there is an apparent overhead of about 1300 bytes in the
Amiga as soon as a single line is entered. (b)ignoring that hit, a typical
ratio of Amiga program length to C64 program length TO DO THE EXACT SAME
THING is two-to-one. (c)since I've also encountered "Program too long" on the
Amiga at a length of about 60k, I conclude that A PROGRAM LONGER THAN ABOUT
30k ON THE C64 IS TOO BIG FOR ABASIC on the Amiga. (d)a couple of horrendous
examples: clear the screen C64-9 bytes Amiga – 24 bytes (for the single word
"SCNCLR"). print "I'm ok" C64 -15 bytes Amiga – 40 bytes.
This seems typical of the current tendency to burnup memory as long as it's
there. They better get this fixed or I'm going to start doubting the wisdom
of my purchase. Dick Darling
Dick, don't regret your decision if ABasiC is all that's bothering you. I'm
taking a 'wait and see' attitude until I get my hands on Microsoft's BASIC. I
hear it's a marvel.
Regards, Larry.
I have heard rumors of a 64k workspace with the array and variable storage
outside the 64k. That may be fine for the 256k machine, but 512k is wasted! I
just hope my info is wrong.
That's kind of consistent with my exper- ience, although I actually am using
as much as 120k of array at times (3 screen buffers at about 44k each). What
gripes me is that this fundamental information isn't available in the docs.
That plus the inefficiency of the language.
Hopefully MSBASIC will be here soon.
Hi Dick,
I was talking to someone from Commodore the other day, and I beleive that he
mentioned that ABasic does not tokenize. This would be a very good explanation
of why an ABasic file is so large compared to a 64's.
Of course, the benefit of an untokenized BASIC, is the ability to run straight
text files.
Running straight text files is only an advantage if they're of usable size.
Why can't ABasiC tokenize internally while still preserving the ability to
read straight text files? Heaven knows there's a batch of fairly small
utilities that give the 64 this ability. I'd trade a usable program size for
a little inconvenience in editing/saving on disk any day.
Hi Dick,
I agree completely, not tokenizing a program makes very little sense. Tokens
allow program execution to be faster, while having smaller program size.
I can't undestand why anyone would write an interpreter that has to parse
through a long, full length list of commands. Even a 2 byte token system
(which I assume would be needed), would increase efficiency grreatly.
MicroSoft Basic???? Anyone know whether it tokenizes?
Gary:
Yes, MS tokenizes — Microsoft wrote the BASICs in most every micro around
(Apple, IBM, C-64, TI…) and they all tokenize (which is why, say, MS-BASIC
files have to be explicitly saved with an ASCII option to be edited externally
from BASIC). I still think that ABasiC tokenizes, it just saves the tokens in
parallel with the ASCII source. This has its advantages. Personally, I've found
ABasiC (on some math) to run very favorably against the tokenized PC-BASIC….
^Kx
Kevin- Speed-wise it seems fine. And never having written a program that hit
the limit size-wise on our PC-AT I can't comment on the comparable size
limits. All I say is it's ridiculously small for a 512k machine costing $2k,
as compared to 64k and 128k machines costing 1/10 as much. Dick Darling
Dick: I agree, and wasn't trying to defend MetaComCo, just try to figure out
what the heck is going on inside this box. I work at a company where we have a
very large computing facility dedicated to just a small number of people, and
we often tend to do things "sloppily" — small efficiency issues often tend to
be ignored when you have a lot of memory and higher processor rates. Or as one
of our Research guys says whenever we find some particularly inefficient code:
"So what, we have a Cray." I suspect that the foolks at MetaComCo had a certain
degree of the same attitude. Sure, ABasiC isn't as efficient as MBASIC — who
cares, we have 512k and a virtually full-speed 68000. This attitude can let you
get things out quickly, but I can't say I approve of it past that. A major part
of our work software effort over recent months has involved going back over
software that was being supported by hardware efficiencies and fixing it — and
finally starting to really see what our machines can DO. ^Kx
Kevin, Microsoft did WRITE basics in most every micro around…. They
modified the first one they originally wrote…Thus MOST of the the
msbasics around all have the 64k limit (ie the pc with 640k mem) and
terrible string-garbage collection- problems…
SSG