|
2
|
1 File "changes"
|
|
|
2 ~~~~~~~~~~~~~~
|
|
|
3
|
|
|
4 LOG of the changes introduced by Simao and summary of results.
|
|
|
5
|
|
|
6 1. first of all, file names had to fit in DOS limitations. Some names had
|
|
|
7 to be truncated, and the mapping is as follows:
|
|
|
8 gsm_create.c -> gsm_crea.c
|
|
|
9 gsm_decode.c -> gsm_deco.c
|
|
|
10 gsm_destroy.c -> gsm_dest.c
|
|
|
11 gsm_encode.c -> gsm_enco.c
|
|
|
12 gsm_explode.c -> gsm_expl.c
|
|
|
13 gsm_implode.c -> gsm_impl.c
|
|
|
14 gsm_option.c -> gsm_opti.c
|
|
|
15 gsm_print.c -> gsm_prin.c
|
|
|
16 long_term.c -> long_ter.c
|
|
|
17 preprocess.c -> preproce.c
|
|
|
18 short_term.c -> short_te.c
|
|
|
19
|
|
|
20 2. gsm.h had added prototypes for all the existing functions
|
|
|
21
|
|
|
22 3. add.c had to be changed to make add_test.c work
|
|
|
23
|
|
|
24 4. private.h had to be changed to use either true-function or the safe
|
|
|
25 pseudo-functions for the GSM_... macros. This was the main reason for
|
|
|
26 the errors that were happening.
|
|
|
27
|
|
|
28 5. undefs were preceeded by a check of their definition to avoid some
|
|
|
29 complaints from VAX-C
|
|
|
30
|
|
|
31 6. rpe.c had to be changed in a strange hacked "switch" by its "normal"
|
|
|
32 implementation for VMS (compilation error!) - the code is as it was
|
|
|
33 in comments.
|
|
|
34
|
|
|
35 7. To keep compatibility, the change in patch 3 to rpe.c
|
|
|
36 shall not be
|
|
|
37 #define STEP( i, H ) (e[ k + i ] * (long)H)
|
|
|
38 but
|
|
|
39 #define STEP( i, H ) (e[ k + i ] * (longword)H)
|
|
|
40
|
|
|
41 8. long_term.c (now long_ter.c) had to have added some castings, such
|
|
|
42 as:
|
|
|
43 temp = gsm_norm( (longword)dmax << 16 );
|
|
|
44 ^^^^^^^^^^
|
|
|
45 because gsm_norm uses longs and dmax is short: (short)<<16 = 0 always!
|
|
|
46 Also, if MSDOS/__MSDOS__ is defined, then USE_TABLE_MUL is
|
|
|
47 #undef'd (see tests below).
|
|
|
48
|
|
|
49 9. other small changes that I don't recall from my notes. These may include
|
|
|
50 type castings, and other changes done in the desperate search for the bugs.
|
|
|
51
|
|
|
52
|
|
|
53 Simplifications:
|
|
|
54 ~~~~~~~~~~~~~~~~
|
|
|
55
|
|
|
56 Since I don't want a compress-like utility, I haven't put my hands in toast.
|
|
|
57 To ease my work, I've put all src, inc and add-test in one single directory
|
|
|
58 and simplified the makefile. I also added labels "all", "rpedemo" and "clean",
|
|
|
59 "anyway".
|
|
|
60
|
|
|
61
|
|
|
62 Extensions:
|
|
|
63 ~~~~~~~~~~~
|
|
|
64
|
|
|
65 I added a DCL for compiling on VMS using either gcc or vax-c, depending on
|
|
|
66 the comments. I have also added a borland bcc make file for the pc, as well
|
|
|
67 as a gcc makefile for the pc.
|
|
|
68
|
|
|
69 Added a demo program and 2 driving routines (currently embedded in the demo
|
|
|
70 program). With them, interfacing with the test sequence file is
|
|
|
71 straight-forward.
|
|
|
72
|
|
|
73
|
|
|
74 Test results:
|
|
|
75 ~~~~~~~~~~~~~
|
|
|
76
|
|
|
77 the bcc-compiled version processed correctly all the 5 test vectors for
|
|
|
78 the following conditions:
|
|
|
79
|
|
|
80 (SASR always defined)
|
|
|
81
|
|
|
82 USE_FLOAT_MUL undefined
|
|
|
83 USE_FLOAT_MUL defined and FAST undefined
|
|
|
84 USE_FLOAT_MUL and FAST defined
|
|
|
85
|
|
|
86 bcc failed compilation when USE_FLOAT_MUL undefined and USE_TABLE_MUL defined
|
|
|
87 because the table matrix is greater than 64kbytes! (No way out!)
|
|
|
88
|
|
|
89 When compiled by bcc with both USE_FLOAT_MUL and FAST undefined, bcc
|
|
|
90 failed passing the test sequences.
|
|
|
91
|
|
|
92 Besides compilation worked for USE_FLOAT_MUL and FAST defined, in fact, all
|
|
|
93 the runs with the test sequences were made in the "compatible mode", i.e.,
|
|
|
94 with the state variable structure fuield "fast" always set as 0. Therefore,
|
|
|
95 it was not tested. Although, it is known from the original authors that
|
|
|
96 the fast mode does not work in Unix (32bit), hence it is very likely not
|
|
|
97 to work with DOS either!
|
|
|
98
|
|
|
99 NeedFunctionPrototypes was always defined for bcc, gcc, acc, and vax-c,
|
|
|
100 and undefined for unix cc.
|
|
|
101
|
|
|
102 Since gcc is the same implementation ported across platforms, it should
|
|
|
103 work as for SunOS, but it was not tested.
|
|
|
104
|
|
|
105 The program worked properly for the following environments (see summary below):
|
|
|
106 SunOS 4.3: cc, acc, gcc
|
|
|
107 MS/DOS: bcc, gcc (djcpp)
|
|
|
108 VAX/VMS: cc (Vax-c), gcc
|
|
|
109
|
|
|
110 Summary of the tests:
|
|
|
111 -------------------------------------------------------------------------
|
|
|
112 Environment Compiler Symbols defined (Note: SASR always def'd)
|
|
|
113 USE_FLOAT_MUL FAST USE_TABLE_MUL Worked?
|
|
|
114 -------------------------------------------------------------------------
|
|
|
115 SunOS 4.3: cc yes no - yes
|
|
|
116 yes yes - yes*
|
|
|
117 no - no yes
|
|
|
118 no - yes yes
|
|
|
119 acc same as for cc in SunOS 4.3 yes
|
|
|
120 gcc same as for cc in SunOS 4.3 yes
|
|
|
121 MS/DOS: bcc yes no - yes
|
|
|
122 yes yes - yes
|
|
|
123 no - no no
|
|
|
124 no - yes no
|
|
|
125 gcc Not tested other than yes/no/- yes
|
|
|
126 VAX/VMS: Vax-c same as for cc in SunOS 4.3 yes
|
|
|
127 gcc Not tested other than yes/no/- yes
|
|
|
128 -------------------------------------------------------------------------
|
|
|
129 * Note: all the runs were made in the compatible mode, therefore the
|
|
|
130 fast computation of the data was not performed!
|
|
|
131 -------------------------------------------------------------------------
|
|
|
132
|
|
|
133 Therefore, the safest approach is to compile always with USE_FLOAT_MUL
|
|
|
134 defined and with and FAST defined if appropriate for speed!
|
|
|
135
|
|
|
136 In Vax-C there were warnings relating to function names longer than 31
|
|
|
137 characters. No way to circumvent this, but it is not a problem because the
|
|
|
138 31 first letters generate unique names anyway. Because of this, link will
|
|
|
139 also complain!
|
|
|
140
|
|
|
141 The test sequence files had the byte order swaped in the Sun workstation
|
|
|
142 because of the Big Endian data orientation.
|
|
|
143
|
|
|
144 -- <simao@cpqd.ansp.br> -- 8/Apr/94
|
|
|
145
|
