Prev: Which type of volatile RAM has the least duration of data remanence when power-offed?
Next: aliasing error question
From: narke on 14 May 2010 04:11
On Fri, 14 May 2010 19:24:47 +1200, Ian Collins <ian-news(a)hotmail.com>
wrote:

>On 05/14/10 06:59 PM, io_x wrote:
>> "narke"<narkewoody(a)gmail.com> ha scritto nel messaggio
>> news:fv0ou5lu8t3m8m1i7kkn5j7e0ou1dvot14(a)4ax.com...
>>> Hi,
>>>
>>> I have a big code, and I cannot get understand some parts of it. Below
>>> is a piece of them:
>>>
>>> void determind_corr_value(void)
>>> {
>>> int8_t Leading0;
>>> uint32_t CorrValue;
>>>
>>> ...
>>>
>>> if( CorrValue>0)
>>> {
>>> // Detect bit number of MSB of CorrValue (Leading 0's are
>>> counted)
>>> Leading0 = 1;
>>>
>>> while(!(*((int16_t*)&CorrValue + 1)< 0)) // MS_Bit = 0
>>> {
>>> CorrValue<<= 1;
>>> Leading0++;
>>> }
>>
>> i don't see why not write it in this way
>> %define MS_Bit 0x00008000
>>
>Why use a macro when a const uint32_t would do?

The name of macro removes the need for a comment :)

>
>> while((CorrValue& MS_Bit)==0)
>> {CorrValue<<= 1;
>> Leading0++;
>> if(CorrValue==0) return error2349;
>> }
From: William Hughes on 14 May 2010 07:30
On May 14, 4:20 am, narke <narkewo...(a)gmail.com> wrote:
> On Thu, 13 May 2010 10:07:00 -0700 (PDT), William Hughes
>
>
>
> <wpihug...(a)hotmail.com> wrote:
> >On May 13, 11:00?am, narke <narkewo...(a)gmail.com> wrote:
> >> Hi,
>
> >> I have a big code, and I cannot get understand some parts of it. Below
> >> is a piece of them:
>
> >> void determind_corr_value(void)
> >> {
> >> ? ?int8_t Leading0;
> >> ? ?uint32_t CorrValue;
>
> >> ? ?...
>
> >> ? ?if( CorrValue>0)
> >> ? ?{
> >> ? ? ? // Detect bit number of MSB of CorrValue (Leading 0's are
> >> counted)
> >> ? ? ? Leading0 = 1;
>
> >> ? ? ? while(!(*((int16_t*) &CorrValue + 1) < 0)) ? // MS_Bit = 0
> >> ? ? ? {
> >> ? ? ? ? ?CorrValue <<= 1;
> >> ? ? ? ? ?Leading0++;
> >> ? ? ? }
>
> >> ? ? ? Leading0 -= 8;
>
> >> ? ? ? // increase the resolution for compensation steps to 0.5Bit by
> >> checking the 2nd bit
> >> ? ? ? //lint -save -e701
> >> ? ? ? Leading0 <<= 1;
> >> ? ? ? if(*((int16_t*) &CorrValue + 1) & 0x4000)
> >> ? ? ? {
> >> ? ? ? ? ?Leading0--;
> >> ? ? ? }
>
> >> ? ? ? // Calculate now the correction value
> >> ? ? ? if( Current < CalibrationData.I_Limit_Corr) {
> >> ? ? ? ? ?// low range
> >> ? ? ? ? ?Leading0-= (int8_t)Data.Leading0_Corr_Low;
>
> >> ? ? ? ? ?CorrValue = (unsigned)(long)(32768L + ((int16_t)
> >> (CalibrationData.Correction_Low * Leading0)));
> >> ? ? ? } else {
> >> ? ? ? ? ?// High range
> >> ? ? ? ? ?Leading0-= (int8_t)Data.Leading0_Corr_High;
>
> >> ? ? ? ? ?CorrValue = (unsigned)(long)(32768L + ((int16_t)
> >> (CalibrationData.Correction_High * Leading0)));
> >> ? ? ? }
>
> >> ? ?} else
> >> ? ? ? CorrValue = 32768;
>
> >> ? ?...
>
> >> }
>
> >> I guess it was doing some kind of DSP, but not sure what was exactly
> >> going on.
>
> >This is horrible.  Basically the idea is to take a 16 bit
> >CorrValue (stored in the second half of a 32 bit integer)
> >and use it to choose one of 32 correction values.
>
> Interesting!  Why do you think the second part of the CorrValue is an
> index and where are the 32 correction values?
>
>
>
> >There is also a sort of a truncated log transform.  The
> >coder had decided to use bit manipulation, probably as
> >a dubious offering to the great god efficiency.
> >It also has the feel of 16 bit code shoehorned into
> >a 32 bit system.
>
> God, you are righ!  the microprocess had upgraded from 16bit to 32bit
> long time ago, so the original 16bit code had been ported to 32bit.
>
> I want to know more about what you said, log transform.  I mean, I do
> know what is logarithm transform but I can not identify where is the
> logarithm operation in the code. Can you help?


