Can inclusion of a printf() effect a calculation? Please help!!

[Ben Bacarisse]

Thanks everyone for your comments. Here is some code that tries to
explain the problem?

Sorry to join in the throng, but the problem was clear. The request
for real code was so that people here might have a stab at determining
the cause. The sketch below has too many gaps to help identify any
cause. One thing stands out for me, though...

somefloatVal = Method2(MyArray1[Att], MyArray2[Att]);

if (somefloatVal == someothervale)
{
//do something
}

What type is "someothervale" [sic]? If it, too, is a floating type,
you have a serious problem. Testing floating-point values for
equality is almost always wrong. This program can print "what?" (in
fact it almost always will!):

int main(void)
{
float a = 7.0/3;
if (a == 7.0/3)
puts("OK");
else puts("what?");
return 0;
}

 

[Guest]

No, I was unfortunately a bit too late for that;-)

reading was actually destructive, but the hardware usually
automatically wrote back whatever it had read so logically
the program saw well behaved memory.

Dynamic RAM forgets its contents even if you don't read it!
It has to be constantly refreshed.

 

[JosephKK]

Core store normally had several available cycles. One was
read/restore. Another was read and leave zeroed (preparatory for
write). A third was write to zeroed location. These covered the
requirements.

While on some core memory machines, that set of cycles may have
existed, i have not worked on any of them. Machines (core memory)
that i have worked on had read(implicit restore), and (implicit
zero)write cycles, and some had read then write(something else) cycles
{these read/alter/write cycles required two data transfers}.

That said; in the early PC(/XT) days, the refresh counter and the
whole DRAM controller were implemented in TTL. DRAM was not so much
destructive readout but decaying charge value retention that required
refreshing (rewriting) every so often to retain data reliably.
.

 

[CBFalconer]

.... snip ...


While on some core memory machines, that set of cycles may have
existed, i have not worked on any of them. Machines (core memory)
that i have worked on had read(implicit restore), and (implicit
zero)write cycles, and some had read then write(something else)
cycles {these read/alter/write cycles required two data transfers}.

You couldn't do that. One requirement for a write is to first
clear the various core bits, and that requires a read. You don't
have to keep the read value. read/alter/write is a minor
modification of read/write. The slow thing is the core operation,
and other processing is negligible.

 

[JosephKK]

You couldn't do that. One requirement for a write is to first
clear the various core bits, and that requires a read. You don't
have to keep the read value. read/alter/write is a minor
modification of read/write. The slow thing is the core operation,
and other processing is negligible.

Are you asking to dispute the design detials of machines i worked on
that you may not have worked on? Would you like to discuss the
excitation levels, timings, circuit enables, interface transfers and
other details?
.

 

[CBFalconer]

.... snip ...


Are you asking to dispute the design detials of machines i worked
on that you may not have worked on? Would you like to discuss the
excitation levels, timings, circuit enables, interface transfers
and other details?

I'm not sure where the disagreement arises, but I am sure that to
write a value into core you first had to reset those bits, and that
that requires a read. The difference between read and write is the
direction of current flow in the drive wires. A memory with more
than one bit per word requires a suppress line, which may even use
the sense line.

 

[Keith Thompson]

I'm not sure where the disagreement arises, but I am sure that to
write a value into core you first had to reset those bits, and that
that requires a read.

[...]

No, that won't work.

After all, it's not even mentioned by the C standard. Therefore it
won't work.

Do you see the problem?

 

[Old Wolf]

Anyone herd of this before

        I am debuging a pre 99 C program. However I have noticed that when I
include some printf() statements (in order to see some float
variables) I get a different type of net answer than when I did not
insert the printf() statements.

This is known as a "Heisenbug".

 

[CBFalconer]

.... snip ...

I'm not sure where the disagreement arises, but I am sure that to
write a value into core you first had to reset those bits, and that
that requires a read.

[...]

No, that won't work.

After all, it's not even mentioned by the C standard. Therefore
it won't work.

Do you see the problem?

Yup. I was thoroughly off-topic. Bad. Sorry.

 

[Keith Thompson]

... snip ...

I'm not sure where the disagreement arises, but I am sure that to
write a value into core you first had to reset those bits, and that
that requires a read.

[...]

No, that won't work.

