The CDPD Public Domain Collection for CDTV 3/CDPDIII.bin/pd/programming/amos/acomp136.dms/acomp136.adf/About_Compiler_1.36

Text File | 1993-03-15 | 18KB | 476 lines

-----------------------------------------------------------------------------

                      AMOS BASIC VERSION 1.36 UPDATER

                              By François Lionet

                AMOS Compiler (c) 1991 Europress Software Ltd.
                  AMOS (c) 1991 Europress Software Ltd.

-----------------------------------------------------------------------------

                           Important copyright notes
                          ---------------------------

     The AMOS Compiler 1.36 Updater is public domain. You can (and you
     are encouraged to) copy and distribute it freely. It does not mean
     the AMOS Compiler itself is public domain. Copyright remains on all
     compiler system files.

     You need AMOS Basic V1.1, V1.21, V1.23, V1.3, V1.31, V1.32, V1.34
     and AMOS Compiler V1.0 or 1.12 to make the adaptation.


------------------------------------------------------------------------------
                    Move the mouse pointer to read the text.
------------------------------------------------------------------------------






Foreword.
-------------------------------------------------------------------------

Welcome to the third PD. update of the AMOS Compiler. This updater will
save out a new AMOS Compiler version 1.36.

This update of the compiler brings only one new feature compared to the
previous version (1.34) : compiled programs now work on a AA machine.

If you already own compiler V1.34, this will be the only modification
since the last version.

If you own a previous version of the Compiler, you will find that a lot
of work has been done to the code, and that a lot of problems have been
removed from the compiler.

You have discovered quite a few problems with the compiler, even though we
pumped the whole AMOS PD. library through it before its release! Each user has
their own programming style, and the Compiler has to cope with all of them.
We have also discovered that some problems were only due to tricky
programming habits. Please read the "pseudo-errors" chapter in this file!

We go on with our policy of PD. updates, and we hope that your bank account
likes it. For us, doing this is like saying a big thank you for all your
feedback.


Cheers! François 01/02/1993


Contents.
---------------------------------------------------------------------------

    * Enhancements to V1.34
    * Bugs removed from V1.12
    * Enhancements to V1.12
    * Pseudo compiler errors.
    * Quick problem reference list.
    * How to create a bootable disc.
    * Bugs removed from V1.0


Enhancement to V1.34
------------------------------------------------------------------------

* Compiled programs now work perfectly on a AA machine. You can as usual
flip between a AA workbench and the AMOS Program.
The new method used on a AA machine makes it impossible to work under
interrupts. That's why you will discover that it Amiga-A does not respond
when a disc activity is taking place, but only when disc access is over.


Bugs removed from V1.12.
------------------------------------------------------------------------

* Icons are now in replace mode when a program boots.

* CBLOCK now works on screens larger than 480 pixels.

* PRINT # used to send a CHR$(0) each time it encountered a semi column.
  You could not access a printer properly.

* =DIR$ used to crash without disc.

* DIR$= does not leave a lock on the disc. The directory system works like it
  does in AMOS 1.34. Please refer to this documentation.

* VAL() now stops on spaces when entering hexadecimal or binary numbers.

* VAL() now works fine in both Workbench and AMOS compiled programs. You
  *MUST* read the pseudo-problems chapter about this!

* You can now have floating point numbers in a compiled .AMOS program.

* The annoying odd SET BUFFER bug is corrected : the compiler used to
  set buffer to 520 or over in a .AMOS program!

* A compiled program does not load the DISK FONT library upon running. It
  only asks for it when you GET FONT for the first time. So if your program
  does not use graphic fonts, you will gain memory (51k on a 2.0 system!)

* Close Workbench now works under WB 2.0.

* The requester now appears in the AMOS environment under WB2.0. Disc swaps
  are correctly detected. It does not crash any more under WB1.3 as it
  did sometimes.

* Error trapping is now fully corrected. Quite a lot of bugs there! RESUME and
  RESUME NEXT did not work in a GOSUB, or in a .AMOS compiled program.
  The ERROR instruction now reports errors over 50.

* Def FN works fine under the compiler with floats.

* SET RAINBOW used to crash with illegal parameters.

* A FOLLOW left in the program does not crash the compiler.

* RANDOMIZE was bugging the compiled program pile, thus leading to crashes
  later on. Very difficult bug to find.

* ICON BANKS are now detected by a compiled program.

* PRINT USING does not crash with an empty string.

* UNDER ON/OFF is no longer compiled as INVERSE.

* Compiled program's icons are not saved over each other.

* EVERY works fine. At last!

* A very bad bug caused the compiler to crash or report a "Label Not Defined"
  when compiling certain programs.
  If a program has an area of code that uses up exactly 510 bytes with no JSR
  machine code calls being made, a relocation problem would occur. This was
  a very rare situation which could vanish as quickly as it had appeared.
  For example, you could make one line change to your code and it would
  compile cleanly again!




Enhancements to V1.12.
------------------------------------------------------------------------------