The transform is (more or less)

correction_value =
middle_value + 2*(MSB-8)*step_value

MSB can only take on one of 32 values. Note that
MSB= C log(Corr_Value) for some constant C.
This is a log transform.

Things are not quite a simple as the above
(for example step_value has one of two values)


Use this code *for anything* (including finding
out what needs to be done) only under duress
(e.g. the code is all there is).

Find out who originally wrote this code.
Hunt him down and kill him.

Find out who ported this code. Hunt him/her
down and cause serious pain.

Find out what transform is needed, then code
it directly.


>
>
>
> >If there is any way you can get away from this
> >code do so. Find out what needs to be done and code
> >from scratch.
>
> >> ?Especially, I hope some one have a guess and give me some
> >> hints for my below questions so far:
>
> >> 1. Why Leading0 was assigned as 1 at begin of the process.
>
> >Leading0 starts out as the MSB.  The MSB starts at 1.
>
> I don't get it.  By 'MSB starts at 1', did you mean the position of
> the MSB is the second couting from left? So, how will you call the
> first bit counting from left?
>
>

No the first position from the left is called 1, not 0.
The MSB numbering makes little sense anyway. Why expect
it to use 0 indexing.
>
> >> 2. Why 8 was substracted from the Leading0
>
> >Leading 0 has to become a signed quantity.  If
> >the MSB is small, then the correction value will
> >be less than 32768  and Leading0 has to be negative.
> >Note the correction value will be changed
> >by some multiple of the (shifted) MSB.  This
> >is a log transform.
>
> Fully don't understand.  Could you explain in more detail?
>
>
>
> >> 3. What means 0.5bit and checking for 2nd bit?
>
> >Rather that using one bit (16 possible positions)
> >the code uses two bits (32 possible positions)
>
> why:
> one bit --> 16
> two bit --> 32
>

The MSB bit can be in 16 places. For each the next bit
can be 0 or 1.

- William Hughes



From: io_x on 14 May 2010 10:38

