[fpc-devel] Review of AVR patch for bug 31925

[Georg Hieber]

implementing 8*8 bit multiplications as library functions is certainly 
one way to cope with the absence of mul/mulsu instructions in  the 
"basic" avr subarchitectures, and the resultint compiler error message 
when confronted with any source code resulting in such a multiplication.

The question is, if that is the most reasonable way to do it, or if it 
would be simpler to have the compiler directly insert the required 
compare/add/shift sequence. This should be answered by someone with a 
very good knowledge of the AVR code generator.


Am 22.09.2017 um 12:28 schrieb Christo:
> On Fri, 2017-09-22 at 07:10 +0200, Christo wrote:
>> On Wed, 2017-09-20 at 12:36 +0200, Karoly Balogh (Charlie/SGR) wrote:
> A complication I've noted is that enabling overflow checking doesn't
> call the fpc_mul_byte_overflow function (as the naming convention
> suggested), rather the generated code calls fpc_mul_byte and then check
> the carry flag to determine whether an overflow occurred. Since the
> function in generic.inc is plain pascal code there is no guarantee that
> the carry flag will be set if an overflow should have occurred.  I
> assume that at a higher level the code generator assumes that a
> hardware MUL instruction _will_ be used, leading to incorrect overflow
> detection logic if a software helper is used.
>
> A similar situation exist for the current 16 bit software MUL case with
> overflow checking.
>
> Any pointers on where to start looking to try and adapt the overflow
> checking code generation?
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel