#Floating Point
26 messages in this thread
Mike, using Manx V5.0, I'm having trouble with the -f8/-lm8 compile/link
option. Programs that work fine using -ff/-lmf and -fa/-lma won't work
right when I try to use my 68881. Adding the -c2 and -mcd options and the
appropriate "l" linker options doesn't change the result. Am I doing
something dumb?
As best I can isolate my -f8/-lm8 problem, the trouble seems to be
truncated input of floats and doubles using scanf(). Rob.
I'm experiencing trouble with floats also. Prototypes don't always work
with floats. Constants are sometimes coerced to char in the presence of
prototypes. I finally gave up and am using double. This is working (for
now).
Thre's some iscussion of SIZEOF in the disk1 read.me; did you look there? I
switched all my floats to doubles and still no luck. The docs warn that
floats don't work right with the ma.lib, except my stuff does work right
using that lib…..(patiently waiting for MikeS)…Rob.
No, didn't read that particular read.me file. Too bad about doubles. It
seems that 5.0a may be buggy for awhile; too many changes have occurred –
default int sizes have switched and now the compiler is "ANSI conformant".
I just wish the 5.0a release was a bit more stable. I'm getting tired of
tracking down compiler bugs – I've enough bugs of my own to worry about
:-). Oh well.
Conversion of floats to doubles is not highly accurate, due to an apparent
problem w/ an Amiga resident library routine. Since most people use
doubles, this hasn't affected too much code. In the next release we're
using our own routine to do the conversion, and that seems to work OK.
"prototypes don't work with floats" Could you expand upon this? "constants
are sometimes coerced to char in the presence of prototypes" this too? It
sounds like you may have K&R style functions w/ function prototypes. If
this is the case, then you should read page 3-9 in the reference manual
(that's in the Language Specification chapter). It talks about how
prototypes and K&R/ANSI style functions interact.
I'll re-read the relevant information Mike. However, K&R/ANSI function
mixing should *NOT* result in code generation errors of the type I'm
encountering. Yes, yes – examples will follow :-).
Yes, mixing K&R-style w/ ANSI prototypes can get you in a _heap_ of
trouble, since K&R functions do promotions of chars and floats where as
ANSI functions do not.
The following examples illustrate some of the bugs I've encountered with
5.0a to date.
Bug 1: 5.0a treats 0.0 as a char in the presence of float prototypes.
Example:
void foo( float null ) { }
main(void) {
foo( 0.0 ) ; }
Aztec C Version 5.0a Jan 9 1990 7:57:19
Copyright 1989 by Manx Software Systems, Inc.
clr.s -(sp)
^ File TMPA341.TMP; Line 16 # Opcode extension size
did not match. 1 errors
Bug 2: Prototypes are not generated correctly for functions taking array,
or pointer to array arguments.
Example:
void foo1( char (*array)[3][2] ) { }
void foo2(array) char (*array)[3][2] ; { }
The above program, test.c, when compiled with -qp produces:
void foo1(char array[2][3]*); void foo2(char array[2][3]*);
Bug 3 (example superfluous): -wq logs only the first 25 (approximately)
errors to AztecC.err. Additional errors are not logged, even when -ww is
used.
Tracking down these bugs takes time. Reporting the bugs in a general sense
is much easier. In this spirit I've encountered the following additional
bug.
Bug 4 (sans example): _stkchk (via the -bd option) will occasionally
corrupt the instruction immediately following its invocation (i.e.
immediately following jsr __stkchk).
Bug 5 (suspected, but not confirmed): sizeof(int) may not be working
correctly. I *suspect* that sizeof(int) does not know whether 16 bit or 32
bit ints are being used, although I *have not* confirmed this. I rewrote
the code using sizeof() and my problem disappeared.
Mike, please keep me informed of the progress in correcting the
above-mentioned bugs. In the past, compiler upgrades have been
clandestine. Not once was I notified of an upgrade or a bug fix.
In addition to these bugs, I have noticed that SDB bogs down when
displaying source from lengthy source modules. SDB is a pain to use when
working on modules longer than about 1000 lines of code.
Forgive me if I seem blunt in my criticism of 5.0a. I realize that much
has changed since 3.6 and that errors can be expected. If Manx supports
5.0a with courtesy, and corrects bugs promptly – if it offers
I certainly hope they've fixed the problems with SDB and FFP floats, too. I
called in my update yesterday, and hope I don't get stung like I did on SDB
the first time.
We now provide two versions of SDB in 5.0a. One version for programs which
use the 68881 or normal emulation, and another which debugs programs which
use FFP.
Me too :-). SDB is still very slow when displaying source from lengthy
source modules though. Oh well.
Lengthy source modules? I don't let mine get longer than 150 lines or so.
🙂 Another programmer error, perhaps? 40K source files are evidence of
lazy programming.
Aw, come on John. My modules are organized by topic. The current program
I'm working on currently has 8 modules, and 3 header files. I comment my
source code liberally, so not withstanding the division of source among
several modules, it is not uncommon to see a couple 1000+ line files.
Granted that half the stuff in a module is probably comment statements.
Nonetheless, why does SDB bog down in long source modules? Lattice's CPR
doesn't. None of my text editors do. I mention the problem in hopes that
Manx will remove this defect from SDB.
Topic? Your program only has 8 topics? what's so bad about breaking down
the topics even further, until there's 3-4 related (*closely* related)
functions in one file? I'd bet you'd save tons of time in compiles.
Parsing comments and whitespace is one of the most time-consuming parts of
a compile. Shorter modules would save development time.
Perhaps you're right John. However, by the time a big project gets done,
you'd probably (at least I would) end up with 20+ modules. How would you
ever find anything?
I guess this represents a matter of coding style. I like fewer source
modules with rather broad topical content. Using this strategy, I have no
trouble figuring out which module a particular function is in. This is the
way I personally code. In my opinion, Manx's SDB should accomodate my
style, especially since I'm unlikely to be the only programmer with lengthy
source modules.
I also code lengthy source modules. Lattices CPR handles them fine.
I *just* knew I was not alone :-). Ben, did you just recently take up am.
radio?
Yes, you could easily end up with 20+ modules. How would you find
anything? Good filenames help, plus programmer's tools like ctags and the
rather good cross-reference database program in the PD for the Amiga, which
revolves around 'mkid' and 'lid'. Seems to me that complaining about
slowness because a file is long is misplaced criticism… what program
doesn't take longer to process, when given more data? The usual answer is,
get an 030, or shorter the file. 🙂 I'm sure SDB could be optimized to
help you, but I have no sympathy. I think there's only one reason people
use big modules, and that's to rely on lazy global variables. Why waste
time recompiling all the other functions within the file, if you're only
changing one thing at a time? Slowness in SDB is bad, but wasted time in
compiles is OK? (And in case you wondered, I get evangelical about C
indentation style, too. 🙂
Ah, but I do have a rather fast (2500) Amiga. And my compile times aren't
long. For this reason, I see absolutely no reason to code using
multitudinous source modules. I take it as an affront that SDB does not
support my personal preference for coding. Should I change my ways just
because the source level debugger I'm stuck with cannot render code to the
screen in a reasonable time frame? I think not.
As for ease of tracking down modules, it is obvious that the ability to
locate particular functions degrades in direct proportion to the number of
modules you have. You state that utilities exist to help you find your
needle among the haystack. But I wonder, does it take more time to hunt
down the function of interest and then make changes and recompile than it
does to immediately go to the function make changes and then compiler a
somewhat longer module? I suspect that the time differential is small, and
may even be in favor of coding lengthy modules.
And if you disagree with me in the slightest, perhaps I'll pull out my
trusty sword,
** > S T O R M B R I N G E R < ***
:-). (this last bit always resolves arguments in my favor).
Actually, if you take breaking code into modules to it's logical conclusion
(ie, one function to a module…), then finding your functions becomes the
easiest thing in the world. Just name each module after the function it
performs. Same thing applies to closely tied functions. (Like, I might
put the functions get_record(), find_record(), and set_record() in a single
module called RECORD.C — It's pretty obvious where the functions are
at…) However, as I mentioned in an earlier reply, if you're the only one
who will ever have to deal with the code, do it whatever way suits. But
only if you are certain nobody else will need to work with it.
Lets hear it for C Indentation style!!! (I'm evangelical about it too, and
I most assuredly do NOT use the typical K&R style. Mine was introduced by
Whitesmiths way back in 1980 or so…) When you are programming for
yourself, you can code however makes you comfortable. But when you do
consulting work, it's always a good idea to code with other people in
mind. This means a consistant coding style, formatting style, commenting
style, and other style guidelines. I prefer short modules containing
closely related functions for my professional work, and if I've gone over
500 lines with more than 2 functions, it's way past time to split it up. A
typical large project for me is 50 to 100 modules, further grouped into
several well defined libraries. A small project is usually 8 to 10
modules. While at first glance one might think that large projects are way
too spread out to handle, but actually I've found that breaking things up
this way tends to make it much easier to debug, test, and maintain a
program, as you rarely have to deal with more than a small piece at a
time.
There aren't any known problems w/ -f8. Could you show a code sample that
breaks?
Mike, here's some code that works with -ff/-lmf and doesn't with -f8/-lm8:
#include <stdio.h>
main()
{ float number;
scanf("%f", &number);
printf("%f", number);
}
Pretty basic, huh? I tried compiling with "cc -f8 test.c" and linking with
"ln test.o -lm8 -lc". Adding -c2 to the compile line seems not to matter. I
also tried variations with the -mcd and -lm8l options. BTW, I *DO* have a
68020/68881 board installed.
Could you tell me what I'm looking for when I compile this? Saying it
"doesn't work" is kind of vague. Does it crash? Give you a wrong value?
Not link? Not compile? Is it printf that's not working? Is it scanf()
that's not working?
I think it's scanf() that's not working. When I used SDB the stored value
of the float showed only the last digit entered from the keyboard. That is,
the entry 144.55 would show only as integer 5. Thanks for your help. Rob.