const myArray as word[256]

[peterverkaik]

Hi,

I declared

const myArray as word[256] = (
<commalist of values>,15999)
so myArray[255] should be 15999

however
dim i as word
i = myArray[255]
shows i=0 when running the debugger.
There are 256 values specified.
Do I need to run an initialization routine or something?

regards peter

[anikolic]

Hi,
mikroBasic for dsPIC30/33 and PIC24 is two year old compiler with lots of known issues, and this could be one of them. Thank you for reporting, our developers will take a look at your suggestions. New, improved and much better PRO version of compiler is expected to be available for beta testing in about one month period, and I assure you this will be resolved.
Sorry for the inconvenience.

Best regards,
Aleksandar

[peterverkaik]

Is there a list of known issues?
A sticky thread about compiler issues
and possible workarounds would be welcomed.

regards peter

[extrapilot]

Hi Peter
There seems to be a series of bugs in the dsPIC compiler related to arrays. One that might apply involves constant arrays, where for some reason, the coimpiler seems to sort of convolute the ASM for the constant data. For example, if the value for Cell[0] is defined as 0x0123, and for Cell[1] it is 0x4567, you may find in the compiled ASM in the data space these referenced as 1067 and 2345, or some such inversion. So the values you see may seem totally random, but in fact they are just convoluted variants of the other cells.

Another error 'seems' to be that the conversion of references in procedures to constants (i.e. While LocalCount < ConstantDefinedCount) do...), the value of ConstantDefinedCount may be some random value. I dont believe this is convolution, because if you reference this by explicit pointers, the values are correct as long as this is not a constant array. That is, so far as I know, Constant=0x1234 always works if you access it by its address.

I reported these to ME last year, and so far, there seems to be no workaround for the constant array problem. If you have the RAM, you might try setting up an array and then populating it in your Initialize routine. As best I can tell, this always works, though it burns RAM.

Regards,
Rob

[peterverkaik]

Hi Rob,

Inspecting the listfile reveals
;RGBWS.dbas,345 :: i = RGB1024_duty[1023]
$052A $200000 MOV #0, W0
$052C $200001 MOV #0, W0+2
$052E $07FF21 RCALL __Float2Longint
$0530 $8859F0 MOV W0, _i

Why the call to __Float2Longint? That seems to be the error.

Workaround:
;RGBWS.dbas,344 :: i = 1023
$04B6 $203FF0 MOV #1023, W0
$04B8 $8859F0 MOV W0, _i
;RGBWS.dbas,345 :: i = RGB1024_duty[i]
$04BA $287064 MOV #@rgb1024_duty, W4
$04BC $207FE0 MOV #2046, W0
$04BE $420000 ADD W4, W0, W0
$04C0 $780210 MOV [W0], W4
$04C2 $8859F4 MOV W4, _i

That seems to work.

Also, the generated const tables all have the correct values.
No 'convolotion' or any kind of byteswapping. I use wordvalues
and these fit in the 24bit wide flashword.

regards peter

[anikolic]

Hi.
@peterverkaik: I did some consultation with our developers regarding your problem and I was given information that you can implement a workaround by using additional variable that contains index of the element you want to access:

Code: Select all

program Test

dim rx1  as  word
const myArray as word[256]=(.....)

dim i as word
dim j as byte
main:
  j = 255
  i = myArray[j]
end. 

Why the call to __Float2Longint? That seems to be the error.

Yes, this is probably due to wrong calculations of data type length and index boundaries, and I assure you new PRO compiler will take care of this.

Best regards,
Aleksandar

[peterverkaik]

Thanks for your confirmation on the workaround.

regards peter