Mercurial > hg > audiostuff
comparison intercom/gsm/changes @ 2:13be24d74cd2
import intercom-0.4.1
author | Peter Meerwald <pmeerw@cosy.sbg.ac.at> |
---|---|
date | Fri, 25 Jun 2010 09:57:52 +0200 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
1:9cadc470e3da | 2:13be24d74cd2 |
---|---|
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 |