Basic compiler

Post by art
Hello all,
I have joined this group in hopes to get back up to speed as I picked
up a couple of apple IIes to use as embedded controllers. Does anyone
know where I can get a copy with manual of a BASIC compiler that will
produce executable code?

found in a recent post:

http://beagle.applearchives.com/

there you'll find the Beagle Compiler with its manual.

Guillaume.

Alex Freed

2006-10-22 21:49:09 UTC

Post by Guillaume Tello
http://beagle.applearchives.com/
there you'll find the Beagle Compiler with its manual.

The problem is that the Beagle Compiler does not generate machine code and
requires the compiler itself to be
resident to run the "compiled" program, according to the manual.

-Alex.

Terry Olsen

2006-10-22 22:30:22 UTC

Wasn't there a program that took a "Labeled" basic language and converted it
to Applesoft? What was the name of that?

Post by Alex Freed

Post by Guillaume Tello
http://beagle.applearchives.com/
there you'll find the Beagle Compiler with its manual.

The problem is that the Beagle Compiler does not generate machine code and
requires the compiler itself to be
resident to run the "compiled" program, according to the manual.
-Alex.

BluPhoenyx

2006-10-23 04:44:35 UTC

Post by Terry Olsen
Wasn't there a program that took a "Labeled" basic language and converted it
to Applesoft? What was the name of that?

MD-Basic but it need a GS. I would recommend ZBasic (it uses labels or
line numbers). The doc's are available as well. AFAIK, the only thing
missing is the DOS 3.3 version.

BTW, there is no link on the software section. Perhaps someone here has
a copy.

Cheers,
Mike T.

finksterj

2006-10-23 04:34:11 UTC

Post by Alex Freed

Post by Guillaume Tello
http://beagle.applearchives.com/
there you'll find the Beagle Compiler with its manual.

The problem is that the Beagle Compiler does not generate machine code and
requires the compiler itself to be
resident to run the "compiled" program, according to the manual.
-Alex.

It's true the Beagle Compiler requires the COMPILER.SYSTEM (or one of
the expanded memory versions) to run your compiled programs-although
the actual COMPILER program is not needed once your programs have been
compiled to disk.

Generally the Beagle Compiler produces code that runs 10X faster than
regular Applesoft and the compiled programs are much smaller than the
original program.

Why is this a problem for you? What is your application?

Michael J. Mahon

2006-10-23 05:03:51 UTC

Post by Alex Freed

Post by Guillaume Tello
http://beagle.applearchives.com/
there you'll find the Beagle Compiler with its manual.

The problem is that the Beagle Compiler does not generate machine code and
requires the compiler itself to be
resident to run the "compiled" program, according to the manual.
-Alex.

It's true the Beagle Compiler requires the COMPILER.SYSTEM (or one of
the expanded memory versions) to run your compiled programs-although
the actual COMPILER program is not needed once your programs have been
compiled to disk.
Generally the Beagle Compiler produces code that runs 10X faster than
regular Applesoft and the compiled programs are much smaller than the
original program.

The actual speedup is highly dependent on the nature of the
code being compiled.

If the code does a lot of floating-point arithmetic, the
speedup is much less (since most of the time is spent in
the floating point routines).

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Michael J. Mahon

2006-10-23 02:26:32 UTC

Just out of curiosity, is your program so big and so slow that
you need to compile it, as opposed to just running it in Applesoft?

If you have a few routines that need machine language speed, they
can be easily crafted in an assembler and called from BASIC.

Unlike most 8-bit microcontrollers today, the 6502 has *very* few
*real* compilers (that compile to machine language).

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Paul Schlyter

2006-10-23 07:43:02 UTC

Just out of curiosity, is your program so big and so slow that
you need to compile it, as opposed to just running it in Applesoft?

....well, if the program is too BIG to run in Applesoft, compiling it will
just make matters worse, since after compilation the program will become
even bigger - at least if you compile it to machine code.

Post by Michael J. Mahon
If you have a few routines that need machine language speed, they
can be easily crafted in an assembler and called from BASIC.
Unlike most 8-bit microcontrollers today, the 6502 has *very* few
*real* compilers (that compile to machine language).

There were some though. Two Applesoft compilers which produced
stand-alone executables in machine code were the "Einstein Compiler"
(aka "Expediter II"), and Microsoft's TASC (The AppleSoft Compiler).

Post by Michael J. Mahon
-michael
NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."

--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/

Michael J. Mahon

2006-10-23 17:52:33 UTC

Just out of curiosity, is your program so big and so slow that
you need to compile it, as opposed to just running it in Applesoft?

.....well, if the program is too BIG to run in Applesoft, compiling it will
just make matters worse, since after compilation the program will become
even bigger - at least if you compile it to machine code.

Right--I should have just said "slow". ;-)

Both of those either loaded or "compiled in" runtimes.
The "machine code" that they produced was mostly calls to
runtime routines.

While this is to be expected as a time-for-space tradeoff for
large programs, it results in code that is much inferior to
the in-line code that most people associate with compilation
to machine language.

In fact, the architecture of the 6502 pretty much dictates this
kind of approach, though it would have been possible to only load
the parts of the runtime that were actually needed instead of the
whole thing, as is usually done.

My point is that there are no BASIC compilers that I know of for
the Apple II that will compile *directly* to *in-line* machine code.

If you really feel you need the "level" of BASIC and the speed of
machine language, then your best approximation will probably be one
of the BASIC-like macro assembler packages. I believe that Nibble
offered such a package (maybe "Macrosoft"?).

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

finksterj

2006-10-23 20:22:32 UTC

Just out of curiosity, is your program so big and so slow that
you need to compile it, as opposed to just running it in Applesoft?

Right--I should have just said "slow". ;-)

Both of those either loaded or "compiled in" runtimes.
The "machine code" that they produced was mostly calls to
runtime routines.
While this is to be expected as a time-for-space tradeoff for
large programs, it results in code that is much inferior to
the in-line code that most people associate with compilation
to machine language.
In fact, the architecture of the 6502 pretty much dictates this
kind of approach, though it would have been possible to only load
the parts of the runtime that were actually needed instead of the
whole thing, as is usually done.
My point is that there are no BASIC compilers that I know of for
the Apple II that will compile *directly* to *in-line* machine code.
If you really feel you need the "level" of BASIC and the speed of
machine language, then your best approximation will probably be one
of the BASIC-like macro assembler packages. I believe that Nibble
offered such a package (maybe "Macrosoft"?).
-michael
NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."