"Ian Collins" <ian-news(a)hotmail.com> ha scritto nel messaggio
news:854c5vF5noU2(a)mid.individual.net...
> On 05/14/10 06:59 PM, io_x wrote:
>> "narke"<narkewoody(a)gmail.com> ha scritto nel messaggio
>> news:fv0ou5lu8t3m8m1i7kkn5j7e0ou1dvot14(a)4ax.com...
>>> Hi,
>>>
>>> I have a big code, and I cannot get understand some parts of it. Below
>>> is a piece of them:
>>>
>>> void determind_corr_value(void)
>>> {
>>> int8_t Leading0;
>>> uint32_t CorrValue;
>>>
>>> ...
>>>
>>> if( CorrValue>0)
>>> {
>>> // Detect bit number of MSB of CorrValue (Leading 0's are
>>> counted)
>>> Leading0 = 1;
>>>
>>> while(!(*((int16_t*)&CorrValue + 1)< 0)) // MS_Bit = 0
>>> {
>>> CorrValue<<= 1;
>>> Leading0++;
>>> }
>>
>> i don't see why not write it in this way
>> %define MS_Bit 0x00008000
>>
> Why use a macro when a const uint32_t would do?

because i not like "const"; yes it should be better if i write
%define MS_Bit 0x00008000
functionsThatUseAboveMacro()
....
functionsThatUseAboveMacro1()
....
functionsThatUseAboveMacro2()
....
functionsThatUseAboveMacro3()
%undef MS_Bit


>> while((CorrValue& MS_Bit)==0)
>> {CorrValue<<= 1;
>> Leading0++;
>> if(CorrValue==0) return error2349;
>> }
>
> --
> Ian Collins



From: Ian Collins on 14 May 2010 16:47
On 05/15/10 02:38 AM, io_x wrote:
> "Ian Collins"<ian-news(a)hotmail.com> ha scritto nel messaggio
> news:854c5vF5noU2(a)mid.individual.net...
>>
>> Why use a macro when a const uint32_t would do?
>
> because i not like "const"; yes it should be better if i write
> %define MS_Bit 0x00008000
> functionsThatUseAboveMacro()
> ....
> functionsThatUseAboveMacro1()
> ....
> functionsThatUseAboveMacro2()
> ....
> functionsThatUseAboveMacro3()
> %undef MS_Bit

Why? MS_Bit is a const uint32_t, so why not declare it as one?

#define really should be reserved for compile time constants when an
enum value can't be used.

--
Ian Collins
From: narke on 15 May 2010 22:49
["Followup-To:" header set to comp.lang.c.]
On 2010-05-14, William Hughes <wpihughes(a)hotmail.com> wrote:
> On May 14, 4:20m, narke <narkewo...(a)gmail.com> wrote:
>> On Thu, 13 May 2010 10:07:00 -0700 (PDT), William Hughes
>>
>>
>>
>> <wpihug...(a)hotmail.com> wrote:
>> >On May 13, 11:00?am, narke <narkewo...(a)gmail.com> wrote:
>> >> Hi,
>>
>> >> I have a big code, and I cannot get understand some parts of it. Below
>> >> is a piece of them:
>>
>> >> void determined_corr_value(void)
>> >> {
>> >> ? ?int8_t Leading0;
>> >> ? ?uint32_t CorrValue;
>>
>> >> ? ?...
>>
>> >> ? ?if( CorrValue>0)
>> >> ? ?{
>> >> ? ? ? // Detect bit number of MSB of CorrValue (Leading 0's are
>> >> counted)
>> >> ? ? ? Leading0 = 1;
>>
>> >> ? ? ? while(!(*((int16_t*) &CorrValue + 1) < 0)) ? // MS_Bit = 0
>> >> ? ? ? {
>> >> ? ? ? ? ?CorrValue <<= 1;
>> >> ? ? ? ? ?Leading0++;
>> >> ? ? ? }
>>
>> >> ? ? ? Leading0 -= 8;
>>
>> >> ? ? ? // increase the resolution for compensation steps to 0.5Bit by
>> >> checking the 2nd bit
>> >> ? ? ? //lint -save -e701
>> >> ? ? ? Leading0 <<= 1;
>> >> ? ? ? if(*((int16_t*) &CorrValue + 1) & 0x4000)
>> >> ? ? ? {
>> >> ? ? ? ? ?Leading0--;
>> >> ? ? ? }
>>
>> >> ? ? ? // Calculate now the correction value
>> >> ? ? ? if( Current < CalibrationData.I_Limit_Corr) {
>> >> ? ? ? ? ?// low range
>> >> ? ? ? ? ?Leading0-= (int8_t)Data.Leading0_Corr_Low;
>>
>> >> ? ? ? ? ?CorrValue = (unsigned)(long)(32768L + ((int16_t)
>> >> (CalibrationData.Correction_Low * Leading0)));
>> >> ? ? ? } else {
>> >> ? ? ? ? ?// High range
>> >> ? ? ? ? ?Leading0-= (int8_t)Data.Leading0_Corr_High;
>>
>> >> ? ? ? ? ?CorrValue = (unsigned)(long)(32768L + ((int16_t)
>> >> (CalibrationData.Correction_High * Leading0)));
>> >> ? ? ? }
>>
>> >> ? ?} else
>> >> ? ? ? CorrValue = 32768;
>>
>> >> ? ?...
>>
>> >> }
>>
>> >> I guess it was doing some kind of DSP, but not sure what was exactly
>> >> going on.
>>
>> >This is horrible. Basically the idea is to take a 16 bit
>> >CorrValue (stored in the second half of a 32 bit integer)
>> >and use it to choose one of 32 correction values.
>>
>> Interesting! Why do you think the second part of the CorrValue is an
>> index and where are the 32 correction values?
>>
>>
>>
>> >There is also a sort of a truncated log transform. The
>> >coder had decided to use bit manipulation, probably as
>> >a dubious offering to the great god efficiency.
>> >It also has the feel of 16 bit code shoehorned into
>> >a 32 bit system.
>>
>> God, you are right! The microprocessor had upgraded from 16bit to 32bit
>> long time ago, so the original 16bit code had been ported to 32bit.
>>
>> I want to know more about what you said, log transform. I mean, I do
>> know what is logarithm transform but I can not identify where is the
>> logarithm operation in the code. Can you help?
>
>
> The transform is (more or less)
>
> correction_value =
> middle_value + 2*(MSB-8)*step_value