All enhancements done to AMOS (new instructions, new directory system) have
been ported into the compiler. A program exploiting these new facilities
will compile.

Please refer to the "About_AMOS_1.34" documentation on the AMOS updater.





Pseudo Compiler bugs.
-----------------------------------------------------------------------------

This chapter is crucial. If something goes wrong with your compiler, please
read this first, and check to see if the problem cannot be corrected.
In 99% of cases, it can.


  Floating Point.
  ---------------
The old AMOS Compiler classic problem.

Your program uses floating point numbers. It works fine under AMOS, but you
get strange results once compiled (very large negative numbers, illegal
function call etc...).
All you need to do is insert the next line :

A#=0.0

at the very beginning of your program, immediately after the SET BUFFER
instruction. Do NOT insert it within a procedure, as it will not work.

Why?

The compiler explore a source code from the beginning to the end,
sequentially. To be fast, the AMOS compiler is a one-pass compiler.
It means it actually creates the code during the source exploration.
If the compiler encounters a =VAL() function in the code, without
being aware of the presence of floating points in the program (without
having encountered a floating point number before VAL() ) then it
will create integer only code. And an integer value used as a float
number gives really weird negative numbers.

That's why you must tell the compiler first "Watch out : I will use floats
in this program!


  Global variables.
  -----------------
Another side effect of the one-pass technique can affect GLOBAL variables.
The side effects can generate bizarre values as with VAL() above, or even
a crash with strings.

It appears when you make a variable global AFTER you've assigned a value to it.
Example of bad code:

A=5
Global A

This worked under AMOS, as the verification process is two passes. It does not
work under the compiler. So the above code should read:

Global A
A=5

Remember : always make your variable or arrays global BEFORE assigning ANY
values to them.
The best solution is to always group your global variables in the first lines
of your program, and not to spread them all around your code. Example:

'----------------------------------------------
' Title
'----------------------------------------------
Set Buffer 20
'
' If needed, to tell the compiler about floats
A#=0.0
'
' Now, we dimension the arrays
Dim A$(10),B$(15)
'
' Now we define global variables
Global A$(),B$(),E,F#
'
' And ONLY now, can we assign values...
A$(0)="This is good programming!"
B$(15)="Sure it is."


  Extension not loaded when compiling.
  ------------------------------------
This annoying message sometimes appears when you compile programs that uses
special extensions, like AMOS 3D, TOME, CTEXT, DUMP etc...

The first thing to do is to check that the extension is correctly installed
on your system. Load your normal AMOS, load the faulty program, and TEST it.
You should not be reported any errors.
If you have, then you should first install the extension, if you have it!
Extensions are usually furnished with an install program. This program
will save out the extension into your AMOS_System folder.

To finish the installation, you should load the CONFIG1_3.AMOS program
under your normal AMOS, then choose "Load Default Configuration", and
type the name of the extension at the correct position in the extension list.
Then save your extension.

DO NOT STOP HERE : Now choose "Load Other Configuration" and choose the
file called RAMOS1_3.ENV in your AMOS folder. This configuration file
is the one used by the compiler. Here too you must enter the name of the
new extension in the extension list. If you don't, the compiler will not be
aware of the presence of the new extension, and will report an "Extension
not Loaded" error when compiling.

The compiler uses RAMOS1_3.Env when you compile a program with "No Errors"
set in the Compiler options menu.


  Size of the program.
  --------------------
Your program was compiling fine, and now the compiler crashes when
compiling. Or the compiled code crashes.
Your program is quite big (60k of CODE, means you need a 60k editor
buffer to hold it).

The compiler default setup is tuned to work with programs up to 70-80k of
code. To run faster, the compiler does not check overwriting its buffers. So
if your program is too big, then it simply writs into non-reserved memory.
This can cause an immediate crash, a late crash (surprise, surprise), or a
strange object code.

You should run the program called:

    Compile_Large_Programs.AMOS

This program can be found on your updated AMOS_Compiler disc. It will alter
the compiler configuration so that the compiler can cope with bigger AMOS
creations.

The altered configuration file will allow you to compile programs as large
as 160K of code (which is REALLY enormous).

If you are a hard-worker, and your program reaches this size, then
you should use a text editor to modify the "compiler_configuration" file
in your AMOS system. This file is in plain ascii text, and gives a full
explanation about the process.
At the same time, you can have fun personalising your AMOS Compiler messages.


  Memory problems.
  ----------------
Your compiled program runs nicely during a certain amount of time, then
it returns to Workbench. If you compile with error messages, you get a
"Out Of Memory" error. If, in your program you display the amount of
free memory, you get quite a high value, like 30k.