You're right about those older BASIC compilers creating code that was
much larger than the original because of the runtime libraries added.
On the other hand, the Beagle Compiler produces code smaller than the
original, but you need the COMPILER.SYSTEM to run them.

Although Macrosoft doesn't add a runtime library, it still produces
code that is larger than the same Applesoft code-typically 3-5X or
larger. Of course the limitation of Macrosoft is you have to convert
your Applesoft code and use the Mindcraft Assembler, but it produces
standalone code.

As the Beagle COMPILER.SYSTEM is about 6-7K larger than BASIC.SYSTEM,
depending on how many programs you need compiled, I think the Beagle
Compiler is probably more space-efficient than the older compilers that
added a runtime package to each program compiled (which typically was
about 15K).

I know the Beagle Compiler can "chain" multiple programs together, so
the limitation on program size is moot as you can split your code into
smaller segments and chain them using common variables.

Michael J. Mahon

2006-10-24 02:00:49 UTC

Just out of curiosity, is your program so big and so slow that
you need to compile it, as opposed to just running it in Applesoft?

Right--I should have just said "slow". ;-)

Both of those either loaded or "compiled in" runtimes.
The "machine code" that they produced was mostly calls to
runtime routines.
While this is to be expected as a time-for-space tradeoff for
large programs, it results in code that is much inferior to
the in-line code that most people associate with compilation
to machine language.
In fact, the architecture of the 6502 pretty much dictates this
kind of approach, though it would have been possible to only load
the parts of the runtime that were actually needed instead of the
whole thing, as is usually done.
My point is that there are no BASIC compilers that I know of for
the Apple II that will compile *directly* to *in-line* machine code.
If you really feel you need the "level" of BASIC and the speed of
machine language, then your best approximation will probably be one
of the BASIC-like macro assembler packages. I believe that Nibble
offered such a package (maybe "Macrosoft"?).
-michael
NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."

You're right about those older BASIC compilers creating code that was
much larger than the original because of the runtime libraries added.
On the other hand, the Beagle Compiler produces code smaller than the
original, but you need the COMPILER.SYSTEM to run them.
Although Macrosoft doesn't add a runtime library, it still produces
code that is larger than the same Applesoft code-typically 3-5X or
larger. Of course the limitation of Macrosoft is you have to convert
your Applesoft code and use the Mindcraft Assembler, but it produces
standalone code.
As the Beagle COMPILER.SYSTEM is about 6-7K larger than BASIC.SYSTEM,
depending on how many programs you need compiled, I think the Beagle
Compiler is probably more space-efficient than the older compilers that
added a runtime package to each program compiled (which typically was
about 15K).
I know the Beagle Compiler can "chain" multiple programs together, so
the limitation on program size is moot as you can split your code into
smaller segments and chain them using common variables.

It's going to be near impossible to beat the space efficiency of
an interpretive system. Small "code" size was a primary design
objective for microcomputer BASICs.

So, is your problem that the program you want to run is
very large (in which case, as Paul points out, a compiler
is not the answer)? Or very slow?

If it's slow, then it is quite likely that a very little bit
of machine code would do wonders to speed it up.

Applesoft can CHAIN programs quite nicely, too.

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

BluPhoenyx

2006-10-24 20:20:06 UTC

Post by Michael J. Mahon
It's going to be near impossible to beat the space efficiency of
an interpretive system. Small "code" size was a primary design
objective for microcomputer BASICs.
So, is your problem that the program you want to run is
very large (in which case, as Paul points out, a compiler
is not the answer)? Or very slow?
If it's slow, then it is quite likely that a very little bit
of machine code would do wonders to speed it up.
Applesoft can CHAIN programs quite nicely, too.

An interesting alternative for speed and space would be ProBasic from
Beagle Bros. This modular Applesoft is incredibly powerful and versatile
for many programming tasks. One creates modules from either Applesoft or
Machine language and/or incorporate external modules (as available).
Speed is automatically increased by reducing the number of program lines
in each module.

Cheers,
Mike T.

Michael J. Mahon

2006-10-25 01:20:28 UTC

Post by BluPhoenyx

Not sure I know what you mean.

A program must always execute all the statements called for by
the control flow, regardless of modularization.

Changing module size could only *add* to the number of module
crossings required to execute a program, never subtract.

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

BluPhoenyx

2006-10-25 03:43:17 UTC

Post by BluPhoenyx
An interesting alternative for speed and space would be ProBasic from
Beagle Bros. This modular Applesoft is incredibly powerful and
versatile for many programming tasks. One creates modules from either
Applesoft or Machine language and/or incorporate external modules (as
available). Speed is automatically increased by reducing the number of
program lines in each module.

It's an impressive feat of programming. At least to me. Except for the
modularity, Applesoft runs the same. IIRC, variables are available to
all child modules as one would expect. I can't really explain it, you
need to read the doc's. Sadly, I can't locate mine.

Cheers,
Mike T.

Michael J. Mahon

2006-10-25 06:01:48 UTC

Post by BluPhoenyx

I'll look for it.

As John pointed out, there is some savings possible in reducing the
scope of the branch target searches--at the cost of increased time to
branch outside the "module".

In my programs, inner loops are generally very tight (which gains the
benefit of a short forward search if the target statement number's
MSB is the same) or are FOR loops, which avoid searching.

It would be interesting to see what percentage of time is spent
searching for branch targets when a program is run...

Of course, every variable reference searches the variable table, too.

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

John B. Matthews

2006-10-25 04:35:30 UTC

Post by BluPhoenyx

IIRC, when branching forward, Applesoft has to walk the pointers from
one line to the next until the target line is located. I seem to recall
some effort devoted to optimization by moving oft-used routines to the
beginning of the program. Might this effect produce the (presumed)
speedup for small modules?

Still, I have to wonder if the long disk-swap times wouldn't swamp the
effect, at least when running from floppy.

--
John Matthews
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/

BluPhoenyx

2006-10-25 16:57:00 UTC