Many thanks, I now begin to understand the transform. MSB here actually defined
as: 32 - int(log2(correction_value)). Am I right? And, inspired from the name
'step_value', I think it would be better to call it 'scale_value', how do you
think it?

Another question is 'middle_value' (thanks for the name). As you seen,
middle_value here is 32768, it looks like middle value of 2^16. But, why
choice so although correct_value is a unsigned 32bit integer?

That finally question about the equation is that: what likely is the true
purpose of the transform? Is there a mathematic model behind it? Do you have any
guess if I tell you the 'correct_value' is initially a RMS current value?

>
> MSB can only take on one of 32 values. Note that
> MSB= C log(Corr_Value) for some constant C.
> This is a log transform.
>
> Things are not quite a simple as the above
> (for example step_value has one of two values)
>
>
> Use this code *for anything* (including finding
> out what needs to be done) only under duress
> (e.g. the code is all there is).
>
> Find out who originally wrote this code.
> Hunt him down and kill him.
>
> Find out who ported this code. Hunt him/her
> down and cause serious pain.
>
> Find out what transform is needed, then code
> it directly.
>
>
>>
>>
>>
>> >If there is any way you can get away from this
>> >code do so. Find out what needs to be done and code
>> >from scratch.
>>
>> >> ?Especially, I hope some one have a guess and give me some
>> >> hints for my below questions so far:
>>
>> >> 1. Why Leading0 was assigned as 1 at begin of the process.
>>
>> >Leading0 starts out as the MSB. The MSB starts at 1.
>>
>> I don't get it. Why 'MSB starts at 1', did you mean the position of
>> the MSB is the second counting from left? So, how will you call the
>> first bit counting from left?
>>
>>
>
> No the first position from the left is called 1, not 0.
> The MSB numbering makes little sense anyway. Why expect
> it to use 0 indexing.
>>
>> >> 2. Why 8 was subtracted from the Leading0
>>
>> >Leading 0 has to become a signed quantity. If
>> >the MSB is small, then the correction value will
>> >be less than 32768 And Leading0 has to be negative.
>> >Note the correction value will be changed
>> >by some multiple of the (shifted) MSB. This
>> >is a log transform.
>>
>> Fully don't understand. Would you explain in more detail?
>>
>>
>>
>> >> 3. What means 0.5bit and checking for 2nd bit?
>>
>> >Rather that using one bit (16 possible positions)
>> >the code uses two bits (32 possible positions)
>>
>> why:
>> one bit --> 16
>> two bit --> 32
>>
>
> The MSB bit can be in 16 places. For each the next bit
> can be 0 or 1.

Are you sure? It should be: the MSB bit can be in *32* places, and for each the
next bit can be 0 or 1.

>
> - William Hughes
>
>
>
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Which type of volatile RAM has the least duration of data remanence when power-offed?
Next: aliasing error question