We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Dear all, I encountered one problem about "executing self-defined 32bit shift-left routine too long"...
That is, I built my own routine to execute 32-bit shift left operation and found it takes too long(Due to some reason 32bit shift left is NOT allowed in my project currently...)
[code body]
UINT32 ShiftLeft32Bits(UINT32 Operand, UINT8 ShiftValue){ bit Carry; OperandDW = Operand; while(ShiftValue>0){ Carry=0; if(OperandDWLo&0x8000) Carry=1; OperandDWLo<<=1; OperandDWHi = (OperandDWHi<<1) | Carry; ShiftValue-=1; } return OperandDW; }
[Statistics] if "Operand = ShiftLeft32Bits(x1, 31);" => cost 60us ( where Operand,x1 are 4-byte xdata variables)
My question is: is it possible to "optimize" above code segments(favor speed) ? Thanks in advance...
p.s I am implementing sha256 calculation...
What reason, exactly?
It's impossible to give appropriate suggestions when you don't supply all the relevant information!
What is the time "cost" of just using the standard 'C' shift operator?
Dear all, The reason why 32-bit shift left(<<) is not allowed in my project is:
#1 our code is composed of 2 parts; one is stored in ROM and the other is in SRAM. #2 if use operator << within code then after compile/link the ROM part changed and this is not allowed because ?C?LIB_CODE is bigger than before...
* ?C?LIB_CODE is assigned in ROM part always in my project
#2 causes mismatch between original ROM part & new SRAM code; then firmware operates abnormally...
To sum up, we did not include lib for 32bit shift-left operation in the early development but now we have to use it...
And that assignment is wrong. It's as simple as that.
You're going at this from entirely the wrong direction. The problem is that you're trying something for which an 8051 is a disastrously wrong choice of CPU architecture, and now you're trying silly things to cure the symptoms, instead of fixing the actual problem.
Splitting programs into a ROM part and variable "add-ons" is extremely tricky business in C on an 8051. I should know --- I've worked in a project where we did this in pure assembly, and that was quite a nightmare already. Getting C51 to jump through those same hoops would be even worse.
You've basically built yourself a solid wall and now you keep running head-first into it instead of considering that it might hurt less if there was a hole to pass through. Might want to call it "door".
I assume the the OP is running into the old problem of having responsibility without authority, i.e. it's his job to fix the problem, but he doesn't have the authority to implement the effective, straightforward solution.