AVR Freaks

Snigelen,

That is even if R24 was used to pass in a char?

It isn't just "call-used" registers below the last passed in register? R23 down if R24 was used?

Thank you Snigilen.

I was under the mistaken impression I needed to leave the values passed into a function untouched.

That bit of news will make my life much easier and give me back six more registers to play with and not having to push/pop so much.

Well the code block has uint8_t i; just 2 lines above :)

The important point is that I can trash R24 (and R25) according to snigilen.

Just getting ready for my 23km pushbike ride to work in Brisbane.

Can't remember exactly where I picked that one up. I think it was a forum post somewhere.

But it is what lead me to wondering if he "free" register was up for grabs in the first place.

Maybe I should recommend adding to the FAQ under the call-used section "You may clobber these even those used to pass in values"

I guess seeing as other people had confusion about SREG maybe adding to the FAQ a bit about I being the only thing you have to preserve might be a good idea as well.

Skeeve - did you not read the whole thread?

We have already ascertained that the I Bit is the only thing you have to preserve.

Don,

Maybe you want to re-read this and think a bit harder.

I am pretty certain everyone should leave the I bit the way the found it. (unless it is their job to change it)

I have already said I know is NOT THE CASE now.

Everything I was saying was theoretical "could" if the compiler implementors CHOSE to do it that way. I was justifying the reason for the question in my original post.

It WAS an arbitrary decision of them to make r18:27 call-used and R2:17 call saved. The same as it was an arbitrary decision to make R1=ZERO (for what ever silly reason they decided to use the result of MUL as a constant).

They COULD have chosen to ask you to keep R24:25 the same to save a reload by the caller. AGAIN for your clarity Koschi I am saying "could have in some other parallel universe - not this one in which they didn't"

And Yes having a different rule for R24:25 on a void function than a non void one would be a different rule. Doesn't defy logic though (look at Clawsons code above and you can see how that "different rule" on a void function could save one clock for an aggressive optimiser)

I already had my answer in post 22. Everything from there down has just been "me too's" trying to get their post count up.

I have honestly never seen anywhere on the interweb with a lower signal to noise ratio than this forum.

I've had people ask me to break with standard conventions of "smallest code to reproduce a bug". Tell me you can't use a MOV instruction with registers below R16. Tell me I have to preserve SREG across a function call.

Sorry to rant at you Koshchi. Generally your, Cliffs and of course Deans posts are what I would read to know the truth when clicking in from google. I just have never HAD to ask a question in here because I normally can find answers myself in google. Now I am here I am a bit fed up with the people who think they know and want to get their "post/day" numbers up.

Is different reason from your first reason for not being logical.

I answered your first statement about logic.

Now your new statement about it being "A consequence of the C language" is a lot more sound. I can't and won't argue with that. Maybe you should have said the second statement first rather than being glib.

Your rebuttal of this is flawed and is making the assumption that the caller will always be less complex than the callee. Granted maybe there is "consequence of the C language" I am not familiar with. Though from a marginally competent ASM programmer - on the AVR architecture what you said there is outright wrong.

In fact in a good many cases where the parameter passed in is not changed at all, no copy ever needed to be made (by caller or callee). Oh except for in the case you pointed out that there already is a "full deck". Though in that case someone has to push/store and everyone is a looser.

If there is going to be a copy made why is it more expensive for the callee?

AVRs don't do out of order, have shadows, predictive branching etc. 1 instruction = 1 instruction. That is why I as just an average human can beat the compiler hands down at simple tasks.

You're starting to use emotive language there to back your arguments. Maybe take a few deep breaths before replying again.

You are NOT just trying to clear up a misconception. In post 22 I had already been set straight by Snigilen. I made it quite clear I understood how it DOES work. Way later in post 39 you where replying about how I said it could have worked if many moons ago the compiler designers had a different idea? Maybe you just didn't bother reading in your haste to hit submit. I don't know.

Oh and now I am just trying to wind you up about post 33 :)

Could no one ever have a function called?

Post half an argument to someone ignorant you can't complain about them missing the hidden point.

First time the word "unintentional" has been mentioned. You just started talking about bugs after I said you might want to change it. Thats akin to me saying now that "unintentionally clearing EEPROM location 0x17" is a bug :S

I'm still waiting to hear how a move is less efficient after an RCALL than before it? I can see how it can make life easier for the compiler/optimiser but I can't see how it can always make the target code faster. (Unless a lot of the code you write a variable is discarded straight after being used by the caller as is the case in the simple example program with blah and wibble)

Only a few weeks on the AVR-8 arch. Still enough to see that although C is powerful, it can not hope to replace ASM for things speed critical.

We should be able to get you up to 14K posts by the end of the week no worries :D