Post by John B. Matthews
IIRC, when branching forward, Applesoft has to walk the pointers from
one line to the next until the target line is located. I seem to recall
some effort devoted to optimization by moving oft-used routines to the
beginning of the program. Might this effect produce the (presumed)
speedup for small modules?
Still, I have to wonder if the long disk-swap times wouldn't swamp the
effect, at least when running from floppy.

--- From the manual:

ProBASIC enhances the Applesoft BASIC that is built into your Apple II
series computer. It allows you to add new commands and functions called
modules in your programs. This capability is called 'extensibility'
because the language actually grows.

These modules may be written in either BASIC or machine language.
Machine language modules may be written to greatly increase the speed of
your programs. Those programmers not familiar with machine language can
still easily use machine language modules written by others. BASIC
modules add modularity and structure that make it much easier to edit,
debug and maintain your programs. Additionally, the modules may be saved
on disk and easily integrated into other programs.

Proper use of ProBASIC modules will make your programs run faster and
will make them much easier to understand for making changes. Variable
conflicts are also much easier to avoid since each BASIC modules module
has it's own set of variables (local variables). Programs should be
broken down into modules of not more than 30 or 40 lines that can be
easily understood and quickly edited. Each modules can be independently
tested and re-used in other programs.

--- A little further in the manual

A program in ProBASIC consists of the main program and zero or more
modules. The main program itself is a BASIC module called 'MAIN'. When
you run a ProBASIC program, the main program (MAIN) is run. It may then
call other modules.

Once a module has been created or loaded from disk, it is called just
like a standard BASIC statement or function and for all practical
purposes the module has become a part of the BASIC language just as much
as FOR or NEXT or any of the others. All modules are both statements and
functions. They may be executed without returning a value like the
statements HGR or GOTO. Every module may also be called as a function
that returns a value such as SINE or PEEK. Modules may be called from
the main program or from BASIC modules.

Like BASIC commands, a module may require one or more parameters.
Parameters are values that are passed to the statement or module. For
example, the statement POKE 36,20 has 2 parameters: 36 and 20.The first
parameter is an address and the second parameter is the value to poke
into that address.

--- Even further.

The ProBASIC program resides at $0c00 (3072) to $1fff (8191). The area
$0800 to $0bff (2048 to 3071) is free and you may use it for text page 2
or lo-res graphics page 2 or for extra memory for your modules. The
module VIRTUAL uses it for a 1k ProDOS buffer so do not use it if you
are using VIRTUAL. Page 3 ($0300) is not used by ProBASIC. HIMEM has
been lowered to make room for the new commands MODLOAD and MODSAVE.

--- End of manual quotes.

I found my printed copy of the help file provided with ProBASIC. I hope
this is enough to give some idea of the system. There is more help for
using and programming in the environment which seems to be a modified
BASIC.SYSTEM program.

I'm not sure what the speed trade off is. It's been a few years since I
used it and even then, not much. I see a limit of 255 modules. Likewise,
there is a limit on the keyword table size but no mention of how big it
is. It should only be a problem if you have close to the maximum number
of modules and the module names are over 8 characters. It also allows
recursion although it doesn't say how deep you can recurse to.

Disk based modules are available but they aren't required. Mostly useful
for large programs or when extra variable space is needed.

Looking a some notes I had scribbled, you can use Program Writer. My
only complaint is the inability to work with Beagle's Extra Variables.
That would make a powerful combination.

Cheers,
Mike T.

Paul Schlyter

2006-10-24 12:45:27 UTC

................

Post by finksterj
I know the Beagle Compiler can "chain" multiple programs together, so
the limitation on program size is moot as you can split your code into
smaller segments and chain them using common variables.

finksterj

2006-10-24 16:42:31 UTC

Post by Paul Schlyter
................

....but it is a p.i.t.a. to have to split up your programs into chaine'd
modules like that. If you're unlucky, the program can end up thrashing
between chained modules all the time, making the effective execution of
the program almost grind to a halt.
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/

I agree it might be difficult & tedius to chain multiple programs
together using the Beagle Compiler, but if you are implying that
chaining regular Applesoft programs together is prone to some random
trashing between modules, I assure you that is not the case. You can
succesfully chain multiple problems together with common variables,
machine language routines, and the hi-res screen without problems.

Paul Schlyter

2006-10-25 06:43:01 UTC

Post by Paul Schlyter
................

finksterj

2006-10-25 19:53:29 UTC

Post by Paul Schlyter
................

I agree it might be difficult & tedius to chain multiple programs
together using the Beagle Compiler, but if you are implying that
chaining regular Applesoft programs together is prone to some random
trashing between modules, I assure you that is not the case. You can
successfully chain multiple problems together with common variables,
machine language routines, and the hi-res screen without problems.

If we disregard the cases of incompetent programming, it's the program
logic which decides how well suited the program is for chaining. If
the program is nicely sequential (i.e. it does A, then B, then C, then
D, then E, then F, and then terminates), it is well suited for
chaining. But if the program jumps between all of A,B,C,D,E,F all the
times, and a large number of times, during execution, then it is less
well suited for chaining.
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/

In general I will agree, however there is a finite amount of memory
available to Applesoft, so any program of even moderate complexity will
require chaining between different modules-usually many times during
execution-while keeping common variables intact and co-existing with
machine language programs and the hi-res screen. This presents no real
difficulty or problems.

For example, Silvern Castle has over a dozen chained modules that are
called multiple times so that most of these chained programs are
executed for a total of over 100 times during the course of an average
30 minute game session.

I have yet to see any ill-efforts or problems due to this multiple
chaining. Not even disk access is much of an issue due to the
relatively small size of the modules-although I do preload the
most-used modules to the ProDOS /RAM drive for best performance.

Linards Ticmanis

2006-10-24 08:17:48 UTC

Post by Michael J. Mahon
If you really feel you need the "level" of BASIC and the speed of
machine language, then your best approximation will probably be one
of the BASIC-like macro assembler packages. I believe that Nibble
offered such a package (maybe "Macrosoft"?).

If it doesn't have to be BASIC but you just don't want to use Assembly,
you could use the "cc65" C Cross-Compiler. The code it produces is still
inferior to hand assembly, but should be a good bit more optimal than
compiled BASIC.

--
Linards Ticmanis

Paul Schlyter

2006-10-24 12:45:27 UTC

Post by Michael J. Mahon
Unlike most 8-bit microcontrollers today, the 6502 has *very* few
*real* compilers (that compile to machine language).

