#optimizer fix
19 messages in this thread
I have a rather strange occurance. I have been playing with the IDEA
encryption file included with the PGP source files. I finally managed to
get the test version to run, but have come across something rather
strange. I compiled it with SAS C 6.5 and was having trouble with the
test decryption not being equal to what I started with. I then compiled
it with the optimizer on and now the program works correctly. I was under
the impression that the optimizer only worked on correctly running
programs, and if you optimize a program that doesn't work, it'll still
won't work, but only faster. What I would like to know, what did the
optimizer fix?
James Du Bois via AutoPilot
Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951
>I then compiled
>it with the optimizer on and now the program works correctly. I was under
>the impression that the optimizer only worked on correctly running
>programs, and if you optimize a program that doesn't work, it'll still
>won't work, but only faster. What I would like to know, what did the
>optimizer fix?
This is an elusive one and the real answer is nothing is "fixed."
I call this and related phenomena “good garbage''.
The basic situation is that you changed the rules of the game by
optimizing (you *do* now have a different program) and got lucky.
Since you know something is wrong, I wouldn't trust it even though
it may turn out that the optimizer did generate something that will
always do the correct thing. But, until you know that, you don't.
And when you do, you'll probably know what was wrong in the first place
and resolve it accordingly. There is also danger in ignoring it,
and subsequently changing something else, which will expose the problem,
perhaps not giving the optimizer the same break (which was no doubt blind
luck in the first place) but only after "you know the optimizer fixed it."
>Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951
??
Greg,
Thanks, I had noticed when the compiler optimized the program that a
couple of messages refering to:
Warning 304 in idea.c line 208: dead assignment eliminated "Z"
Warning 304 in idea.c line 453: dead assignment eliminated "<indirect>"
Since the code around line 453 is dealing with erasing the key used to
encrypt and decrypt the message after everything is done, I am assuming
that the problem is with the "Z". Since this is in the actual encrypting
function, I don't know if I can change anything and have the function work
with messages encrypted on another computer.
On an unrelated question. Why would the compiler compile a jump to 0x04?
I compiled another program that crashed my machine repeatedly and I tried
to use the debugger on it. I tried to compile using full debug, but I
only get the assembly listing without the C source that is supposed to be
there. Anyway, since I don't know that much about assembler or MC680x0
opcodes, I have tried to figure out what is wrong. It still beats me.
>Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951
>??
Haven't you ever seen the t-shirts with the "I survived … " or "Member
GeoPhysical year 19??" ? Note the dates and the order they are in. 😎
James Du Bois via AutoPilot
Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951
A compiler shouldn't compile a jump to 0x04. It may create code that says JMP
(0x04) or JSR (0x04). But that would load an address from location 4 and then
go there (called indirect addressing). I think that is probably what is going
on but I am in 6502 programming mode at the moment.
Phill
Phill,
Sorry, but it IS compiling a jump to 0x4, I watched it jump to 0x4
using the debugger. I think it is an indirect JSR call, but since I know
almost no assembler, the assem. source means almost nothing to me.
James Du Bois via AutoPilot
Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951
> Sorry, but it IS compiling a jump to 0x4, I watched it jump to 0x4
>using the debugger. I think it is an indirect JSR call, but since I know
>almost no assembler, the assem. source means almost nothing to me.
I don't know what the I&D situation is on the Amiga
(it's been years since I toyed with that kinda stuff and
forget which chips and OSs do what), but there is a big difference
in your executing (seeing) a jmp to 4 in your debugger or the compiler
generating the jump or the RTL routine doing it or etc.
These may seem like pedantic differences, but they all present
totally different scenarios. Finding out which is your case is
the issue. For instance, perhaps what you're seeing executed is
some data somewhere that the program "inadvertantly" got to via
some uninitialized function pointer or somesuch. I have a cliche
I use often when I lecture on C and C++, more applicable to source
but, but it is probably applicable here to:
What you see is what you get. — Anonymous
What you see is all you get. — Brian Kernighan
What you see is what you see. What you get is what you get. — Greg Comeau
This (unfortunately?!) encompasses many things, programming and otherwise
and is "what the fun is about." 😉
Greg,
I think I'm just going to flush the program, I was just interested in
looking at it, but since I can't get it to compile properely I just need
to get rid of it. It's not that important. I don't know enough C to
correct the source, and I don't know enough about the algorithm to write
the source from scratch. Besides, I need the disk space. 😎
James Du Bois via AutoPilot
Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951
WYSIWYS, WYGIWYG? Whizzy-whis, Wiggy-wig? This is what you want to be
remembered for? 🙂
>WYSIWYS, WYGIWYG? Whizzy-whis, Wiggy-wig? This is what you want to be
>remembered for? 🙂
Apparently you've been to my lecture(s) 😉
I'm remembered for many things, so this one won't do any harm.
In fact, it's point is to do good, even though it's YAA. 😉
No, I haven't yet had the pleasure of seeing one of your lectures… Is this
part of your "routine"?
I've always thought there'd be a big market for computer comedy. I once saw
St. Silicon in person, and I hear Paula Poundstone has a fair amount of
computer comedy…
>No, I haven't yet had the pleasure of seeing one of your lectures… Is this
>part of your "routine"?
Yes! Precisely so.
>I've always thought there'd be a big market for computer comedy. I once saw
>St. Silicon in person, and I hear Paula Poundstone has a fair amount of
>computer comedy…
I am particularly serious about my lectures. As well, some of it is
non-trivial. In isolation, that could spell b-o-r-i-n-g, even for folks
interested in hearing me or the topic. I use a number of techniques
to ensure the synapses are still going, both for the students and for myself
(in many ways I consider straight lecturing ridiculous). Plus I think
learning should be fun, so I try my darndest that my classes are a panic
(not always, but most times).
If you're jumping to location 4, your code is probably attempting to call a
function pointer that has not been properly initialized or that has been
trashed by another bug. The compiler won't generate a call to location 4.
There are several possible causes for why your code works optimized. If
you've got a memory-trashing bug, as it sounds like you might, then
the changes caused by optimization might change the symptoms – i.e. a
different piece of memory gets trashed.
Try using memlib in SC:EXTRAS and see if any memory-trashing problems come
up. Make sure you are running SC:C/Enforcer and SC:C/Mungwall to get the
best diagnostics possible.
–Doug
Doug,
>Make sure you are running SC:C/Enforcer and SC:C/Mungwall to get the
>best diagnostics possible.
Ok, I'll try it.
James Du Bois via AutoPilot
Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951
>Warning 304 in idea.c line 208: dead assignment eliminated "Z"
>Warning 304 in idea.c line 453: dead assignment eliminated "<indirect>"
>
>Since the code around line 453 is dealing with erasing the key used to
>encrypt and decrypt the message after everything is done, I am assuming
>that the problem is with the "Z".
That is definitely one place I'd look, but it is always too easy to be
led astray by "obvious" clues which turn out to be deadends.
Remain open minded and don't wander too far.
> Since this is in the actual encrypting
>function, I don't know if I can change anything and have the function work
>with messages encrypted on another computer.
I don't know the full implication of this. I mean it could break
compatibility. It could show that the encrypter is broken on the other
machine, etc. Researching it is the only way to find out what is what
for sure.
>On an unrelated question. Why would the compiler compile a jump to 0x04?
I haven't a clue to your context or what you're looking at, or not.
That you might see a jump to 4 doesn't necessarily mean the compiler
created it.
Greg,
Thanks, I'll play around with it and see if that is the problem. Gee,
I never had these problems in BASIC or Forth. 8-/
James Du Bois via AutoPilot
Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951
> Thanks, I'll play around with it and see if that is the problem. Gee,
>I never had these problems in BASIC or Forth. 8-/
Perhaps. Of course that can be because of many thing.
James;
Location 0x04 is the ONLY legal hardware address in an Amiga. It is necessary
to get the exec base address from this location when the program first starts
up.
-bill
Bill,
yes, the address of _SysBase is stored at 0x04. You have to _read_ what is in
this location, but you must not _jump_ to it.
– wkc – … via AP from Hamburg, Germany
Bill,
Yes, I know 0x04 is the only fixed address on the Amiga, but I thought
you could only READ this address to find AbsExecBase, I don't think you
should JSR to it.
James Du Bois via AutoPilot
Member of the Bermuda Triangle Exploratory Expedition 1992 – 1951