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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