Both of those either loaded or "compiled in" runtimes.

:-) ....virtually any compiler will have runtime libraries which are
linked in with the compiled code to produce a stand-alone executable.
Remember good ol' Turbo Pascal for CP/M? The first 8 kBytes of any
.COM file produced by Turbo Pascal was the runtime library.

Post by Michael J. Mahon
The "machine code" that they produced was mostly calls to
runtime routines.

That was the norm of code for 8-bit CPU's generated by compilers:
after all, these CPU's had a quite limited instruction set, so mostly
anything beyond integer add and subtract was done by calling a
subroutine in the runtime library. You wouldn't expect floating-point
arithmetic to be performed by 6502 inline code, would you?

Also, since Applesoft has no integer arithmetic (all arithmetic is
done in floating-point in Applesoft), there isn't much you can inline
when compiling Applesoft to 6502 machine code -- unless you want a
REALLY bloated Applesoft program, where each and every arithmetic
operation would take some 500 bytes of machine code! With such
bloated code, you wouldn't be able to do much within 48K of memory.

Post by Michael J. Mahon
While this is to be expected as a time-for-space tradeoff for
large programs, it results in code that is much inferior to
the in-line code that most people associate with compilation
to machine language.

With modern CPU's which have much more powerful instruction sets,
one can do much more with inline code. But if the inline code
for one single operation would occupy hundreds of bytes, the
overhead of putting it in a subroutine would be quite negligible.

Post by Michael J. Mahon
In fact, the architecture of the 6502 pretty much dictates this
kind of approach, though it would have been possible to only load
the parts of the runtime that were actually needed instead of the
whole thing, as is usually done.

Loading runtime libraries "as needed" as you suggest here would
require relocation of machine code to the addresses currently
avaiable - and code relocation is another weak point of the 6502....

Post by Michael J. Mahon
My point is that there are no BASIC compilers that I know of for
the Apple II that will compile *directly* to *in-line* machine code.

Indeed very true --- and I don't think you'll find such a BASIC
compiler for any other system either. They all have runtime libraries.

Nevertheless, Applesoft programs compiled with Expediter II runs many
times faster than the same program run on the Applesoft Interpreter.

If you really need that speed, you should forget about the Apple II
and go for a modern computer instead! An interpreted language on a
modern CPU runs much faster than even the most skillfully hand
optimized assembly code for the 6502 -- after all, Apple II emulators
nowadays run some 10+ times faster than the original hardware.

Lyrical Nanoha

2006-10-24 13:11:01 UTC

Post by Paul Schlyter
Also, since Applesoft has no integer arithmetic (all arithmetic is
done in floating-point in Applesoft), there isn't much you can inline
when compiling Applesoft to 6502 machine code -- unless you want a
REALLY bloated Applesoft program, where each and every arithmetic
operation would take some 500 bytes of machine code! With such
bloated code, you wouldn't be able to do much within 48K of memory.

I thought fpbasic had the % variable type (16-bit signed integer)?

-uso.

Paul Schlyter

2006-10-24 15:44:21 UTC

I thought fpbasic had the % variable type (16-bit signed integer)?
-uso.

Yes, it does. But Applesoft does execute this line:

10 A% = B% + C%

as:

Load integer B%, convert to floating point
Convert integer C% to floating point, add it
Convert the sum to integer and store in A%

Having integer variables is NOT the same as having integer arithmetic.

If you try MBASIC under Apple CP/M; you'll notice a difference.
That interpreter has integer arithmetic as distinct from floating-point
arithmetic. Under MBASIC, the statement

10 A% = 1% + 2%

will execute significantly faster than

10 A% = 1.0 + 2.0

and if you compile your MBASIC program with BASIC COMPILER, the former
will execute hundreds of times faster than the latter (the former will
be compiled to inline code for an integer addition, while the latter
will compile to a subroutin calls for floating-point addition).

So Applesoft do have integer variables, but no integer arithmetic.
And the operation

30000 * 10

won't overflow, because it is performed in floating-point arithmetic.
In MBASIC, the operation 30000% * 10% *will* overflow !!!!

Knut Roll-Lund

2006-10-24 16:21:47 UTC

I thought fpbasic had the % variable type (16-bit signed integer)?
-uso.

10 A% = B% + C%
Load integer B%, convert to floating point
Convert integer C% to floating point, add it
Convert the sum to integer and store in A%
Having integer variables is NOT the same as having integer arithmetic.
If you try MBASIC under Apple CP/M; you'll notice a difference.
That interpreter has integer arithmetic as distinct from floating-point
arithmetic. Under MBASIC, the statement
10 A% = 1% + 2%
will execute significantly faster than
10 A% = 1.0 + 2.0
and if you compile your MBASIC program with BASIC COMPILER, the former
will execute hundreds of times faster than the latter (the former will
be compiled to inline code for an integer addition, while the latter
will compile to a subroutin calls for floating-point addition).
So Applesoft do have integer variables, but no integer arithmetic.
And the operation
30000 * 10
won't overflow, because it is performed in floating-point arithmetic.
In MBASIC, the operation 30000% * 10% *will* overflow !!!!

I'm surprised, on the TRS-80 which also has Microsoft basic, though a
bit differently looking, does integer operations on integers (and it is
an important point to use integers for speed). This is so except for
division where the actual division is done in single precision. Even
constants are done as integers as long as they fit.

The Microsoft basic came with the TRS-80 (Model I) Level II that came in
August 1978. The original TRS-80 Microcomputer (Model I Level I) from
August 1977 had a basic that was made by Tandy famous for its error
messages: 3 in all WHAT?, HOW? and SORRY (means syntaxerr, outofrange
and outofmemory respectively). :-)

--
Knut
(delete 'nogarbage.' for email)

Michael J. Mahon

2006-10-24 18:22:31 UTC

I thought fpbasic had the % variable type (16-bit signed integer)?
-uso.

In Applesoft, constants are represented in ASCII in the program
text and converted on each use. This is why assigning a frequently
used constant to a variable speeds up a program.

Post by Knut Roll-Lund
The Microsoft basic came with the TRS-80 (Model I) Level II that came in
August 1978. The original TRS-80 Microcomputer (Model I Level I) from
August 1977 had a basic that was made by Tandy famous for its error
messages: 3 in all WHAT?, HOW? and SORRY (means syntaxerr, outofrange
and outofmemory respectively). :-)

