32-bit IEEE float multiplication

[Andy]

Hi,
I don't know if this is the correct group to post this, but
when I multiply a huge floating point value by a really
small (non-zero) floating point value, I get 0 (zero) for the result.
This creates a big hole in a 32-bit timer routine I wrote.

Questions.
1. Why does this happen?
2. Is there C macros/functions I can call to tell me
when two non-zero numbers are multiplied and the
result will be zero?

TIA
Andy

[E. Robert Tisdale]

Andy wrote:

Dan.Pop wrote:

Sorry, but if you can't figure these things out yourself,
after all the advice you have received, you're in the wrong business.

Please stop wasting bandwidth with your senseless remarks.

I see that you've met some of our indigenous trolls.

Indigenous trolls live under bridges (usenet newsgroups)
and snack on unwary billy goats gruff (new subscribers).

http://www.surlalunefairytales.com/billygoats/

They try to provoke an emotional response from new subscribers
("get their goat" if you please ;-).
They may say nasty things about you, your intellect, your character
or even your mother that have nothing at all to do
with the topic of the comp.lang.c newsgroup.

The best way to deal with indigenous trolls is to ignore them.
Remember, if you respond, the troll wins. ;-)

[Dik T. Winter]

In article <ae*************************@posting.google.com> bi*****@hotmail.com (Andy) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<br**********@sunnews.cern.ch>...

Sorry, but if you can't figure these things out yourself, after all the
advice you have received, you're in the wrong business.

Please stop wasting bandwidth with your senseless remarks.
If I understand you correctly, I would compare to the microseconds
counter if I need milliseconds resolution and I would compare
to the milliseconds counter if I need seconds resolution? But
ideally, I'd want a single counter to compare against for all
my timing needs from milliseconds, to seconds, to days. I guess
I can put these two counters in a struct, but then I'd have
a 64-bit timing variable. Too wastful..

Yup, that is life. As it is not clear at all what you really want, you
should not expect the people here to give you a clear solution.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Richard Heathfield]

E. Robert Tisdale wrote:

Andy wrote:

Dan.Pop wrote:

Sorry, but if you can't figure these things out yourself,
after all the advice you have received, you're in the wrong business.
Please stop wasting bandwidth with your senseless remarks.

I see that you've met some of our indigenous trolls.

Oh, don't be so ridiculous. Dan Pop is no troll. This is a case of the pot
calling the rainbow black.
The best way to deal with indigenous trolls is to ignore them.
To the OP: Tisdale's advice here, for once, is correct (insofar as it
suggests that you ignore his own articles). His advice is rarely topical
and rarely correct, so there's no point reading his stuff anyway.

Remember, if you respond, the troll wins. ;-)

No. This is a newsgroup, not a game. Where trolls like Tisdale are
concerned, nobody wins.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Dan Pop]

In <ae*************************@posting.google.com> bi*****@hotmail.com (Andy) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<br**********@sunnews.cern.ch>...

Sorry, but if you can't figure these things out yourself, after all the
advice you have received, you're in the wrong business.
Please stop wasting bandwidth with your senseless remarks.

My remarks were far from senseless. They actually provided you with the
best solution for your problem. But if this is how you understand to say
"thank you", I may choose other ways of spending my time.
If I understand you correctly, I would compare to the microseconds
counter if I need milliseconds resolution and I would compare
to the milliseconds counter if I need seconds resolution? But
ideally, I'd want a single counter to compare against for all
my timing needs from milliseconds, to seconds, to days.
For an embedded control problem, the ideal solution is the one that
gets the job done in a minimum of CPU cycles and a minimum of program
memory bytes, not the one that minimizes the number of counters.
If you haven't understood that by now, reread my remark quoted at
the begining of this post.
I guess
I can put these two counters in a struct, but then I'd have
a 64-bit timing variable. Too wastful..

You need a 16-bit counter for microseconds, a 16-bit counter for
milliseconds and a 32-bit counter for seconds. There are only a few bits
wasted in the first two counters (which only use 10 bits out of 16).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Andy]

Da*****@cern.ch (Dan Pop) wrote in message >

You need a 16-bit counter for microseconds, a 16-bit counter for
milliseconds and a 32-bit counter for seconds. There are only a few bits
wasted in the first two counters (which only use 10 bits out of 16).

Dan

After some soul searching, I've come up with this new clock
module (it only works for big-endian machines)
/* 4 millisecond increments */
#define GCLK_INC ((unsigned short)((double)(4.0) *
((double)65536.0/1000.0)) + 0.5)

/* use this type in your code */
typedef unsigned long GCLK_T;

/* Do not use this type in your code. It's only used internally in
gclk.c */
typedef union {
struct {
unsigned long secs;
unsigned short fractSecs; /* 1/65536 second */
} inc;
struct {
unsigned char unused;
GCLK_T ticks; /* upper 3 bytes are seconds. lower
byte 1/256 seconds */
} gclk;
} GCLK_LOW_LEVEL_T;

GCLK_LOW_LEVEL_T gcGClk;

#define GCLKIsr() do { \
gzGClk.inc.fractSecs += GCLK_INC; \
if (gzGClk.inc.fractSecs < GCLK_INC) { \
++gzGClk.inc.secs; \
} \
} while(0)

And everybody compares to gzGClk.gclk.ticks for time
references. that gives 24-bit seconds and 8-bit 1/65536 seconds.
This should work much better now. No? And the time measurement
should be linear up to overflow (in 198 days).

Andy