Hi,
Taking the code snippet below,
char* ptr = (char*)0x0000; short size = 0x100; short sum = 0x00; do { sum += *ptr++; } while (size--)
This will cause C51 to allocate "ptr" and "size" in RAM.
MOV R3,#00H MOV R2,#00H MOV R1,#00H MOV DPTR,#pre?1251 MOVX @DPTR,PR0 MOV DPTR,#size?1252 MOV A,#01H MOVX @DPTR,A INC DPTR CLR A MOVX @DPTR,A
and everytime "size" is decremented, or "ptr" is incremented, the values are loaded back into the RAM.
Is there a way to force C51 to not use RAM but use the registers only as "ptr" and "size" will never be used anymore after that. What I mean is, is there a way to force C51 to compile to something like this,
mov dptr, #WORD0(00h) mov r4, #01h ; r4:r5 = size mov r5, #00h mov r6, #00h ; r6:r7 = sum mov r7, #00h loop: movx A, @dptr+#000h addw 006h, A ; r6:r7 += A inc dptr subw 004h, 001h ; r4:r5-- jnc loop ; add code to store r6:r7 into RAM
Any advice would be greatly appreciated. Thanks in advance.
"Is there a way to force C51 to not use RAM ..."
You might be able to provide hints, but no absolute control.
If you want that level of control, you should consider doing some assembler.
You can try and convince the compiler to output code you like. But most likely this would be a waste of your time. Write your program in a high-level language, leave the code generation to the compiler. Yes, you may not like the code it generates, but remember: you are trying to write a working program, not a perfect program. Only begin to optimize after you've established the fact that optimization is needed. This will save you a ton of time.
when I learned 'C' back in the 90's was there not a 'C' thing called 'register'?
Erik
"when I learned 'C' back in the 90's was there not a 'C' thing called 'register'?"
It's still there - But it's still only a hint to the compiler.
You probably mean this thing: http://www.keil.com/support/man/docs/c51/c51_le_register.htm
Ignored by the compiler.
The starting text in that link said "should be stored".
But it was just added as a hint, letting a developer put some extra priority on the decisions of what variables to allocate to registers.
It was only applicable when compilers were dumb and variables lived in memory or in registers for the full lifetime of a function.
Todays compilers performs huge amounts of lifetime analysis and other optimization steps, so a variable may sometimes be stored in a register, and at other times be stored in RAM. It's just a question of what the compiler have found to be the most efficient alternative for the different parts of the code.
Most newer compilers sees it as a dummy keyword to 100% ignore. We have the volatile keyword to force memory accesses. And we have the optimization flags to tell how much work we want the compiler to spend on tweaking the actual code generated.
Most newer compilers sees it as a dummy keyword to 100% ignore.
I'm quite sure that's untrue because otherwise most newer compilers would be defective. register still has ssome required semantic effect that compiler writers are not at liberty to ignore: it forbids taking address of any object so qualified, and code violating that rule has to be diagnosed. To do that, the compiler must heed the register keyword.
Not exactly. Suppose you specify 10 register variables? How many get used depends on the number available. Even worse you only specify 1 register variables. The compiler uses them all then what? An Error? You move some code around an now it is OK. The register keyword never guaranteed that a variable would be in a register. Only that it would be nice if it were.
Is it ANSI required?
Thank you everyone for the information. I have tried using the 'register' keyword before posting the question here but so far it is ignored by the compiler. By manually writing in assembly using registers, I manage to speed up the task by 50%. However it would be tedious to do so as the reason to use C is to simplify coding. I really hope there is a way to ask the compiler do what is needed.
"Is it ANSI required?"
The keyword must be processed according to the standard, which means it does mean something gramatically. But most new compilers totally ignore it for the code generation phase.
No, it won't. Not unless you avoid turning on optimization or use a horribly wrong memory model.
addw 006h, A ; r6:r7 += A
Surely you're aware that no machine instruction like 'addw' exists in an 8051, right? And that, the 8051 being a so-called accumulator-based design, the target of all arithmetic machine instruction is the accumulator, not some memory address?
Oh, and if you're looking for efficient code, why are you using generic pointers?
But does the taks actually need to be speeded up by 50% - or, indeed, at all?
"However it would be tedious"
So, unless it is really essential, don't do it!
As has already been suggested, if the performance is adequate, there is no point in messing about trying to optimise it!
It is also an 8-bit processor - which means that multibyte operations have to be coded using multiple single-byte instructions.
If high performance of multibyte operations is a key requirement of your application, then you should seriously reconsider whether the 8051 is an appropriate choice...
Thanks for pointing that out but the chip I'm using supports additional extended instruction set which includes addw and it costs 3 machine cycles. Also since R0 - R7 is mapped to offset 0 to 7 of idata, I decided to access it directly.
I'm using a generic pointer because the address is a far address.
Also, the optimization option is enabled and if I never increment the pointer, the pointer will be kept in the register.
the chip I'm using supports additional extended instruction set
Aha. And the reason you had to keep that crucial bit of information to yourself all this time was ...?
And how were you planning on convincing the compiler that
(char *)0x0000
is something other than a not-far-at-all idata pointer?