In the tradition of the JOSS language for the Johnniac computer at
RAND, which had exactly one error message: Eh?

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Knut Roll-Lund

2006-10-24 19:47:02 UTC

I thought fpbasic had the % variable type (16-bit signed integer)?
-uso.

In Applesoft, constants are represented in ASCII in the program
text and converted on each use. This is why assigning a frequently
used constant to a variable speeds up a program.

Yes A=1:B=A is faster than A=1:B=1 this is similar, constants are stored
as ascii also on a TRS-80, but when converted they start out as integers
and will convert to single or double precision as needed. Line numbers
after THEN, ELSE, GOTO or GOSUB are also stored as ASCII but the line
numbers themselves (at the beginning of a line) is stored digitally 16 bit.

I have a basic compiler for the TRS-80 that does a strange hybrid thing;
ACCEL2. I bought it back in the old days. It will put assembly into
comments within the basic program and there is a small runtime library
too. It will compile only what is advantageous. The output is smaller
and a lot faster.

Post by Knut Roll-Lund
The Microsoft basic came with the TRS-80 (Model I) Level II that came
in August 1978. The original TRS-80 Microcomputer (Model I Level I)
from August 1977 had a basic that was made by Tandy famous for its
error messages: 3 in all WHAT?, HOW? and SORRY (means syntaxerr,
outofrange and outofmemory respectively). :-)

In the tradition of the JOSS language for the Johnniac computer at
RAND, which had exactly one error message: Eh?

So it is not unique :-)

I write software and identifying and then explaining to the user and/or
log what went wrong is so much tedious work. But of course I benefit
from it too getting less phone calls from frustrated users, or can at
least identify what is wrong so I can help them.

--
Knut
(delete 'nogarbage.' for email)

Michael J. Mahon

2006-10-25 01:36:39 UTC

Post by Knut Roll-Lund
I'm surprised, on the TRS-80 which also has Microsoft basic, though a
bit differently looking, does integer operations on integers (and it
is an important point to use integers for speed). This is so except
for division where the actual division is done in single precision.
Even constants are done as integers as long as they fit.

In Applesoft, constants are represented in ASCII in the program
text and converted on each use. This is why assigning a frequently
used constant to a variable speeds up a program.

I believe this approach is common to all interpreted Microsoft BASICs.

Whether integer arithmetic or floating point arithmetic is used in
evaluating constants is an implementation decision, regardless of
the final number format desired, assuming that sufficient precision
is retained (32-bit integers, for example).

I'd have to look at the disassembly to see exactly what Applesoft
does. (If I were doing it, I'd accumulate the integer in the FAC
mantissa, keeping note of where/if I saw a decimal point and/or
exponent. Then I'd scale in floating point if required, and then
return either the integer or the FP result, as required.)

Of course, having to convert ASCII to binary on each use is painful
with integer operations (multiply by 10 and add for each digit),
but excruciating with FP ops (same thing, but much slower). ;-)

Post by Knut Roll-Lund
Line numbers
after THEN, ELSE, GOTO or GOSUB are also stored as ASCII but the line
numbers themselves (at the beginning of a line) is stored digitally 16 bit.

Right. The only case I can think of that is kept in binary--and it's a
good thing, since branches (but not FOR loops) require searching the
line list each time!

Post by Knut Roll-Lund
I have a basic compiler for the TRS-80 that does a strange hybrid thing;
ACCEL2. I bought it back in the old days. It will put assembly into
comments within the basic program and there is a small runtime library
too. It will compile only what is advantageous. The output is smaller
and a lot faster.

An interesting approach...so it must "patch" the BASIC program so that
it gets control to the machine code?

I remember looking into a scheme to pre-compute branch targets in
Applesoft programs to eliminate the need to search the program
repeatedly. I finally got an accelerator and just let it go. ;-)

Post by Knut Roll-Lund
The Microsoft basic came with the TRS-80 (Model I) Level II that came
in August 1978. The original TRS-80 Microcomputer (Model I Level I)
from August 1977 had a basic that was made by Tandy famous for its
error messages: 3 in all WHAT?, HOW? and SORRY (means syntaxerr,
outofrange and outofmemory respectively). :-)

In the tradition of the JOSS language for the Johnniac computer at
RAND, which had exactly one error message: Eh?

So it is not unique :-)

The idea was that JOSS statements were pretty simple, so if you
called the scientist's attention to a statement with an error, it
would be "obvious". ;-)

Post by Knut Roll-Lund
I write software and identifying and then explaining to the user and/or
log what went wrong is so much tedious work. But of course I benefit
from it too getting less phone calls from frustrated users, or can at
least identify what is wrong so I can help them.

Back in the "bad old days" we just told them to RTFM--if they couldn't
either figure it out or document a bug, they weren't smart enough to
use the computer. ;-)

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Paul Schlyter

2006-10-25 07:43:32 UTC

An interesting approach...so it must "patch" the BASIC program so that
it gets control to the machine code?

Microsoft's MBASIC (runs under CP/M) does that too: integers which are
line number targets (such as in GOTO, GOSUB, etc) are initially stored
as the line number itself, as a 16-bit binary integer. The first time
the GOTO or GOSUB is executed, the interpreter searches for that line
number as expected. But when the line number is found, something
interesting happens: the token for GOTO is changed into another token
which also means GOTO, and the line number is replaced by the offset
for the start of the line in the tokenized Basic program. If the
Basic program is saved in tokenized rather than ASCII format, this
information is preserved so that the interpreter doesn't have to look
for the line at all the next time that program is loaded and run, the
GOTO/GOSUB statement already knows where it is!

But what happens then in an MBASIC program which have "compiled" its
GOTO/GOSUB statements if you modify the program, by adding, removing
or modifying some line? That can potentially invalidate any offset to
the target line after a GOTO/GOSUB. In that case the interpreter,
before modifying the program, scans all through it and replaces all
GOTO/GOSUBS's having machine addresses with GOTO/GOSUB's with
corresponding line numbers instead.

This applies to any statements containing target line numbers: not
just GOT and GOSUB but also ON N GOTO <list of line numbers>, ON ERROR
GOTO <line number> (error handling), RESUME <line number> (determines
where an error handler should resume execution after handling the
error) and RESTORE <line number> (determines where the next READ
statement should start reading its DATA lines).

