Compiled code size

frthomas

Anybody has like a good model of the size of the code generated by the compiler?

I have very strange and variable results. It seems large arrays eat some compiled code memory, and/or code containing it take an enormous amount of time to compile.
Also I noticed that changing the size of an array changes the code size, and surprise, not necessarily in the way you'd expect: making the array smaller increases the code size...

I guess there must be some complex things going on with optimizations kicking in at some obscure point. I was just wondering if anybody had some idea about that.

Practically, my code is reaching 1.2 Meg and I am starting to get out of room on my NXC-ME. By sending a shorter program first I can get around that but I was trying to see if I could optimize things a bit and started to notice the strange behaviour above.

Thanks for any ideas

Fred

jeffaco

Not that this is directly relevant:

I've worked very hard to avoid large arrays. They do eat up memory, and fast.

Can you work around it by doing other things? For example, could you store some data on the "disk" and read in as necessary? Not as convienent, but you can store a whole lot of data there (and get larger flash cards if needed).

For the Audiotron, I used to cache large amounts of song data, and was looking at storing it on "disk" in the ME-260. But I ended up chatting with the manufacturer about it, and they ended up extending their API to give me what I needed via API. Now I just need an array sized to the number of items displayed on the touchpanel (on my system, 7 lines of text). Reduced the module to something like 1/3rd of what it was ...

Just a thought. And I hope this was at least somewhat clearer! :-)

frthomas

Originally posted by jeffaco
I've worked very hard to avoid large arrays. They do eat up memory, and fast.
Can you work around it by doing other things? For example, could you store some data on the "disk" and read in as necessary?

That's exactly what I am trying to do, and in doing so noticed the weirdness in there, hence my post.

In practice I am using arrays for an interface to a home automation bus (not AMX, a European thing called EIB). Every light in the house, every blind and every heating zone has a number of controls which are transmitted using some address. Since I want all of that on a touch panel, that's about 200 or so addresses to map between the EIB world and the Netlinx world. I can't really store the mapping table on the disk as obviously access time would be a problem...

The other thing is I have this locking mechanism we discussed and therefore every touch panel push is actually a lock command with some handling if the device to control is locked and all of that. Therefore all TP events are in large arrays, since the processing for each is the same except the device and command to send for each button.

Add to that a similar mechanism to implement feedback, i.e. something like
Addfeedback(Dev, channel, TEXTCOLOR, 4, 5, TP_dev, TP_CC), that does the same thing than having an event on [Dev, channel] that turns the color of the text of button TP_CC on TP_dev to 4 if/when [Dev, channel] is false and to 5 if/when true...
The advantage of the method is that when TP_dev comes online, I can walk over the array and refresh all feedback on the panel, and only have to implement each feedback "type" once.

All of these do create large arrays that I can't really avoid (using my particular NetLinx approach). REBUILD_EVENTS helped a lot for feedback (I dynamically create a list of DEVCHAN for all handled Dev, channel), maybe it will help as well for TP_pushes (same approach).

For the Audiotron, I used to cache large amounts of song data,

Yeah, I had the same idea in the Squeezebox XML API so that small tidbits can be digested by a "limited" control system (compared to a PC). (Squeezebox is an "open host" kind of Audiotron: www.slimdevices.com).

And I hope this was at least somewhat clearer! :-)

Crystal clear, you're making progress :-)

Thanks

Fred

DHawthorne

You can compile without debug information once your code is solid, and without a copy of the source code.

frthomas

I never compile with code as I never found the debugger particularly useful in my attempts at using it. Not that it is bad, just that maybe I do not know how to use it properly.

Fred

Spire_Jeff

I love the debugger, but I agree that there are times in which it won't work. Those times for me have fortunately been few and far between and generally involve me making an assumption of some sort. Normally tho I like the debugger to let me step through event handlers line by line and view the data as it is actually coming to the processor from the device and not how the documentation says it is supposed to arrive. This also let's me catch those little typos that will throw off a handler completely.

Just my humble opinion,

Jeff

frthomas

A bit OT, but maybe you can help me understand the thing. I get as far as setting a breakpoint in code. It seems to me there the infamous line errors occur as well, so it's not really clear which line is selected, but OK, imagine it works.

Now I have this red line in my source. Is there a way to step OVER function calls? If I go step by step, I think the debugger goes to do the function but there is no visible indication of it, the line just doesn't move... Then if I say "go" or "run" or whatever this is called, the line stays there...

Between the line errors and the lack of visible indication of what the processor is doing, I get lost very quickly... So what I typically do is to have another system where I only compile the "troublesome" bit (say the one module I am debugging, or the set or functions), and add lotsa "SEND_STRING 0," in there to get to understand the flow and which variables are in which state...

Maybe that's what they teach you in AMX training I really should go and attend!

Fred

Spire_Jeff

I feel a possible need for a new thread before this valuable information gets lost in here and then subsequently asked by someone else in a new thread. I am going to start a thread for debugging because I am sure there are parts I don't know about yet.

Jeff

HARMAN_guy.minervini

If you are declaring large arrays, it's best to declare them as VOLATILE so they don't eat up your 1M of NV Ram:
DEFINE_VARIABLE

VOLATILE CHAR MyBig2DimArrayOfStrings[64][16000]

If the variable above is not declared as VOLATILE, it will get loaded into non-volatile memory and your code won't run...