Unfortunately, a real out of memory has occurred, there is nothing
that can be done about it.
The memory of your Amiga, is like a piece of Swiss cheese. each time
a program wants some memory, the system creates a hole in the cheese.
The whole of memory consists of free, then reserved, then free, then
reserved, chunk of bytes.
When you boot your machine, everything is tidy. All the reserved memory
lies in the bottom of the memory map, and the free areas in the top.
But your program will reserve, and free more and more memory when it is
running. It will then free small parts in the bottom. After a while, the
number of small parts (from 8 bytes to a couple of k) increase considerably.
If you want, say a 60k bank, the system cannot use all these small parts
of free memory in the bottom. Even a 50k chunk is not enough.

There is NOTHING we can do to prevent it. That's the way it goes with a
multitask machine. We can only give you tricks to avoid problems:

* Always leave a reasonable amount of free mem. 50k should be the minimum. It
  is not safe to run a program on an Amiga with less than 20k. It can crash
  at any moment.

* If you need big chunks of memory, reserve them once and for all at the
  beginning of your program.

* The same applies to screens. Try, as far as possible, to open all screens
  at the beginning, and keep them opened. Hide them if needed.


  Chaining compiled programs problem.
  ------------------------------------
If you've written two AMOS programs and want to make the first one load and
run the second you may find that, although the two programs run OK separately,
the second one just refuses to be launched by the first.

This problem also comes from memory limitations. When you run a second program
from a first one, there is a moment when the following occupies memory at the
same time:

    1 The first program code and screens.
    2 The second program being loaded.

Although we have made it as clever as possible, during a small moment,
running a second program from a first, AMOS will ask for more memory than
the biggest of the two programs. Not very much more (around 50k).

You can though, do something to avoid this problem. Since the display screens
are directly transferred from one program to another, nothing is erased in
display memory. So you can remove the following items before chaining:

    * Erase all opened screens.
    * Erase any bob banks.
    * Clear blocks out.
    * Set the sprite buffer to only 16 lines.

This way you reduce the size of remaining reserved memory during the load.

The problem can also be caused by the "memory problem" we have just
seen before. If the first program created a lot of garbage in memory, and if
the second is very big, then it might not be possible to reserve a chunk of
continuous memory big enough to load the code.

To prevent this further you could cut down each program's code into smaller
sections which chain each other.


Quick AMOS_Compiler problem reference (Problem, Solution):
--------------------------------------------------------------------------

P: The floating point numbers give odd results once compiled.
S: Insert A#=0.0 at the top of your program.

P: My compiled program holds odd values in global variables.
S: Remove all assignments to variables before turning them into global.

P: My compiler crashes.
S: The program is too large, run "Compile_Large_Programs.AMOS"

P: My compiled program crashes.
S: If the program is large, run "Compile_Large_Programs.AMOS"
S: Remove all assignments to string variables or arrays before turning them
   into global.

P: I get an Extension not loaded error when compiling, but it worked
   fine under AMOS.
S: Install the extension name into RAMOS1_3.ENV configuration file.

P: My compiled program returns to Workbench.
S: In most cases your program is failing to find a file. First compile your
   program with error messages. Then try it from an OPENED CLI, or from
   the Workbench. An error message will then be returned. Make sure you
   are in the correct directory and that you have copied all the files.
S: If you compile your program with the "CLI Programs to run in the
   background" option selected, then the default directory upon booting
   will be "SYS:", and NOT the directory you booted from.

P: I have created a bootable disc but the program returns to Workbench.
S: If you try your compiled program on a bootable disc, the RAM DISC will
   not be created as it may be under your normal AMOS interpreter. If your
   compiled program access the ram disc it will simply create an error
   and escape out. Make sure the system configuration is exactly the same
   when you run your compiled program.
S: You program could not load the disc fonts, or the disc font library.
   Copy the Font: folders and the Libs:Discfont.library onto your bootable
   disc. Have a look at the next chapter, "How to create a bootable
   disc".




How to create a bootable disc, simply.
----------------------------------------------------------------------

Your program is now ready, you want to create a bootable disc. Here is
a simple and reliable way to proceed.

* Do a DISK-COPY of your AMOS Basic Programs disc

* With a disc editor, delete ALL the files and folders, except for the
  following directories:

    C
    L
    Devs
    S
    Libs

This way, you have a blank disc, with all system file correctly installed,
and with a proper startup-sequence.

* Now compile your program and save it with the name : "AMOS1.3" on this
  disc. It will run automatically when booted. Clever isn't it?



Major problems corrected in V1.12 from V1.1.
----------------------------------------------------------------------------

* For / Next loops in a sub-routine do not mess other For / Next loops
  up.

* Title Bottom compiles.

* Priority ON / OFF compiles.

* HAM interlaced screens can now be opened.

* =PORT() used to wait for characters.

* Compiler.AMOS now works fine with CLI programs.

* Compiler shell skips sub-directories in AMOS_System folder.


The future of AMOS Compiler.
----------------------------------------------------------------------------

The AMOS Compiler will constantly be updated so that it keeps up-to-date with
new trends on the Amiga scene. For the latest AMOS update information
contact Sandra Sharkey of the AMOS PD. Library: 25 Park Road, Wigan, WN6
7AA, England. Telephone 10am to 3pm on [phone].