In Applesoft, it is recommended that frequently called subroutines
should be put near the beginning of the program, since then the
GOSUB statement will find the target line faster. In MBASIC, this
doesn't matter, since the GOSUB will have to scan for the target
line just once - after that it "remembers" where the target line is.

Knut Roll-Lund

2006-10-25 22:33:45 UTC

Post by Knut Roll-Lund
I have a basic compiler for the TRS-80 that does a strange hybrid
thing; ACCEL2. I bought it back in the old days. It will put assembly
into comments within the basic program and there is a small runtime
library too. It will compile only what is advantageous. The output is
smaller and a lot faster.

An interesting approach...so it must "patch" the BASIC program so that
it gets control to the machine code?

The TRS-80 has basic in rom executing straight out if the ROM, 12K (and
many machine code programs rely on calling rom routines) but it has some
jumps to the low ram which are made for disk basic to add some commands
for disk handling etc. These jump-returns are used to intercept basic.

--
Knut
(delete 'nogarbage.' for email)

Michael J. Mahon

2006-10-26 01:45:25 UTC

Post by Knut Roll-Lund
I have a basic compiler for the TRS-80 that does a strange hybrid
thing; ACCEL2. I bought it back in the old days. It will put assembly
into comments within the basic program and there is a small runtime
library too. It will compile only what is advantageous. The output is
smaller and a lot faster.

An interesting approach...so it must "patch" the BASIC program so that
it gets control to the machine code?

Sorry, I should have been more precise: by BASIC program, I meant
the tokenized text of the BASIC program, not the BASIC interpreter.

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Knut Roll-Lund

2006-10-26 18:49:16 UTC

Post by Knut Roll-Lund
I have a basic compiler for the TRS-80 that does a strange hybrid
thing; ACCEL2. I bought it back in the old days. It will put
assembly into comments within the basic program and there is a small
runtime library too. It will compile only what is advantageous. The
output is smaller and a lot faster.

An interesting approach...so it must "patch" the BASIC program so that
it gets control to the machine code?

The TRS-80 has basic in rom executing straight out if the ROM, 12K
(and many machine code programs rely on calling rom routines) but it
has some jumps to the low ram which are made for disk basic to add
some commands for disk handling etc. These jump-returns are used to
intercept basic.

Sorry, I should have been more precise: by BASIC program, I meant
the tokenized text of the BASIC program, not the BASIC interpreter.

Sorry, my mistake. On TRS-80 DOS the BASIC is an application, a program
(even if it will call and is much based on ROM routines).

Yes, much of the BASIC program "disappears", hides and since it is
binary it can't be saved with the normal BASIC SAVE or CSAVE command,
one needs a machine code saving program either from the DOS, or with
cassette a program like the one they made and sold separately. Also you
couldn't edit it any more so if you needed to change it you would have
to go back to the source and edit then recompile. It was pretty fast
compiling too, which of course depended on the size of the program. With
the ACCEL2 it was pretty easy to create games in BASIC and still get a
good speed.

BTW it gave you opportunity to write nicer, tidier code with comments.
It no longer mattered with few statements per line, comments or where in
a program the GOTO was to.

--
Knut
(delete 'nogarbage.' for email)

Paul Schlyter

2006-10-25 07:43:32 UTC

Post by Michael J. Mahon
In Applesoft, constants are represented in ASCII in the program
text and converted on each use. This is why assigning a frequently
used constant to a variable speeds up a program.

Yes A=1:B=A is faster than A=1:B=1

...and A=1:B=1 is faster than A=1.00000000:B=1.00000000 :-)

Btw whether B=A is faster than B=1 may depend on how many variables your
program has. The "=A" require a lookup of the variable A. IF your program
has few variables (as small test programs tend to have), B=A is definitely
faster than B=1. But if your program has a large number of variables,
then B=A may be slower, depending on where in the list of variables A
happens to reside.

Paul Schlyter

2006-10-25 06:43:01 UTC

...............

Post by Paul Schlyter
So Applesoft do have integer variables, but no integer arithmetic.
And the operation
30000 * 10
won't overflow, because it is performed in floating-point arithmetic.
In MBASIC, the operation 30000% * 10% *will* overflow !!!!

I'm surprised, on the TRS-80 which also has Microsoft basic, though a
bit differently looking, does integer operations on integers (and it is
an important point to use integers for speed). This is so except for
division where the actual division is done in single precision. Even
constants are done as integers as long as they fit.
The Microsoft basic came with the TRS-80 (Model I) Level II that came in
August 1978. The original TRS-80 Microcomputer (Model I Level I) from
August 1977 had a basic that was made by Tandy famous for its error
messages: 3 in all WHAT?, HOW? and SORRY (means syntaxerr, outofrange
and outofmemory respectively). :-)

The TSR-80 was an 808 or Z80 based computer. Microsoft did put considerably
more effort into its Basic interpreters in 8080 assembly language than
the interpreters in 6502 assembly language.

The Applesoft (as well as the Commodore PET and C64) Basic had one
advantage in its floating point though: better precision than normal
single precision. Single precision f.p. numbers usually occupy 4
bytes, which leaves room for 6 or 7 decimal digits of precision.
Double precision occupies twise as much, 8 bytes, giving 14 to 16
decimal digits of precision. Applesoft Basis used 5 bytes for its
floating point, which gave 9 or 10 decimal digits of precision.

(early versions of Turbo Pascal, which used software floating point,
used 6 bytes for its f.p. numbers, yielding sime 12 decimal digits of
precision)

Post by Knut Roll-Lund
--
Knut
(delete 'nogarbage.' for email)

Knut Roll-Lund

2006-10-25 22:41:37 UTC

Post by Paul Schlyter
...............

I'm surprised, on the TRS-80 which also has Microsoft basic, though a
bit differently looking, does integer operations on integers (and it is
an important point to use integers for speed). This is so except for
division where the actual division is done in single precision. Even
constants are done as integers as long as they fit.
The Microsoft basic came with the TRS-80 (Model I) Level II that came in
August 1978. The original TRS-80 Microcomputer (Model I Level I) from
August 1977 had a basic that was made by Tandy famous for its error
messages: 3 in all WHAT?, HOW? and SORRY (means syntaxerr, outofrange
and outofmemory respectively). :-)

