File "changes"
~~~~~~~~~~~~~~

LOG of the changes introduced by Simao and summary of results.

1. first of all, file names had to fit in DOS limitations. Some names had
   to be truncated, and the mapping is as follows:
	gsm_create.c    -> gsm_crea.c
	gsm_decode.c    -> gsm_deco.c
	gsm_destroy.c   -> gsm_dest.c
	gsm_encode.c    -> gsm_enco.c
	gsm_explode.c   -> gsm_expl.c
	gsm_implode.c   -> gsm_impl.c
	gsm_option.c    -> gsm_opti.c
	gsm_print.c     -> gsm_prin.c
	long_term.c     -> long_ter.c
	preprocess.c    -> preproce.c
	short_term.c    -> short_te.c

2. gsm.h had added prototypes for all the existing functions

3. add.c had to be changed to make add_test.c work

4. private.h had to be changed to use either true-function or the safe
   pseudo-functions for the GSM_... macros. This was the main reason for
   the errors that were happening.
   
5. undefs were preceeded by a check of their definition to avoid some
   complaints from VAX-C
   
6. rpe.c had to be changed in a strange hacked "switch" by its "normal"
   implementation for VMS (compilation error!) -  the code is as it was
   in comments. 
   
7. To keep compatibility, the change in patch 3 to rpe.c 
   shall not be 
   #define STEP( i, H )    (e[ k + i ] * (long)H)
   but
   #define STEP( i, H )    (e[ k + i ] * (longword)H)

8. long_term.c (now long_ter.c) had to have added some castings, such 
   as:
      temp = gsm_norm( (longword)dmax << 16 );
                       ^^^^^^^^^^
   because gsm_norm uses longs and dmax is short: (short)<<16 = 0 always!
   Also, if MSDOS/__MSDOS__ is defined, then USE_TABLE_MUL is 
   #undef'd (see tests below).

9. other small changes that I don't recall from my notes. These may include
   type castings, and other changes done in the desperate search for the bugs.

   
Simplifications:
~~~~~~~~~~~~~~~~

Since I don't want a compress-like utility, I haven't put my hands in toast.
To ease my work, I've put all src, inc and add-test in one single directory
and simplified the makefile. I also added labels "all", "rpedemo" and "clean",
"anyway".


Extensions:
~~~~~~~~~~~

I added a DCL for compiling on VMS using either gcc or vax-c, depending on
the comments. I have also added a borland bcc make file for the pc, as well 
as a gcc makefile for the pc.

Added a demo program and 2 driving routines (currently embedded in the demo 
program). With them, interfacing with the test sequence file is 
straight-forward.


Test results:
~~~~~~~~~~~~~

the bcc-compiled version processed correctly all the 5 test vectors for
the following conditions:

(SASR always defined)

USE_FLOAT_MUL undefined
USE_FLOAT_MUL defined and FAST undefined
USE_FLOAT_MUL and FAST defined

bcc failed compilation when USE_FLOAT_MUL undefined and USE_TABLE_MUL defined 
because the table matrix is greater than 64kbytes! (No way out!)

When compiled by bcc with both USE_FLOAT_MUL and FAST undefined, bcc
failed passing the test sequences. 

Besides compilation worked for USE_FLOAT_MUL and FAST defined, in fact, all
the runs with the test sequences were made in the "compatible mode", i.e.,
with the state variable structure fuield "fast" always set as 0. Therefore,
it was not tested. Although, it is known from the original authors that
the fast mode does not work in Unix (32bit), hence it is very likely not
to work with DOS either!

NeedFunctionPrototypes was always defined for bcc, gcc, acc, and vax-c, 
and undefined for unix cc.

Since gcc is the same implementation ported across platforms, it should 
work as for SunOS, but it was not tested.

The program worked properly for the following environments (see summary below):
SunOS 4.3:	cc, acc, gcc	
MS/DOS: 	bcc, gcc (djcpp)
VAX/VMS: 	cc (Vax-c), gcc

Summary of the tests:
-------------------------------------------------------------------------
Environment	Compiler    Symbols defined (Note: SASR always def'd)
			USE_FLOAT_MUL	FAST	USE_TABLE_MUL  Worked?
-------------------------------------------------------------------------
SunOS 4.3:	cc	yes		no	-		yes
			yes		yes	-		yes*
			no		-	no		yes
			no		-	yes		yes
		acc	same as for cc in SunOS 4.3		yes
		gcc	same as for cc in SunOS 4.3		yes
MS/DOS: 	bcc	yes		no	-		yes
			yes		yes	-		yes
			no		-	no		no
			no		-	yes		no
		gcc	Not tested other than yes/no/-		yes
VAX/VMS: 	Vax-c	same as for cc in SunOS 4.3		yes
		gcc	Not tested other than yes/no/-		yes
-------------------------------------------------------------------------
* Note: all the runs were made in the compatible mode, therefore the
        fast computation of the data was not performed!
-------------------------------------------------------------------------

Therefore, the safest approach is to compile always with USE_FLOAT_MUL
defined and with and FAST defined if appropriate for speed! 

In Vax-C there were warnings relating to function names longer than 31 
characters. No way to circumvent this, but it is not a problem because the
31 first letters generate unique names anyway. Because of this, link will 
also complain!

The test sequence files had the byte order swaped in the Sun workstation
because of the Big Endian data orientation.

-- <simao@cpqd.ansp.br> -- 8/Apr/94