max length of constants

Beta Testing discussion on mikroBasic PRO for dsPIC30/33 and PIC24.
Post Reply
Author
Message
peterverkaik
Posts: 174
Joined: 31 Aug 2009 22:44

max length of constants

#1 Post by peterverkaik » 22 Dec 2009 10:15

According to help subject What's new
Program can have more than 32kBytes of constants, PSVPAG is maintained by linker

However, declaring
const cbuf as byte[32769] = (0)

generates linker error
There is not enough ROM space

const cbuf as byte[32768] = (0)
linkes ok

regards peter

User avatar
anikolic
mikroElektronika team
Posts: 1775
Joined: 17 Aug 2009 16:51
Location: Belgrade
Contact:

#2 Post by anikolic » 23 Dec 2009 11:10

Hi,
Yes, there can be more than 32Kbytes of constants, plural. Sum of all memory consumed by constants can exceed 32KBytes up to maximum available memory. But maximum size of a single constant can be 32K = 32768 bytes.
So, if you add another line:

Code: Select all

const cbuf as byte[32768] = (0) far
const cbuf1 as byte[32768] = (0) far

it will compile correctly.

Also, you should use far memory qualifier for such a large values of constant's size, because it can be stored anywhere in memory, not just in the first 32Kbytes of program memory.

Best regards,
Aleksandar
Web Department Manager

peterverkaik
Posts: 174
Joined: 31 Aug 2009 22:44

#3 Post by peterverkaik » 23 Dec 2009 12:48

Thanks for the clarification. That wasn't quite clear
from the help text.

If a const is declared far
const tempString as string[10] = "someText" far

does that mean that @tempString is of type longword or longint?

regards peter

peterverkaik
Posts: 174
Joined: 31 Aug 2009 22:44

#4 Post by peterverkaik » 23 Dec 2009 12:55

I can do

dim bptr as ^const byte far
bptr = @tempString

Does adding far to pointer declaration make bptr a 32bits pointer

regards peter

peterverkaik
Posts: 174
Joined: 31 Aug 2009 22:44

#5 Post by peterverkaik » 23 Dec 2009 17:01

I found out

dim bptr as ^const byte far
creates a 16bit pointer

dim bptr as ^far const byte
creates a 32bit pointer

bptr = @largeBuf3 'address of largeBuf3 > 0xFFFF
if bptr^ = 0 then

compiles into

Code: Select all

;RGBWSv0_02p.mbas,702 :: 		bptr = @largeBuf3
0x040C	0x284410  	MOV	lo_addr(_largeBuf3), W0
0x040E	0x200021  	MOV	higher_addr(_largeBuf3), W1
0x0410	0x884700  	MOV	W0, _bptr
0x0412	0x884711  	MOV	W1, _bptr+2
;RGBWSv0_02p.mbas,703 :: 		while (1)
L__main32:
;RGBWSv0_02p.mbas,704 :: 		if bptr^ = 0 then
0x0414	0x804700  	MOV	_bptr, W0
0x0416	0x804711  	MOV	_bptr+2, W1
0x0418	0x8801A1  	MOV	W1, PSVPAG
0x041A	0x784010  	MOV.B	[W0], W0
0x041C	0xE10460  	CP.B	W0, #0
This revealed the existence of higher_addr(_label)
(why not hi_addr since lo_addr is used)
Interesting to see how the linker manages psv to read a flashbyte.
Would a tableread use less code?

regards peter

User avatar
anikolic
mikroElektronika team
Posts: 1775
Joined: 17 Aug 2009 16:51
Location: Belgrade
Contact:

#6 Post by anikolic » 24 Dec 2009 14:38

peterverkaik wrote:Interesting to see how the linker manages psv to read a flashbyte. Would a tableread use less code?
I have consulted with our developers, and I have been given information that code using tableread wouldn't be smaller, in fact it would be about the same size, but then the compatibility between near ROM and RAM pointers would be lost.

Best regards,
Aleksandar
Web Department Manager

Post Reply

Return to “mikroBasic PRO for dsPIC30/33 and PIC24 Beta Testing”