The TSR-80 was an 8080 or Z80 based computer. Microsoft did put considerably
more effort into its Basic interpreters in 8080 assembly language than
the interpreters in 6502 assembly language.

Z-80 at a blazing 1.76MHz for model I (same family: model III does 2MHz
and model 4 does 4MHz).

--
Knut
(delete 'nogarbage.' for email)

Michael J. Mahon

2006-10-24 18:51:16 UTC

Post by Michael J. Mahon
Unlike most 8-bit microcontrollers today, the 6502 has *very* few
*real* compilers (that compile to machine language).

Both of those either loaded or "compiled in" runtimes.

:-) ....virtually any compiler will have runtime libraries which are
linked in with the compiled code to produce a stand-alone executable.
Remember good ol' Turbo Pascal for CP/M? The first 8 kBytes of any
..COM file produced by Turbo Pascal was the runtime library.

I was responding to your statement that appeared to contrast
compilers that loaded runtime packages with those that ran
"stand-alone" code.

Frankly, whether or not the runtime is included in the same file
as the executable is pretty irrelevant (except that many such programs
on a disk will require more space than a system that loads the runtime
as a separate file).

Post by Michael J. Mahon
The "machine code" that they produced was mostly calls to
runtime routines.

after all, these CPU's had a quite limited instruction set, so mostly
anything beyond integer add and subtract was done by calling a
subroutine in the runtime library. You wouldn't expect floating-point
arithmetic to be performed by 6502 inline code, would you?

Of course not, as I've commented elswhere in this thread.

But there's a big difference between a large, fixed-size runtime
and a "present only if used" runtime, particularly for simple
programs.

This seemed to be the point raised by the OP, to which I was
responding.

But most Applesoft compilers understood the "%" integer datatype
(or had other REM-like declarations) to specify 16-bit integer
arithmetic, not floating-point. It is reasonable to expand 16-bit
integer arithmetic, moves, and compares in-line.

In fact, for many "controller" apps, most of the program logic
could be expressed quite nicely in terms of 16-bit data and
operations, and something approximating real machine code could
be achieved.

Exactly. So the issue is whether the program can be largely
expressed as operations involving 16-bit integers. (Which reminds
me, has the OP considered the Flash *Integer BASIC* compiler? I'll
bet it does a pretty reasonable job.)

Loading runtime libraries "as needed" as you suggest here would
require relocation of machine code to the addresses currently
avaiable - and code relocation is another weak point of the 6502....

I agree that it is non-trivial, and I know of no Apple BASIC compiler
that emits assembly code, which would solve that problem simply by
appending the required runtime routines to the assembly.

There are ways to handle it without reassembly, like writing
location-independent 6502 code (not bad for short non-self-modifying
routines), but they can cost speed, which is a problem.

Post by Michael J. Mahon
My point is that there are no BASIC compilers that I know of for
the Apple II that will compile *directly* to *in-line* machine code.

Indeed very true --- and I don't think you'll find such a BASIC
compiler for any other system either. They all have runtime libraries.

Of course, every language system has runtime libraries for complex
operations, but many Apple compiler writers seem to have been so
concerned with code expansion that they made their implementations
little more than calls to interpretive execution routines.

Post by Paul Schlyter
Nevertheless, Applesoft programs compiled with Expediter II runs many
times faster than the same program run on the Applesoft Interpreter.

It would be quite interesting to see comparisons of code generated
by various compilers for the Apple II. I expect there are some
significant differences.

Sure, but that goes a bit beyond the scope of both this forum and
the OP's question...

There's quite a gap between the speed of interpreted Applesoft,
the speed of machine code on an Apple II, and the speed of modern
machines--plenty of room for applications in each speed range.

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Paul Schlyter

2006-10-25 06:43:01 UTC

Post by Michael J. Mahon
Unlike most 8-bit microcontrollers today, the 6502 has *very* few
*real* compilers (that compile to machine language).

Both of those either loaded or "compiled in" runtimes.

:-) ....virtually any compiler will have runtime libraries which are
linked in with the compiled code to produce a stand-alone executable.
Remember good ol' Turbo Pascal for CP/M? The first 8 kBytes of any
..COM file produced by Turbo Pascal was the runtime library.

I was responding to your statement that appeared to contrast
compilers that loaded runtime packages with those that ran
"stand-alone" code.
Frankly, whether or not the runtime is included in the same file
as the executable is pretty irrelevant (except that many such programs
on a disk will require more space than a system that loads the runtime
as a separate file).

I fully agree with that. Perhaps I expressed myself unclearly, but
I really meant pseudo-code which needs to be interpreted, rather than
machine code which mostly is a long string of CALL instructions.

Post by Michael J. Mahon
The "machine code" that they produced was mostly calls to
runtime routines.

Of course not, as I've commented elswhere in this thread.
But there's a big difference between a large, fixed-size runtime
and a "present only if used" runtime, particularly for simple
programs.
This seemed to be the point raised by the OP, to which I was
responding.

But most Applesoft compilers understood the "%" integer datatype
(or had other REM-like declarations) to specify 16-bit integer
arithmetic, not floating-point. It is reasonable to expand 16-bit
integer arithmetic, moves, and compares in-line.
In fact, for many "controller" apps, most of the program logic
could be expressed quite nicely in terms of 16-bit data and
operations, and something approximating real machine code could
be achieved.

Perhaps good ol' Integer Basic would then be a better language?
It has (only) integer arithmetic.

It does -- but Flash does not compile to 6502 machine code, but to
a Forth-like threaded code. But that pseudo-code is interpreted
much more rapidly than Integer Basic programs.

Loading runtime libraries "as needed" as you suggest here would
require relocation of machine code to the addresses currently
avaiable - and code relocation is another weak point of the 6502....

I agree that it is non-trivial, and I know of no Apple BASIC compiler
that emits assembly code, which would solve that problem simply by
appending the required runtime routines to the assembly.
There are ways to handle it without reassembly, like writing
location-independent 6502 code (not bad for short non-self-modifying
routines), but they can cost speed, which is a problem.

Actually, Apple once made an effort to use the "R" file type in Apple
DOS, for relocatable 6502 object code. That code was not executable
though until it had ben processed by a linker.