After all, it's not even mentioned by the C standard. Therefore
it won't work.

Do you see the problem?

Yup. I was thoroughly off-topic. Bad. Sorry.

Yes, you were off-topic. Nevertheless, my remark that "No, that won't
work.", if I had meant it seriously, would have been factually
incorrect and inappropriate. *That's* the point I've been trying to
make.

 

[Kenny McCormack]

Lovebirds Keith Thompson <[email protected]> & CBFalconer <[email protected]> went at it in their usual way:

.... (You've seen it before, you'll see it again, no need to repeat it here)

You guys are insane. I wish you could read your own posts as others do.

Indeed. A little while ago, I suggested that Keith try to step back
just a little, and see his posts as an adult would. It would help him a
lot.

 

[Old Wolf]

Indeed.  A little while ago, I suggested that Keith try to step back
just a little, and see his posts as an adult would.  It would help him a
lot.

Usenet needs the feature suggested in http://xkcd.com/481/ .

 

[Default User]

Usenet needs the feature suggested in http://xkcd.com/481/ .

Remember to hover the mouse over the comic.



Brian

 

[James Dow Allen]

While on some core memory machines, that set of cycles may have
existed, i have not worked on any of them. Machines (core memory)
that i have worked on had read(implicit restore), and (implicit
zero)write cycles, and some had read then write(something else) cycles
{these read/alter/write cycles required two data transfers}.

That said; in the early PC(/XT) days, the refresh counter and the
whole DRAM controller were implemented in TTL. DRAM was not so much
destructive readout but decaying charge value retention that required
refreshing (rewriting) every so often to retain data reliably.

Don't know about present-day but *most* Japanese DRAM's in mid-70's
took a minute or so to lose their data, though they were spec'ed
at 2 or 4 msecs, IIRC.

But many seem to overlook that DRAMs are like core in that readout
is destructive! Every read had to be followed by a write, though
it would be transparent beyond the board or even chip level.

BTW, thanks to poster who gave the link
http://xkcd.com/481/
It is indeed appropriate here!
(and I spent a few enjoyable moments clicking
"Get another Random comic")

James

 

[CBFalconer]

CBFalconer said:
.... snip ...


Since you seem to equate "off-topic" with "doesn't work", bear in
mind that by your own definition your nmalloc package doesn't work.

And I don't advertise it as 'working everywhere'. It is for DJGPP,
and is fairly easily adapted for many other systems. Since you
have to inject your nonsense everywhere, I have to occasionally
deny your silly accusations.

 

[Kenny McCormack]

== doesn't work in your own words you silly, foolish, big headed fool.

It really is funny watching the whole thing implode on top of them.

It's like watching Christianity implode - which I think has indeed
happened in the 20th Century. After ruling the roost for so long, the
leaders of Christianity are now seeing their pack of lies implode upon
them.

I think it is pretty well dead among the young in mainstream America.
They say the only thing that keeps it going at all is immigration.

Sorta like the only thing that keeps this newsgroup going is the endless
stream of newbies (from the same places as we get our new Xtians...).

 

[JosephKK]

I'm not sure where the disagreement arises, but I am sure that to
write a value into core you first had to reset those bits, and that
that requires a read. The difference between read and write is the
direction of current flow in the drive wires. A memory with more
than one bit per word requires a suppress line, which may even use
the sense line.

It is really simple. I stated properties (of core memory) of systems
that i actually worked on. You said that they did not work the way
that they actually did. Nor did i say that the cycle set you
discussed would not work, it will. Your proposal is not the cycle set
implemented on the real machines that i have worked on.
.

 

[JosephKK]

Don't know about present-day but *most* Japanese DRAM's in mid-70's
took a minute or so to lose their data, though they were spec'ed
at 2 or 4 msecs, IIRC.

But many seem to overlook that DRAMs are like core in that readout
is destructive! Every read had to be followed by a write, though
it would be transparent beyond the board or even chip level.

BTW, thanks to poster who gave the link
http://xkcd.com/481/
It is indeed appropriate here!
(and I spent a few enjoyable moments clicking
"Get another Random comic")

James

No it is not actually destructive read out. Data is retained by
charge storage, which leaks, thus the need for re-writes. At about
one per thousand reads. To fair though, the reads cause the charge to
decay faster.
.