On Monday 12 August 2013 20:45:22 andy pugh did opine: > I just fixed (I think) a very serious bug in the Resolver driver on > 64-bit systems > It was in some code that promotes a 32-bit register into a 64-bit > accumulator. > > This is done by subtracting the old 32-bit register value from the new > one, and adding the difference to the accumulator. > This works even when the 32-bit value wraps, as a consequence of > 2s-complement maths. > > The problem was caused by the assumption that casting to long gives a > 32-bit value. > > A quick grep of the code for (long) shows very many instances of that > cast. I rather suspect that in many cases it might not be doing quite > what the author intended when compiled for 64-bit systems. > This might need a bit of analysis by someone who actually understands > this sort of thing…
Do those 'casts' make the compiler issue the equ of the motorola 6809's "sex" (sign extend) instruction? When applied to the value in the lower half of the accumulator, register B, it sign extends the d7 bit of the B register into the A register, creating a 2's complement 16 bit value that can in turn be used for other 16 bit add & subtracts using the D register code to represent the combined A:B set.. No reason a 64 bit cpu wouldn't have the equivalent assembly language command to extend a 32 bit registers bit d31 into the combined 64 bit register. In fact, I would consider any so called 64 bit cpu that didn't have the equivalent command as being seriously drain bamaged. But I would verify that its being used properly by doing the compile in stages, looking at the compilers output to the assembler. On the 6x09 cpu, I have been known to find 50% increases in speed by substituting a quick register copy in place of 8 individual 1 bit, 2 register shifts to do exactly the same thing as all those one bit shifts. I used the 6x09 as a placeholder since the Hitachi HD63C09EP is functionally the same as the Motorola MC68C09EP but is done in cmos with the 6809's opcode map done in micro-code, which left a lot of empty space so Hitachi filled it in with more registers and smarter code. But their contract with moto was for a workalike, so 15 years after we discovered the new commands, Hitachi has yet to admit they exist. Smarter as in it can do a 16 bit into a 32 bit divide, all internally, in 39 clocks worst case. The equ on a 6809 is about 1500 clocks. As I'm not that familiar with GCC, I'd have to assume that similar 'stageing' of a build could be used if the right command line options were given, but I've never done it as the assembly nemonics for the X86 stuffs have yet to make any sense to the motorola trained/contaminated mind. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> signal(i, SIG_DFL); /* crunch, crunch, crunch */ -- Larry Wall in doarg.c from the perl source code A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
