[BUG REPORT OPTIMISER]

wrong address calculaction

  • 1
  • 2
  • Page 1 of 2
Thomas.AC
Benutzer
Avatar
Gender: n/a
Age: 43
Posts: 308
Registered: 07 / 2013
Subject:

[BUG REPORT OPTIMISER]

 ·  Posted: 25.01.2016 - 13:59  ·  #1
Hello Merlin,

there is a silly bug in avrco 5.07.00 with optimizer 3.4.1.0

Look at the picture of the Attachement:
Bytes are written to wrong Memory Locations (red circles)

Code

program optimizerAddressBug;

Device = mega2560, VCC=5;

Import;
From System Import ;


Define
  ProcClock      = 16000000;       {Hertz}
  StackSize      = $0064, iData;
  FrameSize      = $0064, iData;

Implementation

{$IDATA}

type
  T_Button = record
    btnNr               : byte;
    btnData             : array[0..9] of byte;
  End;

var
  btnArray[$573] : array[0..17] of T_Button;

begin
  btnArray[0].btnNr := 1;
  btnArray[1].btnNr := 2;
  btnArray[2].btnNr := 3;
  btnArray[3].btnNr := 4;
  btnArray[4].btnNr := 5;
  btnArray[5].btnNr := 6;
  btnArray[6].btnNr := 7;
  btnArray[7].btnNr := 8;
  btnArray[8].btnNr := 9;
  btnArray[9].btnNr := 10;
  btnArray[10].btnNr := 11;
  btnArray[11].btnNr := 12;
  btnArray[12].btnNr := 13;
  btnArray[13].btnNr := 14;
  btnArray[14].btnNr := 15;
  btnArray[15].btnNr := 16;
  btnArray[16].btnNr := 17;
  btnArray[17].btnNr := 18;
end optimizerAddressBug.



Thomas.AC
Attachments
simulator showing optimizer bug
Filename: optimizerAddressError.png
Filesize: 84.16 KB
Title: simulator showing optimizer bug
Download counter: 142
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: [BUG REPORT OPTIMISER]

 ·  Posted: 25.01.2016 - 14:34  ·  #2
Hello Thomas,

it seems that this is a problem of the Merlin Optimiser, right?

rolf
Thomas.AC
Benutzer
Avatar
Gender: n/a
Age: 43
Posts: 308
Registered: 07 / 2013
Subject:

Re: [BUG REPORT OPTIMISER]

 ·  Posted: 25.01.2016 - 15:02  ·  #3
Yes,
no erroneous memory location without optimiser
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: [BUG REPORT OPTIMISER]

 ·  Posted: 25.01.2016 - 15:18  ·  #4
ok, I found the Optimiser problem,

Code
  .LINE     35
  LDI       _ACCCLO, optimizerAddressBug.btnArray + 66 AND 0FFh
  LDI       _ACCCHI, optimizerAddressBug.btnArray + 66 SHRB 8
  LDI       _ACCA, 007h
  ST        Z, _ACCA
  .LINE     36
  LDI       _ACCCLO, optimizerAddressBug.btnArray + 77 AND 0FFh <- addition overflow not recognized !
  LDI       _ACCA, 008h
  ST        Z, _ACCA

If the fixed address is @ $5F0 then the bug appears after first addition.

rolf
Merlin
Administrator
Avatar
Gender:
Age: 24
Posts: 1409
Registered: 03 / 2005
Subject:

Re: [BUG REPORT OPTIMISER]

 ·  Posted: 25.01.2016 - 16:11  ·  #5
Hi Rolf. Maybe I misunderstood how the assembler works. I would not expect an overflow in your assembler there. What is the correct syntax to prevent an overflow? Or are you saying that the SHRB 8 is missing in this case?

Yes, considering the situation, this must be what you mean.

I will investigate straight away.
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: [BUG REPORT OPTIMISER]

 ·  Posted: 25.01.2016 - 18:05  ·  #6
Hello Merlin,

yes, of course an overflow may appear!
Assuming the array address is $12FF.
The Assembler adds the offs to $ff
Then the ACCCLO is loaded with ($FF + offs)
And here comes the Overflow. ACCCLO is wrapped throu 0.
This wrapping then must be succeded by an increment of ACCCHI.

To take tis overflow event into account the compiler always
adds a 16bit value of offs to ACCCLO/HI

In this very, very special case you can use
ADIW ACCCLO, step
where step is the index size of this array, presuming that
step is not greater than 63.

rolf
Harald_K
 
Avatar
 
Subject:

Re: [BUG REPORT OPTIMISER]

 ·  Posted: 25.01.2016 - 20:27  ·  #7
.LINE 36
LDI _ACCCLO, optimizerAddressBug.btnArray + 77 AND 0FFh <- addition overflow not recognized !
LDI _ACCA, 008h
ST Z, _ACCA


problem is, that the overflow on addition (btnArray + 77) is recognized, but is cutted off by the AND 0FFH - the upper Address byte must be loaded with the correct value.

.LINE 36
LDI _ACCCLO, optimizerAddressBug.btnArray + 77 AND 0FFh <- addition overflow not recognized !
LDI _ACCCHI, optimizerAddressBug.btnArray + 77 SHRB 8 <- addition overflow not recognized !
LDI _ACCA, 008h
ST Z, _ACCA

this needs one clock cycle more ...

you might replace both LDIs by one
ADIW _ACCCHI, 11 ; or maybe _ACCCLO

which performs a word-add. It uses also 2 machine cycles like the two 8bit-Adds but it uses a smaller amount of ROM space. But the addable value is only +/- 64. On the other hand, the ADIW changes a lot of flags, LDI doesnt change any.
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: [BUG REPORT OPTIMISER]

 ·  Posted: 25.01.2016 - 20:45  ·  #8
Hi Harald,

yes, the ADIW seems to be the best solution.
In this special case the Opti can continously use ADIW _ACCCLO, 11
without loading the Z-Pointer (ACCCLO/HI) with new values

Code
// load the Z-pointer with start address of the array and then
  LDI     _ACCA, xx
  STS     Z, _ACCA
  ADIW    _ACCCLO, 11
  LDI     _ACCA, yy
  STS     Z, _ACCA
  ADIW    _ACCCLO, 11
  ...

rolf
  • 1
  • 2
  • Page 1 of 2
Selected quotes for multi-quoting:   0

Registered users in this topic

Currently no registered users in this section

The statistic shows who was online during the last 5 minutes. Updated every 90 seconds.
MySQL Queries: 16 · Cache Hits: 15   140   155 · Page-Gen-Time: 0.035145s · Memory Usage: 2 MB · GZIP: on · Viewport: SMXL-HiDPI