There was even a third-party Linker utility, which could be used with
any Apple II assembler. Linker required you to follow specific
conventions in your assembly code, to mark and name entry points,
calls to external routines, and to mark blocks of code, relocatable
data, and non-relocatable data. You could then build a library of
routines, where each routine resided in its own binary file. Linker
linked it all together into one signle binary file, and could relocate
library modules but only by even multiples of 256 bytes.

Post by Michael J. Mahon
My point is that there are no BASIC compilers that I know of for
the Apple II that will compile *directly* to *in-line* machine code.

Indeed very true --- and I don't think you'll find such a BASIC
compiler for any other system either. They all have runtime libraries.

With only 48K RAM available, that's an understandable trade-off.

Post by Paul Schlyter
Nevertheless, Applesoft programs compiled with Expediter II runs many
times faster than the same program run on the Applesoft Interpreter.

It would be quite interesting to see comparisons of code generated
by various compilers for the Apple II. I expect there are some
significant differences.

Such comparisons were made back in the 1980's, and as far as I
remember, Microsoft's TASC (The AppleSoft Compilter) was the winner in
runtime speed but was much slower than all the others in compilation
speed. Expediter II (the "Einstein" compiler) came second in runtime
speed, and was among the fastest in compilation speed.

What I meant is that it's not really fun to strain the ability of your
hardware, e.g. by writing huge programs which need 4711 chained modules
to fit at all. Back in the early 1980's it could be understandable,
because then perhaps you couldn't afford more powerful hardware. Today
that situation is drastically different.

Michael J. Mahon

2006-10-25 17:01:59 UTC

Post by Paul Schlyter
Loading runtime libraries "as needed" as you suggest here would
require relocation of machine code to the addresses currently
avaiable - and code relocation is another weak point of the 6502....

I agree that it is non-trivial, and I know of no Apple BASIC compiler
that emits assembly code, which would solve that problem simply by
appending the required runtime routines to the assembly.
There are ways to handle it without reassembly, like writing
location-independent 6502 code (not bad for short non-self-modifying
routines), but they can cost speed, which is a problem.

Actually, Apple once made an effort to use the "R" file type in Apple
DOS, for relocatable 6502 object code. That code was not executable
though until it had ben processed by a linker.
There was even a third-party Linker utility, which could be used with
any Apple II assembler. Linker required you to follow specific
conventions in your assembly code, to mark and name entry points,
calls to external routines, and to mark blocks of code, relocatable
data, and non-relocatable data. You could then build a library of
routines, where each routine resided in its own binary file. Linker
linked it all together into one signle binary file, and could relocate
library modules but only by even multiples of 256 bytes.

I have a technique that I use to relocate short routines, that is
also restricted to page boundaries. I don't think I've ever seen
it used by others, even though it's pretty obvious.

I assemble the code at some arbitrary page origin, then scan the
code (I use a BASIC histogram program) looking for unused byte values.
(In any routine less than one page in length, there must be unused
byte values, of course.) I then change the page origin to one of
those unused values and re-assemble.

When I load the module, I use a trivial relocator that scans for
the byte value that now uniquely marks the high bytes of relocatable
addresses, and replaces them with the new page number.

This is extremely fast, can be combined with "move" code, if that
is required, and requires almost no logic.

If several modules are to be relocated in a single program, the
"magic" value can be stored at a fixed point in the module code
where the relocation loop can find it easily. (Often a module
starts with a short vector of JMPs to entry points, and the high
byte of the first such JMP is a natural place.)

This relocation technique can often be used successfully with modules
several pages long, but then it *is* possible for every byte value to
be used, so it may not work without some "fiddling" (that may need
redoing if the module source is altered).

Post by Michael J. Mahon
My point is that there are no BASIC compilers that I know of for
the Apple II that will compile *directly* to *in-line* machine code.

Indeed very true --- and I don't think you'll find such a BASIC
compiler for any other system either. They all have runtime libraries.

With only 48K RAM available, that's an understandable trade-off.

If there is only one way, that's probably what is required.

It is a shame, though, that no one ever addressed the "speed" side
of the space/speed tradeoff.

Post by Paul Schlyter
Nevertheless, Applesoft programs compiled with Expediter II runs many
times faster than the same program run on the Applesoft Interpreter.

It would be quite interesting to see comparisons of code generated
by various compilers for the Apple II. I expect there are some
significant differences.

It's slow compile speed was no doubt a result of it being itself a
TASC-compiled Applesoft program! (This is clear if you enter the
monitor and take a look in memory--the runtime is obvious.)

Many would consider this a case of taking self-compilation a step
too far. ;-) But it is interesting to contemplate an Applesoft
compiler written in Applesoft. And it does keep the writers honest,
since the compiler must be able to compile itself--a pretty large
program exercising much of the language.

I'd love to find the source code for TASC! It is unique, AFAIK.

One could attempt a de-compilation, but the original program would be
a treasure!

This is true for many practical purposes--but in this forum we are a
cadre of folks who 1) love Apple II's, 2) enjoy a challenge, and
3) are amused by puzzle solving. ;-)

BTW, I couldn't agree more about the practical difficulties in
organizing a complex overlay scheme. It's hard enough to get a
*correct* organization (that doesn't overwrite needed info), but
getting an *efficient* organization is really difficult.

Some programs have a structure that naturally suggests a simple
overlay/chain structure, but many large programs do not.

-michael

NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Liam Busey

2006-10-25 21:08:44 UTC

-snip-

Post by Michael J. Mahon
There are ways to handle it without reassembly, like writing
location-independent 6502 code (not bad for short non-self-modifying
routines), but they can cost speed, which is a problem.

Actually, Apple once made an effort to use the "R" file type in Apple
DOS, for relocatable 6502 object code. That code was not executable
though until it had ben processed by a linker.
There was even a third-party Linker utility, which could be used with
any Apple II assembler. Linker required you to follow specific
conventions in your assembly code, to mark and name entry points,
calls to external routines, and to mark blocks of code, relocatable
data, and non-relocatable data. You could then build a library of
routines, where each routine resided in its own binary file. Linker
linked it all together into one signle binary file, and could relocate
library modules but only by even multiples of 256 bytes.

This sounds interesting. Do you recall the name of the linker?

Liam Busey

Michael J. Mahon

2006-10-26 01:46:31 UTC

Post by Liam Busey
-snip-