ZBasic Forum : ZBasic Language : Persistent Variables

ZBasic Home

Forum Rules

Forum FAQ

Memberlist

Usergroups

RSS Feed

Site Search

Links

Download

Digests and Subscriptions

Profile

Persistent Variables

Forum Index -> ZBasic Language

Author

Message

Don_Kirby

Joined: 15 Oct 2006
Posts: 329
Location: Long Island, New York

Posted: 24 October 2006, 0:24 AM Post subject: Persistent Variables

In converting my code from BasicX to ZBasic, I came across something that could use some clarification.

In the BasicX docs, the following suggests that the ordering in EEPROM memory is maintained by read, as well as write operations. (#2)

Quote:

In order to guarantee the ordering of persistent variables, 3 rules should be followed:
1. All persistent variables should be declared in one module.
2. The ordering of declarations of persistent variables must match the order in which the variables
are first accessed at runtime. In this context, "accessed" means either a read or write operation.
3. All persistent variables should be private.

What I've done in the past is to read each variable into a temp non-persistent variable at the beginning of Sub Main(), in order. I don't really know if it does anything or not, but the docs suggest it does.

Is this necessary in ZBasic? I've declared all of my persistents (as well as non-persistents globals) in a seperate module, for ease of coding. This, in effect, ensures that they are always declared in the same order.

So I guess the question is; Once the persistents are initialized (done automatically in my app on FirstTime()), do I really need to maintain the ordering by reading or writing in any particular order?

As an aside, although NetMedia tells me that they should be private, it seems to me that private persistent variables are a bit of an oxy moron.

-Don

dkinzer
Site Admin

Joined: 03 Sep 2005
Posts: 2493
Location: Portland, OR

Posted: 24 October 2006, 1:23 AM Post subject: Re: Persistent Variables

Don_Kirby wrote:

[...]What I've done in the past is to read each variable into a temp non-persistent variable at the beginning of Sub Main(), in order. I don't really know if it does anything or not, but the docs suggest it does. Is this necessary in ZBasic?

Short answer: no. Long answer: The ZBasic compiler assigns persistent memory addresses in the order that modules are compiled and within modules in the order the variables are defined. Adding superfluous code to read the Persistent variables is neither necessary nor useful with respect to the resulting addresses.

To avoid unexpected address changes, it is suggested that all Persistent variables be declared in just one module. However, if you are careful not to change the order of compilation of modules it is workable to have them defined in several modules. The compilation order is the order that the module names appear in the project file and/or on the compiler command line.

Don_Kirby wrote:

As an aside, although NetMedia tells me that they should be private, it seems to me that private persistent variables are a bit of an oxymoron.

No more oxymoronic, I would suggest, than private RAM-based variables. I think that NetMedia's suggestion implies that the module containing the Persistent variables should provide a public interface for reading/writing the values of Persistent variables.

Don_Kirby

Joined: 15 Oct 2006
Posts: 329
Location: Long Island, New York

Posted: 24 October 2006, 1:48 AM Post subject: Re: Persistent Variables

Thanks for clearing that up. I had a hard time believing that reading the persistent would have anything to do with the ordering, but one can never tell...

dkinzer wrote:

Of course. My perception is skewed due to the fact that I usually only use persistent variables for global settings that woud be public anyway. Encapsulation was never one of my strong points.

A bit off topic here:

I have been working my way through a large-ish application origionally written for the BX24. Porting it for the ZX44 has been almost too easy. By far the biggest change is all of the things I don't have to do (such as reading persistent variables in order at the start of the app). While it seems that the ZX compiler is more efficient (producing smaller code), it also makes many BX conventions obsolete, requiring even less code space.

While the initial porting was easy (the code compiled without modification), I seem to be doing a lot of 'tweaking', making the code faster and more compact as I go. Kudos.

-Don

stevech

Joined: 23 Feb 2006
Posts: 656

Posted: 24 October 2006, 2:07 AM Post subject:

question on writing speed - using putPersistent() and a byte declared as in persistent. My app is using putPersistent() because it's storing structures and there's no persistent type yet. The speed seems slow.

dkinzer
Site Admin

Joined: 03 Sep 2005
Posts: 2493
Location: Portland, OR

Posted: 24 October 2006, 2:53 AM Post subject:

stevech wrote:

question on writing speed - using putPersistent() and a byte declared as in persistent.

Although the pcode instructions generated for the two types of access are slightly different, internally they are implemented using the same service routine. Consequently, calling PutPersistent() for a 1-byte write should be nearly the same speed as assigning to a PersistentByte variable.

stevech wrote:

The speed [of PutPersistent()] seems slow.

The mega32 specification says that writing a byte will typically require 8.5mS. Writing a 10 byte structure would take in excess of 85mS. The measured time for a 10-byte write was 75mS using the code below. This was executed on a ZX-24 using pin 13 as a timing signal monitored with a logic analyzer.

Code:

Dim b as Byte
Sub Main()
Register.DDRA = &H80
Call PutPersistent(200, b, 10)
Register.PortA = &H80
End Sub

dkinzer
Site Admin

Joined: 03 Sep 2005
Posts: 2493
Location: Portland, OR

Posted: 24 October 2006, 3:01 AM Post subject: Re: Persistent Variables

Don_Kirby wrote:

Thanks for clearing that up. I had a hard time believing that reading the persistent would have anything to do with the ordering, but one can never tell...

It may well be that the read accesses do, in fact, affect the address assignment in BasicX. It never made much sense to me to require that so I adopted a different strategy.

Don_Kirby wrote:

While the initial porting was easy (the code compiled without modification), I seem to be doing a lot of 'tweaking', making the code faster and more compact as I go.

To be able to compile a BasicX program without modification was a design goal. We're pleased that that part was trivial for you. The more difficult part was the design goal of having a working BasicX program function the same. The realization of that goal was complicated by incorrect and/or incomplete documentation, processor differences and main clock speed differences. Have you had success executing your code on the ZX platform?

stevech

Joined: 23 Feb 2006
Posts: 656

Posted: 24 October 2006, 4:23 AM Post subject:

dkinzer wrote:

stevech wrote:

question on writing speed - using putPersistent() and a byte declared as in persistent.

stevech wrote:

The speed [of PutPersistent()] seems slow.

Code:

Dim b as Byte
Sub Main()
Register.DDRA = &H80
Call PutPersistent(200, b, 10)
Register.PortA = &H80
End Sub

Thanks for the info and reminder on on-chip EEPROM writing speed.
One more question: Does the VM suspend the task doing the write to persistent memory and run other tasks during the 8.5mSec/byte? I know it would get complicated, so I'd guess "no".

dkinzer
Site Admin

Joined: 03 Sep 2005
Posts: 2493
Location: Portland, OR

Posted: 24 October 2006, 5:12 AM Post subject:

stevech wrote:

Does the VM suspend the task doing the write to persistent memory and run other tasks during the 8.5mSec/byte? I know it would get complicated, so I'd guess "no".

You are correct, it does not.

Don_Kirby

Joined: 15 Oct 2006
Posts: 329
Location: Long Island, New York

Posted: 24 October 2006, 9:35 AM Post subject: Re: Persistent Variables

dkinzer wrote:

Have you had success executing your code on the ZX platform?

Short answer: yes. Long answer: I had quite a few problems in the beginning due to the speed issues. Once that was resolved, there were only slight differences to deal with. I'm now at the point where I can add some functinality to the application that I couldn't have before (due to code space restrictions). Basically, I've rewritten most of the application. Partly due to knowing more about the languages involved, and partly due to the BX-ZX differences. All in all, I'm very pleased.

-Don

Display posts from previous:

	Forum Index -> ZBasic Language	Time synchro. with the server - Timezone/DST with your computer
Page 1 of 1