SV: SV: [basicstamps] Nothing on Memory Map Window?
Archiver
Posts: 46,084
Greetings!
>>That aside, if you know how much space your data will use you could
>>reserve it with the DATA statement. (highly recommended)
> The DATA statement still does not limit storage. Program/Data
collisions can
> still occur if the programmer is not careful about where they write
data.
No, it doesn't, but it will show up on the memory map, and I think the
translator will give an error if the program code grows to reach the
areas defined with the DATA statement.
If the data size isn't known beforehand, all a user can do is to note
how long the program is(approximately) and test for it run-time, or use
a BS2p/BS2pe since they allow data to be stored in separate Program
spaces.
:-)
Trygve
>>That aside, if you know how much space your data will use you could
>>reserve it with the DATA statement. (highly recommended)
> The DATA statement still does not limit storage. Program/Data
collisions can
> still occur if the programmer is not careful about where they write
data.
No, it doesn't, but it will show up on the memory map, and I think the
translator will give an error if the program code grows to reach the
areas defined with the DATA statement.
If the data size isn't known beforehand, all a user can do is to note
how long the program is(approximately) and test for it run-time, or use
a BS2p/BS2pe since they allow data to be stored in separate Program
spaces.
:-)
Trygve
Comments
>Greetings!
>
> >>That aside, if you know how much space your data will use you could
> >>reserve it with the DATA statement. (highly recommended)
>
> > The DATA statement still does not limit storage. Program/Data
>collisions can
> > still occur if the programmer is not careful about where they write
>data.
>
>No, it doesn't, but it will show up on the memory map, and I think the
>translator will give an error if the program code grows to reach the
>areas defined with the DATA statement.
>
>If the data size isn't known beforehand, all a user can do is to note
>how long the program is(approximately) and test for it run-time, or use
>a BS2p/BS2pe since they allow data to be stored in separate Program
>spaces.
>
>:-)
>Trygve
Trygve -
I respectfully disagree with your assessments, but we'll wait for a "ruling"
from Jon Williams, or any other Parallax employee who may wish to offer a
definitive answer.
The DATA statement merely assigns storage or values at compile time rather
than run time. That is EXACTLY why it DOES show up on the memory map.
I believe the manual clearly states that the compiler/interpreter makes no
check as regards to data boundaries. In the same section (as I remember)
the admonition about data overrunning program areas is also made. I don't
have the latest
PBasic Manual handy, otherwise I would cite page numbers for reference.
Additionally, my information reflects PBasic versions prior to 2.5 . I've
not had the pleasure yet of using that latest version.
Regards,
Bruce Bates
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the Subject and
>Body of the message will be ignored.
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
When you compile your program the DATA statements get placed into the
EEPROM first (from the bottom [noparse][[/noparse]0] up). That way, if you have a DATA
collision (due to specifying an address that is already being used by
other data) the compiler can alert you with...
"Location already contains data"
If the DATA statements have no collisions, your source code is tokenized
and placed into memory from the top [noparse][[/noparse]$07FF] down. If a token location
collides with a DATA byte, you will get this error message...
"Location occupies same location as program"
None of these checks prevent you from growing your DATA area with WRITE
and colliding with your program tokens. After discussing it, we are
considering adding another feature to PBASIC 2.5 that will let you write
the end-of-program address to a DATA statement. Perhaps something like
this:
PgmEnd DATA (EOP)
What this will do is place the two-byte address of the last token into
your DATA table so that you can check for a possible collision. You
could do something like this:
READ PgmEnd, Word eopAddr
IF (eopAddr > (recAddr + recLen)) THEN
' write new record
ELSE
' data would overwrite program space -- don't do it!
ENDIF
Please understand that this is in development, so for the time being you
may need to check your memory map and manually code your EOP address to
prevent run-time collisions.
-- Jon Williams
-- Applications Engineer, Parallax
-- Dallas Office
Original Message
From: Bruce Bates [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=TEVtddquZZiIuAmEWUU0k1GvSE9joyVto5qMeM62Y9m6WsTdx1f8inkCiLx3ScHaEGvkMObB7hp193mGqLg]bvbates@u...[/url
Sent: Thursday, August 21, 2003 8:32 AM
To: basicstamps@yahoogroups.com
Subject: Re: SV: SV: [noparse][[/noparse]basicstamps] Nothing on Memory Map Window?
At 02:39 PM 8/21/03 +0200, Trygve Henriksen wrote:
>Greetings!
>
> >>That aside, if you know how much space your data will use you could
> >>reserve it with the DATA statement. (highly recommended)
>
> > The DATA statement still does not limit storage. Program/Data
>collisions can
> > still occur if the programmer is not careful about where they write
>data.
>
>No, it doesn't, but it will show up on the memory map, and I think the
>translator will give an error if the program code grows to reach the
>areas defined with the DATA statement.
>
>If the data size isn't known beforehand, all a user can do is to note
>how long the program is(approximately) and test for it run-time, or use
>a BS2p/BS2pe since they allow data to be stored in separate Program
>spaces.
>
>:-)
>Trygve
Trygve -
I respectfully disagree with your assessments, but we'll wait for a
"ruling" from Jon Williams, or any other Parallax employee who may wish
to offer a
definitive answer.
The DATA statement merely assigns storage or values at compile time
rather than run time. That is EXACTLY why it DOES show up on the memory
map.
I believe the manual clearly states that the compiler/interpreter makes
no
check as regards to data boundaries. In the same section (as I remember)
the admonition about data overrunning program areas is also made. I
don't
have the latest
PBasic Manual handy, otherwise I would cite page numbers for reference.
Additionally, my information reflects PBasic versions prior to 2.5 .
I've not had the pleasure yet of using that latest version.
Regards,
Bruce Bates
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the Subject
>and
>Body of the message will be ignored.
>
>
>Your use of Yahoo! Groups is subject to
>http://docs.yahoo.com/info/terms/
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject
and Body of the message will be ignored.
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
This message has been scanned by WebShield. Please report SPAM to
abuse@p....