BCD List to HEX List
Hi, I'm looking for an algo that would convert a list such as: I'm using python to prototype the algo: this will move to C in an embedded system where an int has 16 bits - I do not wish to use any python library. l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 l2 = func (l1) # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
In <[EMAIL PROTECTED]>, Philippe Martin wrote: > I'm looking for an algo that would convert a list such as: > > I'm using python to prototype the algo: this will move to C in an embedded > system where an int has 16 bits - I do not wish to use any python library. > > l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 > l2 = func (l1) > # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 def func(x): result = list(x) result[2:4] = [0xd] result[-1], result[-2] = result[-2], result[-1] return result l1 = [1, 2, 3, 4, 6, 7, 8] l2 = func(l1) print l2 And now please describe you problem a little better. ;-) Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Philippe Martin wrote:
>
>> I'm looking for an algo that would convert a list such as:
>>
>> I'm using python to prototype the algo: this will move to C in an
>> embedded system where an int has 16 bits - I do not wish to use any
>> python library.
>>
>> l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678
>> l2 = func (l1)
>> # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687
>
> def func(x):
> result = list(x)
> result[2:4] = [0xd]
> result[-1], result[-2] = result[-2], result[-1]
> return result
>
> l1 = [1, 2, 3, 4, 6, 7, 8]
> l2 = func(l1)
> print l2
>
> And now please describe you problem a little better. ;-)
>
> Ciao,
> Marc 'BlackJack' Rintsch
I'll try.
first of all python is not going to be used for my purpose (sigh)
I have device A which holds a binary coded decimal array [N1,N2,Nn]
where the array represents a decimal number.
In C: unsigned char dec[] = {1,2,3,4,5,6,7,8};
I need that array converted for device B into an array where each element
represents the actual byte value.
In C: the result would be unsigned char hex[] = {0x1,0x2,0xD,0x6,0x8,0x7};
I guess any pocket calculator goes through that process for dec/hex
conversion.
Hope that's clearer.
Regards,
Philippe
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
In <[EMAIL PROTECTED]>, Philippe Martin wrote:
> Marc 'BlackJack' Rintsch wrote:
>
>> And now please describe you problem a little better. ;-)
>
> I'll try.
>
> first of all python is not going to be used for my purpose (sigh)
>
> I have device A which holds a binary coded decimal array [N1,N2,Nn]
> where the array represents a decimal number.
>
> In C: unsigned char dec[] = {1,2,3,4,5,6,7,8};
>
> I need that array converted for device B into an array where each element
> represents the actual byte value.
>
> In C: the result would be unsigned char hex[] = {0x1,0x2,0xD,0x6,0x8,0x7};
>
> I guess any pocket calculator goes through that process for dec/hex
> conversion.
>
> Hope that's clearer.
Not really. Maybe I'm missing something obvious but I don't see the link
between your `dec` and `hex` values. 12345678 converted to hex is
bc614e. Do you need such a conversion? And should the result really be
one nibble (4 bit)/hex digit per array entry!?
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Philippe Martin wrote:
>
>> Marc 'BlackJack' Rintsch wrote:
>>
>>> And now please describe you problem a little better. ;-)
>>
>> I'll try.
>>
>> first of all python is not going to be used for my purpose (sigh)
>>
>> I have device A which holds a binary coded decimal array [N1,N2,Nn]
>> where the array represents a decimal number.
>>
>> In C: unsigned char dec[] = {1,2,3,4,5,6,7,8};
>>
>> I need that array converted for device B into an array where each element
>> represents the actual byte value.
>>
>> In C: the result would be unsigned char hex[] =
>> {0x1,0x2,0xD,0x6,0x8,0x7};
>>
>> I guess any pocket calculator goes through that process for dec/hex
>> conversion.
>>
>> Hope that's clearer.
>
> Not really. Maybe I'm missing something obvious but I don't see the link
> between your `dec` and `hex` values. 12345678 converted to hex is
> bc614e. Do you need such a conversion? And should the result really be
> one nibble (4 bit)/hex digit per array entry!?
>
> Ciao,
> Marc 'BlackJack' Rintsch
My apologies, I clearly made a mistake with my calculator, yes the resulting
array I would need is [0xb,0xc,0x6,0x1,0x4,0xe]
Regards,
Philippe
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > Hi, > > I'm looking for an algo that would convert a list such as: Such as what? > > I'm using python to prototype the algo: this will move to C in an embedded > system where an int has 16 bits - I do not wish to use any python library. > > l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 Does it??? How do you represent the decimal number 12349678, then? > l2 = func (l1) > # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 > I'm sorry, but very little of that makes any sense to me: 1. I thought BCD meant something very much like this: http://en.wikipedia.org/wiki/Binary-coded_decimal 2. >>> [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 [1, 2, 13, 6, 8, 7] So [1], [2], [6] are unchanged, [3, 4] -> [13] (or maybe [3, 4, 5] -> 13), and [7, 8] -> [8,7]. I doubt very much that there's an algorithm to do that. What is the relationship between 1234(maybe 5)678 and 0x12D687??? I would expect something like this:: 0x12345678 (stored in 4 bytes 0x12, ..., 0x78) -- or 0x21436587 or 0x012345678s (where s is a "sign" nibble; stored in 5 bytes 0x01, ..., 0x8s) IOW something regular and explicable ... 3. Perhaps it might be a good idea if you told us what the *real* problem is, including *exact* quotes from the manual for the embedded system. You evidently need/want to convert from one representation of signed? unsigned? integers to another. Once we all understand *what* those representations are, *then* we can undoubtedly help you with pseudocode in the form of Python code manipulating lists or whatever. Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > Philippe Martin wrote: >> Hi, >> >> I'm looking for an algo that would convert a list such as: > > Such as what? > >> >> I'm using python to prototype the algo: this will move to C in an >> embedded system where an int has 16 bits - I do not wish to use any >> python library. >> >> l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 > > Does it??? How do you represent the decimal number 12349678, then? > >> l2 = func (l1) >> # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 >> > > I'm sorry, but very little of that makes any sense to me: > > 1. I thought BCD meant something very much like this: > http://en.wikipedia.org/wiki/Binary-coded_decimal > > 2. >>> [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 > [1, 2, 13, 6, 8, 7] > > So [1], [2], [6] are unchanged, [3, 4] -> [13] (or maybe [3, 4, 5] -> > 13), and [7, 8] -> [8,7]. > > I doubt very much that there's an algorithm to do that. What is the > relationship between 1234(maybe 5)678 and 0x12D687??? I would expect > something like this:: > > 0x12345678 (stored in 4 bytes 0x12, ..., 0x78) -- or 0x21436587 > or > 0x012345678s (where s is a "sign" nibble; stored in 5 bytes 0x01, > ..., 0x8s) > > IOW something regular and explicable ... > > 3. Perhaps it might be a good idea if you told us what the *real* > problem is, including *exact* quotes from the manual for the embedded > system. You evidently need/want to convert from one representation of > signed? unsigned? integers to another. Once we all understand *what* > those representations are, *then* we can undoubtedly help you with > pseudocode in the form of Python code manipulating lists or whatever. > > Cheers, > John Hi, >From my answer to Marc: >My apologies, I clearly made a mistake with my calculator, yes the >resulting >array I would need is [0xb,0xc,0x6,0x1,0x4,0xe] Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin <[EMAIL PROTECTED]> writes:
> I'm using python to prototype the algo: this will move to C in an embedded
> system where an int has 16 bits - I do not wish to use any python library.
>
> l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678
This is untested, but should give you the idea:
First, convert that list to a decimal digit string:
s = ''.join(map(str, l1))
Then convert the string to an integer:
n = int(s)# base 10 is the default
Then convert the integer to a hex digit string:
h = '%X' % n
Finally, convert the hex digit string to a list of integer values of the
individual digits:
vlist = [int(d, 16) for d in h]
This is the list you want.
If you prefer, You can do it all in one line:
vlist = [int(d, 16) for d in ('%X' % int(''.join(map(str, l1]
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Paul Rubin wrote:
> Philippe Martin <[EMAIL PROTECTED]> writes:
>> I'm using python to prototype the algo: this will move to C in an
>> embedded system where an int has 16 bits - I do not wish to use any
>> python library.
>>
>> l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678
>
> This is untested, but should give you the idea:
>
> First, convert that list to a decimal digit string:
>
>s = ''.join(map(str, l1))
>
> Then convert the string to an integer:
>
>n = int(s)# base 10 is the default
>
> Then convert the integer to a hex digit string:
>
>h = '%X' % n
>
> Finally, convert the hex digit string to a list of integer values of the
> individual digits:
>
>vlist = [int(d, 16) for d in h]
>
> This is the list you want.
>
> If you prefer, You can do it all in one line:
>
>vlist = [int(d, 16) for d in ('%X' % int(''.join(map(str, l1]
Thanks Paul,
I'm just using Python to prototype, so I cannot use any of these great
features of the language.
Regards,
Philippe
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > John Machin wrote: > > > Philippe Martin wrote: > >> Hi, > >> > >> I'm looking for an algo that would convert a list such as: > > > > Such as what? > > > >> > >> I'm using python to prototype the algo: this will move to C in an > >> embedded system where an int has 16 bits - I do not wish to use any > >> python library. > >> > >> l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 > > > > Does it??? How do you represent the decimal number 12349678, then? > > > >> l2 = func (l1) > >> # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 > >> > > > > I'm sorry, but very little of that makes any sense to me: > > > > 1. I thought BCD meant something very much like this: > > http://en.wikipedia.org/wiki/Binary-coded_decimal > > > > 2. >>> [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 > > [1, 2, 13, 6, 8, 7] > > > > So [1], [2], [6] are unchanged, [3, 4] -> [13] (or maybe [3, 4, 5] -> > > 13), and [7, 8] -> [8,7]. > > > > I doubt very much that there's an algorithm to do that. What is the > > relationship between 1234(maybe 5)678 and 0x12D687??? I would expect > > something like this:: > > > > 0x12345678 (stored in 4 bytes 0x12, ..., 0x78) -- or 0x21436587 > > or > > 0x012345678s (where s is a "sign" nibble; stored in 5 bytes 0x01, > > ..., 0x8s) > > > > IOW something regular and explicable ... > > > > 3. Perhaps it might be a good idea if you told us what the *real* > > problem is, including *exact* quotes from the manual for the embedded > > system. You evidently need/want to convert from one representation of > > signed? unsigned? integers to another. Once we all understand *what* > > those representations are, *then* we can undoubtedly help you with > > pseudocode in the form of Python code manipulating lists or whatever. > > > > Cheers, > > John > > > Hi, > > From my answer to Marc: > > >My apologies, I clearly made a mistake with my calculator, yes the > >resulting > >array I would need is [0xb,0xc,0x6,0x1,0x4,0xe] > "Clearly"? I don't think that word means what you think it means :-) All you need is something like the following. You will need to use "long" if the C "int" is only 16 bits. C:\junk>type bcd.py def reconstitute_int(alist): reg = 0 # reg needs to be 32-bits (or more) for digit in alist: assert 0 <= digit <= 9 reg = reg * 10 + digit return reg def make_hex(anint): # anint needs to be 32-bits (or more) result = [] while anint: result.append(anint & 0xF) anint >>= 4 return result def reverse_list(alist): n = len(alist) for i in xrange(n >> 1): reg1 = alist[n - 1 - i] reg2 = alist[i] alist[i] = reg1 alist[n - 1 - i] = reg2 C:\junk> C:\junk>python Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import bcd >>> num = bcd.reconstitute_int([1,2,3,4,5,6,7,8]) >>> num 12345678 >>> result = bcd.make_hex(num) >>> result [14, 4, 1, 6, 12, 11] >>> bcd.reverse_list(result) >>> result [11, 12, 6, 1, 4, 14] >>> ['0x%x' % digit for digit in result] ['0xb', '0xc', '0x6', '0x1', '0x4', '0xe'] >>> ^Z HTH, John -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > Philippe Martin wrote: >> John Machin wrote: >> >> > Philippe Martin wrote: >> >> Hi, >> >> >> >> I'm looking for an algo that would convert a list such as: >> > >> > Such as what? >> > >> >> >> >> I'm using python to prototype the algo: this will move to C in an >> >> embedded system where an int has 16 bits - I do not wish to use any >> >> python library. >> >> >> >> l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 >> > >> > Does it??? How do you represent the decimal number 12349678, then? >> > >> >> l2 = func (l1) >> >> # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 >> >> >> > >> > I'm sorry, but very little of that makes any sense to me: >> > >> > 1. I thought BCD meant something very much like this: >> > http://en.wikipedia.org/wiki/Binary-coded_decimal >> > >> > 2. >>> [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 >> > [1, 2, 13, 6, 8, 7] >> > >> > So [1], [2], [6] are unchanged, [3, 4] -> [13] (or maybe [3, 4, 5] -> >> > 13), and [7, 8] -> [8,7]. >> > >> > I doubt very much that there's an algorithm to do that. What is the >> > relationship between 1234(maybe 5)678 and 0x12D687??? I would expect >> > something like this:: >> > >> > 0x12345678 (stored in 4 bytes 0x12, ..., 0x78) -- or 0x21436587 >> > or >> > 0x012345678s (where s is a "sign" nibble; stored in 5 bytes 0x01, >> > ..., 0x8s) >> > >> > IOW something regular and explicable ... >> > >> > 3. Perhaps it might be a good idea if you told us what the *real* >> > problem is, including *exact* quotes from the manual for the embedded >> > system. You evidently need/want to convert from one representation of >> > signed? unsigned? integers to another. Once we all understand *what* >> > those representations are, *then* we can undoubtedly help you with >> > pseudocode in the form of Python code manipulating lists or whatever. >> > >> > Cheers, >> > John >> >> >> Hi, >> >> From my answer to Marc: >> >> >My apologies, I clearly made a mistake with my calculator, yes the >> >resulting >> >array I would need is [0xb,0xc,0x6,0x1,0x4,0xe] >> > > "Clearly"? I don't think that word means what you think it means :-) > > All you need is something like the following. You will need to use > "long" if the C "int" is only 16 bits. > > C:\junk>type bcd.py > def reconstitute_int(alist): > reg = 0 # reg needs to be 32-bits (or more) > for digit in alist: > assert 0 <= digit <= 9 > reg = reg * 10 + digit > return reg > > def make_hex(anint): > # anint needs to be 32-bits (or more) > result = [] > while anint: > result.append(anint & 0xF) > anint >>= 4 > return result > > def reverse_list(alist): > n = len(alist) > for i in xrange(n >> 1): > reg1 = alist[n - 1 - i] > reg2 = alist[i] > alist[i] = reg1 > alist[n - 1 - i] = reg2 > > C:\junk> > C:\junk>python > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] > on win32 > Type "help", "copyright", "credits" or "license" for more information. import bcd num = bcd.reconstitute_int([1,2,3,4,5,6,7,8]) num > 12345678 result = bcd.make_hex(num) result > [14, 4, 1, 6, 12, 11] bcd.reverse_list(result) result > [11, 12, 6, 1, 4, 14] ['0x%x' % digit for digit in result] > ['0xb', '0xc', '0x6', '0x1', '0x4', '0xe'] ^Z > > HTH, > John Thanks John, I do not have a long available on the device: stuck with 16 bits. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Dennis Lee Bieber wrote: > On Sun, 30 Jul 2006 16:39:47 -0500, Philippe Martin > <[EMAIL PROTECTED]> declaimed the following in comp.lang.python: > >> >> My apologies, I clearly made a mistake with my calculator, yes the >> resulting array I would need is [0xb,0xc,0x6,0x1,0x4,0xe] >> > Take note that this is NOT a BCD form for "12345678". BCD (typically > packed) uses four bits per decimal digit. That would make "12345678" => > 0x12, 0x34, 0x56, 0x78 (ignoring matters of big/little end). > > The binary representation of 12345678, in bytes, is 0xBC, 0x61, 0x4E > > 0xb, 0xc... is really 0x0B, 0x0C... 8-bits per byte, with MSB set to > . > > Compare: > BCD 00010010 00110100 01010110 0000 > binary1000 0111 01001110 > your 1011 1100 0110 0001 0100 1110 > -- > Wulfraed Dennis Lee Bieber KD6MOG > [EMAIL PROTECTED] [EMAIL PROTECTED] > HTTP://wlfraed.home.netcom.com/ > (Bestiaria Support Staff: [EMAIL PROTECTED]) > HTTP://www.bestiaria.com/ Yes I realized that after writing it. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin <[EMAIL PROTECTED]> writes: > I'm just using Python to prototype, so I cannot use any of these great > features of the language. I think when writing a prototype, you should use whatever features you want, except maybe at the upper levels of program organization. The idea of prototyping is to get something done quickly, that you can use for integration and user testing earlier in the development cycle. So you should use whatever Python features are available to make prototyping faster. You shouldn't expect the prototype code to closely match the final C code, if that slows you down. If you want code that closely resembles C code, you might as well write in C directly. -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Paul Rubin wrote: > Philippe Martin <[EMAIL PROTECTED]> writes: >> I'm just using Python to prototype, so I cannot use any of these great >> features of the language. > > I think when writing a prototype, you should use whatever features you > want, except maybe at the upper levels of program organization. The > idea of prototyping is to get something done quickly, that you can use > for integration and user testing earlier in the development cycle. So > you should use whatever Python features are available to make > prototyping faster. You shouldn't expect the prototype code to > closely match the final C code, if that slows you down. If you want > code that closely resembles C code, you might as well write in C > directly. Some truth in that. Thanks, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > > Thanks John, I do not have a long available on the device: stuck with 16 > bits. > What does "available on the device" mean? Having a "long" is a property of a C complier, not a device. What is the CPU in the device? What is the C compiler you are using? N.B. Last time I looked, gcc would generate code for just about any CPU since Babbage's. I would expect *any* C compiler that is targetting a 16-bit CPU to provide a 32-bit long and generate reasonably efficient code for most simple operations. Is there no library of utility routines for *elementary* base conversions such as you need? Is there no 32-bit-arithmetic-simulation package? -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > Philippe Martin wrote: > >> >> Thanks John, I do not have a long available on the device: stuck with 16 >> bits. >> > > What does "available on the device" mean? Having a "long" is a property > of a C complier, not a device. What is the CPU in the device? What is > the C compiler you are using? N.B. Last time I looked, gcc would > generate code for just about any CPU since Babbage's. I would expect > *any* C compiler that is targetting a 16-bit CPU to provide a 32-bit > long and generate reasonably efficient code for most simple operations. > Is there no library of utility routines for *elementary* base > conversions such as you need? Is there no 32-bit-arithmetic-simulation > package? Hi John, I'm working on an embedded 8 bit device and have no choice as to which cross-compiler to use: in this case the guy knows up to short and that's it. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin <[EMAIL PROTECTED]> writes: > Thanks John, I do not have a long available on the device: stuck with 16 > bits. Oh, I think I understand now, why you were asking about algorithms. You really did want something whose intermediate results all fit in 16 bits. Even if your C compiler doesn't support a long int datatype, it may have some library functions to do long arithmetic. Look for functions with names like lmul, ldiv, etc. Will the decimal digit strings always be 8 digits? If yes, there are probably a few math tricks you can use to do the hex conversion simply. -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > Hi, > > I'm looking for an algo that would convert a list such as: > > I'm using python to prototype the algo: this will move to C in an embedded > system where an int has 16 bits - I do not wish to use any python library. > > l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 > l2 = func (l1) > # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 > > > Regards, > > Philippe Thanks to all, I decided to attack the problem another way and change the code in device #2 so it can now take the output from device #1. As device #2 only needs to compare, add, and subtract the stuff .. it makes my life much simpler. Sample (potentially buggy): l1 = [1,2,3,4] l2 = [0,2,3,9] def sup (l1, l2): #assume same length for i in range(len(l1) ): if l1[i] > l2[i]: return 1 if l1[i] < l2[i]: return -1 return 0 def add (l1, l2): #assume same length r = [] idx = range (len(l1)) idx.reverse() carry = 0 for i in idx: if l1[i] + l2[i] > 10: carry = 1 r.insert(0,(l1[i] + l2[i]) % 10) else: r.insert(0,l1[i] + l2[i] + carry) carry = 0 return r print sup(l1,l2) print add (l1,l2) -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > John Machin wrote: > > > Philippe Martin wrote: > > > >> > >> Thanks John, I do not have a long available on the device: stuck with 16 > >> bits. > >> > > > > What does "available on the device" mean? Having a "long" is a property > > of a C complier, not a device. What is the CPU in the device? What is > > the C compiler you are using? N.B. Last time I looked, gcc would > > generate code for just about any CPU since Babbage's. I would expect > > *any* C compiler that is targetting a 16-bit CPU to provide a 32-bit > > long and generate reasonably efficient code for most simple operations. > > Is there no library of utility routines for *elementary* base > > conversions such as you need? Is there no 32-bit-arithmetic-simulation > > package? > > Hi John, > > I'm working on an embedded 8 bit device and have no choice as to which > cross-compiler to use: in this case the guy knows up to short and that's > it. > What do you mean, no choice? You generate code, you stuff it into the device, it doesn't give a rat's where the code came from ... Perhaps we could help you better if you actually answered the questions, like: What is the CPU in the device? What is the C compiler you are using? Is there an assembler for the CPU that's in the device? Have you considered asking on a newsgroup where your problem might actually be on-topic, like: comp.lang.c a NG devoted to microprocessors ? -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > Have you considered asking on a newsgroup where your problem might > actually be on-topic, like: > comp.lang.c Yes, I came here for the "algorithm" question, not the code result. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > Philippe Martin wrote: > > > Hi, > > > > I'm looking for an algo that would convert a list such as: > > > > I'm using python to prototype the algo: this will move to C in an embedded > > system where an int has 16 bits - I do not wish to use any python library. > > > > l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 > > l2 = func (l1) > > # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 > > > > > > Regards, > > > > Philippe > > Thanks to all, > > I decided to attack the problem another way and change the code in device #2 > so it can now take the output from device #1. > > As device #2 only needs to compare, add, and subtract the stuff .. it makes > my life much simpler. > I'm confused. 1. Was the original device #1 or #2? 2. How many bits does the non-original device's C compiler support? 3. If the original device is device #1, please explain where *it* obtained an 8-digit decimal number expressed as 1 digit per byte (or int) ... -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > John Machin wrote: > > > Have you considered asking on a newsgroup where your problem might > > actually be on-topic, like: > > comp.lang.c > > Yes, I came here for the "algorithm" question, not the code result. > This is comp.lang.python, not comp.algorithms Why are you avoiding naming the chip and its compiler? -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > > Philippe Martin wrote: >> Philippe Martin wrote: >> >> > Hi, >> > >> > I'm looking for an algo that would convert a list such as: >> > >> > I'm using python to prototype the algo: this will move to C in an >> > embedded system where an int has 16 bits - I do not wish to use any >> > python library. >> > >> > l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 >> > l2 = func (l1) >> > # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 >> > >> > >> > Regards, >> > >> > Philippe >> >> Thanks to all, >> >> I decided to attack the problem another way and change the code in device >> #2 so it can now take the output from device #1. >> >> As device #2 only needs to compare, add, and subtract the stuff .. it >> makes my life much simpler. >> > > I'm confused. > 1. Was the original device #1 or #2? > 2. How many bits does the non-original device's C compiler support? > 3. If the original device is device #1, please explain where *it* > obtained an 8-digit decimal number expressed as 1 digit per byte (or > int) ... Well I don't want to bore you guys more than needed ;-) but: Device #1 has an 8 bit processor - uses a C cross-compiler that does not know anything above a 16 bit integer. I use this device to get information from users "1234...". Device #2 has an 8 bit processor - uses a subset of Java ... that does not know anything above a 16 bit integer. The information gathered in device number #1 must then be sent to device #2 (after being encrypted ) to be compared, subtracted or added. The code I already have in device #2 makes the assumption that the information received is an array of bytes of length N which represents an actual value. ex: 0x67DF5 ==> [0x6, 0x7, 0xD, 0xF, 0x5] ... so it can compare/add/subtract values ... and do its job. As a python fan, I figured (back to my initial not very clear request), that I could prototype the above without making any major assumption as to the capabilities of the interpreter. I still believe that to be true. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > > Philippe Martin wrote: >> John Machin wrote: >> >> > Have you considered asking on a newsgroup where your problem might >> > actually be on-topic, like: >> > comp.lang.c >> >> Yes, I came here for the "algorithm" question, not the code result. >> > > This is comp.lang.python, not comp.algorithms > > Why are you avoiding naming the chip and its compiler? I must disagree on that one: There are many threads on this site where people just have fun talking algorithm. I'm not an algo. expert and I know there are many here. > Why are you avoiding naming the chip and its compiler? I am not but I do not see what that brings to the discussion: but if you wish ==> on one device, the processor in an 8-bit arm and the X-compiler is made by epson on the other device, the processor is unknown to me and the environment is a subset of java made for smartcards called javacard. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > John Machin wrote: > > > > > Philippe Martin wrote: > >> Philippe Martin wrote: > >> > >> > Hi, > >> > > >> > I'm looking for an algo that would convert a list such as: > >> > > >> > I'm using python to prototype the algo: this will move to C in an > >> > embedded system where an int has 16 bits - I do not wish to use any > >> > python library. > >> > > >> > l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 > >> > l2 = func (l1) > >> > # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 > >> > > >> > > >> > Regards, > >> > > >> > Philippe > >> > >> Thanks to all, > >> > >> I decided to attack the problem another way and change the code in device > >> #2 so it can now take the output from device #1. > >> > >> As device #2 only needs to compare, add, and subtract the stuff .. it > >> makes my life much simpler. > >> > > > > I'm confused. > > 1. Was the original device #1 or #2? > > 2. How many bits does the non-original device's C compiler support? > > 3. If the original device is device #1, please explain where *it* > > obtained an 8-digit decimal number expressed as 1 digit per byte (or > > int) ... > > > Well I don't want to bore you guys more than needed ;-) but: > > Device #1 has an 8 bit processor - uses a C cross-compiler that does not > know anything above a 16 bit integer. I use this device to get information > from users "1234...". > > Device #2 has an 8 bit processor - uses a subset of Java ... that does not > know anything above a 16 bit integer. > > > The information gathered in device number #1 must then be sent to device #2 > (after being encrypted ) to be compared, subtracted or added. > > The code I already have in device #2 makes the assumption that the > information received is an array of bytes of length N which represents an > actual value. ex: 0x67DF5 ==> [0x6, 0x7, 0xD, 0xF, 0x5] ... so it can > compare/add/subtract values ... and do its job. > > As a python fan, I figured (back to my initial not very clear request), that > I could prototype the above without making any major assumption as to the > capabilities of the interpreter. > > > I still believe that to be true. > Try this: C:\junk>type bcd.py def reconstitute_int(alist): reghi, reglo = 0, 0 for digit in alist: assert 0 <= digit <= 9 reghi, reglo = mul32by10(reghi, reglo) reghi, reglo = add32(reghi, reglo, 0, digit) return reghi, reglo def uadd16(a, b): return (a + b) & 0x def shr32by4(hi, lo): newhi = (hi >> 4) & 0x newlo = ((lo >> 4) | ((hi & 0xF) << 12)) & 0x return newhi, newlo def add32(hia, loa, hib, lob): lox = uadd16(loa, lob) hix = uadd16(hia, hib) inx = ((lox & 0x8000) >> 13) + ((lob & 0x8000) >> 14) + ((loa & 0x8000) >> 1 5) carry = [0, 1, 1, 1, 0, 0, 0, 1][inx] # The above is admittedly ugly but sheesh I haven't even had my # second cup of coffee yet today :-) # Anybody who's good at solving equations in Boolean algebra, # pls beautify this!! if carry: hix = uadd16(hix, 1) expected = (hia+hib)*65536 + loa + lob actual = hix*65536 + lox if actual != expected: print (hia, loa), (hib, lob), (hix, lox), actual, expected, inx, carry return hix, lox def mul32by10(hi, lo): tmphi, tmplo = add32(hi, lo, hi, lo) # 2 times tmphi, tmplo = add32(tmphi, tmplo, tmphi, tmplo) # 4 times tmphi, tmplo = add32(tmphi, tmplo, hi, lo) # 5 times tmphi, tmplo = add32(tmphi, tmplo, tmphi, tmplo) # 10 times return tmphi, tmplo def make_hex32(aninthi, anintlo): result = [] while aninthi or anintlo: result.append(anintlo & 0xF) aninthi, anintlo = shr32by4(aninthi, anintlo) return result def reverse_list(alist): n = len(alist) for i in xrange(n >> 1): reg1 = alist[n - 1 - i] reg2 = alist[i] alist[i] = reg1 alist[n - 1 - i] = reg2 C:\junk>python Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import bcd >>> num = bcd.reconstitute_int([1,2,3,4,5,6,7,8]) >>> num (188, 24910) >>> num[0]*65536 + num[1] 12345678 >>> result = bcd.make_hex32(*num) >>> result [14, 4, 1, 6, 12, 11] >>> bcd.reverse_list(result) >>> result [11, 12, 6, 1, 4, 14] >>> ['0x%x' % digit for digit in result] ['0xb', '0xc', '0x6', '0x1', '0x4', '0xe'] >>> ^Z -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > John Machin wrote: > > > > > Philippe Martin wrote: > >> John Machin wrote: > >> > >> > Have you considered asking on a newsgroup where your problem might > >> > actually be on-topic, like: > >> > comp.lang.c > >> > >> Yes, I came here for the "algorithm" question, not the code result. > >> > > > > This is comp.lang.python, not comp.algorithms > > > > Why are you avoiding naming the chip and its compiler? > > > I must disagree on that one: There are many threads on this site where > people just have fun talking algorithm. I'm not an algo. expert and I know > there are many here. Get this through your head: some time in the last 25 years someone will have made some general-purpose functions for doing the elementary 32-bit operations with a C compiler that offers no more than 16 bit arithmetic, and published the C source code. Go find it. > > > > Why are you avoiding naming the chip and its compiler? > I am not but I do not see what that brings to the discussion: Readers may actually know something about the device and/or compiler!! > but if you > wish ==> > > on one device, the processor in an 8-bit arm and the X-compiler is made by > epson 1. You still haven't *NAMED* the CPU and the compiler!! 2. Do you mean ARM as in "Acorn/Advanced RISC Machines"?? They make 8-bit CPUs 3. How does the device manage to compute the 8-decimal-digit number that is your input?? -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
On 2006-07-30, John Machin <[EMAIL PROTECTED]> wrote: >> Yes, I came here for the "algorithm" question, not the code >> result. > > This is comp.lang.python, not comp.algorithms > > Why are you avoiding naming the chip and its compiler? It's top secret. If he told us, he'd have to kill us. -- Grant Edwards grante Yow! ... I see TOILET at SEATS... visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
On 2006-07-31, John Machin <[EMAIL PROTECTED]> wrote: >> but if you >> wish ==> >> >> on one device, the processor in an 8-bit arm and the X-compiler is made by >> epson > > 1. You still haven't *NAMED* the CPU and the compiler!! He obviously doesn't want to have to kill all of us. > 2. Do you mean ARM as in "Acorn/Advanced RISC Machines"?? That's the only "arm" processor I know about. > They make 8-bit CPUs Nope. > 3. How does the device manage to compute the 8-decimal-digit number > that is your input?? -- Grant Edwards grante Yow! Yow! Maybe I should at have asked for my Neutron visi.comBomb in PAISLEY-- -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Dennis Lee Bieber wrote:
> On Sun, 30 Jul 2006 17:07:57 -0500, Philippe Martin
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>> Paul Rubin wrote:
>>
>> >
>> > If you prefer, You can do it all in one line:
>> >
>> >vlist = [int(d, 16) for d in ('%X' % int(''.join(map(str, l1]
>>
>> Thanks Paul,
>>
>> I'm just using Python to prototype, so I cannot use any of these great
>> features of the language.
>>
>
> You asked for "algorithm"... The above can be translated to C fairly
> easily without changing the algorithm... The array handling requires
> some thought, but...
>
> Or did you want a literal "recipe"
>
> for each integer in list I1:
> convert to string representation
> join the resultant strings into one string
> convert result to binary integer
> "print" the integer to string using Hex format code
> for each hex-digit in the string representation:
> convert to binary representation
>
> But then, that description was given to you...
>
> That /is/ the algorithm... Implementation is a detail for the
> student
> --
> Wulfraed Dennis Lee Bieber KD6MOG
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> HTTP://wlfraed.home.netcom.com/
> (Bestiaria Support Staff: [EMAIL PROTECTED])
> HTTP://www.bestiaria.com/
Thank you very much
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Grant Edwards wrote: > On 2006-07-31, John Machin <[EMAIL PROTECTED]> wrote: > >>> but if you >>> wish ==> >>> >>> on one device, the processor in an 8-bit arm and the X-compiler is made >>> by epson >> >> 1. You still haven't *NAMED* the CPU and the compiler!! > > He obviously doesn't want to have to kill all of us. > >> 2. Do you mean ARM as in "Acorn/Advanced RISC Machines"?? > > That's the only "arm" processor I know about. > >> They make 8-bit CPUs > > Nope. > >> 3. How does the device manage to compute the 8-decimal-digit number >> that is your input?? > > > -- > Grant Edwards grante Yow! Yow! Maybe I > should > at have asked for my > Neutron >visi.comBomb in PAISLEY-- Yes I had arm in mind (for some reason) while it is the Smc8831 (http://www.google.com/url?sa=U&start=1&q=http://www.epsondevice.com/www/PDFS/epdoc_ic.nsf/5388db40b5eee4f949256a9c001d589f/944b73008b0bad33492570a00015d6ba/%24FILE/S5U1C88000C_2Ev3.pdf&e=9797) >> 3. How does the device manage to compute the 8-decimal-digit number >> that is your input?? What device manager ? think about it before being rude Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > Grant Edwards wrote: > >> On 2006-07-31, John Machin <[EMAIL PROTECTED]> wrote: >> but if you wish ==> on one device, the processor in an 8-bit arm and the X-compiler is made by epson >>> >>> 1. You still haven't *NAMED* the CPU and the compiler!! >> >> He obviously doesn't want to have to kill all of us. >> >>> 2. Do you mean ARM as in "Acorn/Advanced RISC Machines"?? >> >> That's the only "arm" processor I know about. >> >>> They make 8-bit CPUs >> >> Nope. >> >>> 3. How does the device manage to compute the 8-decimal-digit number >>> that is your input?? >> >> >> -- >> Grant Edwards grante Yow! Yow! Maybe I >> should >> at have asked for my >> Neutron >>visi.comBomb in PAISLEY-- > > Yes I had arm in mind (for some reason) while it is the Smc8831 > (http://www.google.com/url?sa=U&start=1&q=http://www.epsondevice.com/www/PDFS/epdoc_ic.nsf/5388db40b5eee4f949256a9c001d589f/944b73008b0bad33492570a00015d6ba/%24FILE/S5U1C88000C_2Ev3.pdf&e=9797) > > >>> 3. How does the device manage to compute the 8-decimal-digit number >>> that is your input?? > > What device manager ? think about it before being rude > > Regards, > > Philippe PS: That is the first time I feel insulted posting on this list in _many_ years ... but I'm certain it is my fault. -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > Philippe Martin wrote: >> John Machin wrote: >> >> > >> > Philippe Martin wrote: >> >> Philippe Martin wrote: >> >> >> >> > Hi, >> >> > >> >> > I'm looking for an algo that would convert a list such as: >> >> > >> >> > I'm using python to prototype the algo: this will move to C in an >> >> > embedded system where an int has 16 bits - I do not wish to use any >> >> > python library. >> >> > >> >> > l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678 >> >> > l2 = func (l1) >> >> > # l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687 >> >> > >> >> > >> >> > Regards, >> >> > >> >> > Philippe >> >> >> >> Thanks to all, >> >> >> >> I decided to attack the problem another way and change the code in >> >> device >> >> #2 so it can now take the output from device #1. >> >> >> >> As device #2 only needs to compare, add, and subtract the stuff .. it >> >> makes my life much simpler. >> >> >> > >> > I'm confused. >> > 1. Was the original device #1 or #2? >> > 2. How many bits does the non-original device's C compiler support? >> > 3. If the original device is device #1, please explain where *it* >> > obtained an 8-digit decimal number expressed as 1 digit per byte (or >> > int) ... >> >> >> Well I don't want to bore you guys more than needed ;-) but: >> >> Device #1 has an 8 bit processor - uses a C cross-compiler that does not >> know anything above a 16 bit integer. I use this device to get >> information from users "1234...". >> >> Device #2 has an 8 bit processor - uses a subset of Java ... that does >> not know anything above a 16 bit integer. >> >> >> The information gathered in device number #1 must then be sent to device >> #2 (after being encrypted ) to be compared, subtracted or added. >> >> The code I already have in device #2 makes the assumption that the >> information received is an array of bytes of length N which represents an >> actual value. ex: 0x67DF5 ==> [0x6, 0x7, 0xD, 0xF, 0x5] ... so it can >> compare/add/subtract values ... and do its job. >> >> As a python fan, I figured (back to my initial not very clear request), >> that I could prototype the above without making any major assumption as >> to the capabilities of the interpreter. >> >> >> I still believe that to be true. >> > > Try this: > C:\junk>type bcd.py > def reconstitute_int(alist): > reghi, reglo = 0, 0 > for digit in alist: > assert 0 <= digit <= 9 > reghi, reglo = mul32by10(reghi, reglo) > reghi, reglo = add32(reghi, reglo, 0, digit) > return reghi, reglo > > def uadd16(a, b): > return (a + b) & 0x > > def shr32by4(hi, lo): > newhi = (hi >> 4) & 0x > newlo = ((lo >> 4) | ((hi & 0xF) << 12)) & 0x > > return newhi, newlo > > def add32(hia, loa, hib, lob): > lox = uadd16(loa, lob) > hix = uadd16(hia, hib) > inx = ((lox & 0x8000) >> 13) + ((lob & 0x8000) >> 14) + ((loa & > 0x8000) >> 1 > 5) > carry = [0, 1, 1, 1, 0, 0, 0, 1][inx] > # The above is admittedly ugly but sheesh I haven't even had my > # second cup of coffee yet today :-) > # Anybody who's good at solving equations in Boolean algebra, > # pls beautify this!! > if carry: > hix = uadd16(hix, 1) > expected = (hia+hib)*65536 + loa + lob > actual = hix*65536 + lox > if actual != expected: > print (hia, loa), (hib, lob), (hix, lox), actual, expected, > inx, carry > return hix, lox > > def mul32by10(hi, lo): > tmphi, tmplo = add32(hi, lo, hi, lo) # 2 times > tmphi, tmplo = add32(tmphi, tmplo, tmphi, tmplo) # 4 times > tmphi, tmplo = add32(tmphi, tmplo, hi, lo) # 5 times > tmphi, tmplo = add32(tmphi, tmplo, tmphi, tmplo) # 10 times > return tmphi, tmplo > > def make_hex32(aninthi, anintlo): > result = [] > while aninthi or anintlo: > result.append(anintlo & 0xF) > aninthi, anintlo = shr32by4(aninthi, anintlo) > return result > > def reverse_list(alist): > n = len(alist) > for i in xrange(n >> 1): > reg1 = alist[n - 1 - i] > reg2 = alist[i] > alist[i] = reg1 > alist[n - 1 - i] = reg2 > > > C:\junk>python > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] > on win32 > Type "help", "copyright", "credits" or "license" for more information. import bcd num = bcd.reconstitute_int([1,2,3,4,5,6,7,8]) num > (188, 24910) num[0]*65536 + num[1] > 12345678 result = bcd.make_hex32(*num) result > [14, 4, 1, 6, 12, 11] bcd.reverse_list(result) result > [11, 12, 6, 1, 4, 14] ['0x%x' % digit for digit in result] > ['0xb', '0xc', '0x6', '0x1', '0x4', '0xe'] ^Z Thanks John, I will give it a good look. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > >> 3. How does the device manage to compute the 8-decimal-digit number > >> that is your input?? > > What device manager ? think about it before being rude > No device manager [noun] was mentioned. You may have inferred rudeness where astonishment was being implied. I'll try again: How does the [8-bit] device manage [verb, as in "how is it able"] to compute the [32-bit] 8-decimal-digit number that is [split up one decimal digit per array element thus becoming] your input?? -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > > Yes I had arm in mind (for some reason) while it is the Smc8831 > (http://www.google.com/url?sa=U&start=1&q=http://www.epsondevice.com/www/PDFS/epdoc_ic.nsf/5388db40b5eee4f949256a9c001d589f/944b73008b0bad33492570a00015d6ba/%24FILE/S5U1C88000C_2Ev3.pdf&e=9797) That appears to be volume 2 of the 2-volume set of manuals that come with the tools package. It says that vol 1 has details about the C compiler. This appears to be volume 1: http://www.epsondevice.com/www/PDFS/epdoc_ic.nsf/5388db40b5eee4f949256a9c001d589f/1410881ddee374f7492570a00015d65e/$FILE/C88000C_1Ev3.pdf Section 1.2.3 Data Types mentions unsigned and signed long (32-bit) data types. There are several references to "long" later, including declarations in sample C code, and details of how long (32-bit) function args are passed. There appears to be a fundamental disconnection here somewhere ... -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin <[EMAIL PROTECTED]> writes: > > Why are you avoiding naming the chip and its compiler? > > I must disagree on that one: There are many threads on this site where > people just have fun talking algorithm. I'm not an algo. expert and I know > there are many here. This is just like the very common situation here and on sci.crypt, where a person has a programming or algorithm question and gets asked what the application is, and when they answer, it turns out that what they need is not anything like what they thought they needed. > on one device, the processor in an 8-bit arm and the X-compiler is made by > epson > > on the other device, the processor is unknown to me and the environment is a > subset of java made for smartcards called javacard. You mean ARM?? There is no such thing as an 8-bit ARM; they are 32-bit cpu's that (in some models) support a 16-bit instruction format. Javacard is an interpreter that runs in many 8-bit processors. The interpreter supports 32-bit arithmetic. -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Paul Rubin wrote: > Philippe Martin <[EMAIL PROTECTED]> writes: >> > Why are you avoiding naming the chip and its compiler? >> >> I must disagree on that one: There are many threads on this site where >> people just have fun talking algorithm. I'm not an algo. expert and I >> know there are many here. > > This is just like the very common situation here and on sci.crypt, > where a person has a programming or algorithm question and gets asked > what the application is, and when they answer, it turns out that what > they need is not anything like what they thought they needed. > >> on one device, the processor in an 8-bit arm and the X-compiler is made >> by epson >> >> on the other device, the processor is unknown to me and the environment >> is a subset of java made for smartcards called javacard. > > You mean ARM?? There is no such thing as an 8-bit ARM; they are > 32-bit cpu's that (in some models) support a 16-bit instruction > format. > > Javacard is an interpreter that runs in many 8-bit processors. The > interpreter supports 32-bit arithmetic. I checked the processor and it is an EPSON 8 bit (SC88 I think). If you check the javacard specs, you'll see that not all VM support 32 bits. Regards, Philipped -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > > Philippe Martin wrote: > >> >> 3. How does the device manage to compute the 8-decimal-digit number >> >> that is your input?? >> >> What device manager ? think about it before being rude >> > > No device manager [noun] was mentioned. You may have inferred rudeness > where astonishment was being implied. I'll try again: > > How does the [8-bit] device manage [verb, as in "how is it able"] to > compute the [32-bit] 8-decimal-digit number that is [split up one > decimal digit per array element thus becoming] your input?? I get keystrokes from the device keyboard and append to the array as needed. I actually need numbers much larger than 32 bits. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > Philippe Martin wrote: > >> >> Yes I had arm in mind (for some reason) while it is the Smc8831 >> (http://www.google.com/url?sa=U&start=1&q=http://www.epsondevice.com/www/PDFS/epdoc_ic.nsf/5388db40b5eee4f949256a9c001d589f/944b73008b0bad33492570a00015d6ba/%24FILE/S5U1C88000C_2Ev3.pdf&e=9797) > > That appears to be volume 2 of the 2-volume set of manuals that come > with the tools package. It says that vol 1 has details about the C > compiler. > > This appears to be volume 1: > http://www.epsondevice.com/www/PDFS/epdoc_ic.nsf/5388db40b5eee4f949256a9c001d589f/1410881ddee374f7492570a00015d65e/$FILE/C88000C_1Ev3.pdf > > Section 1.2.3 Data Types mentions unsigned and signed long (32-bit) > data types. There are several references to "long" later, including > declarations in sample C code, and details of how long (32-bit) > function args are passed. > > There appears to be a fundamental disconnection here somewhere ... Just trust me John, I do not have access to 32 bit ints/longs. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin <[EMAIL PROTECTED]> writes: > I actually need numbers much larger than 32 bits. What is the max size hex number you need? What is the application if you don't mind my asking? -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Paul Rubin wrote:
> Philippe Martin <[EMAIL PROTECTED]> writes:
>> I actually need numbers much larger than 32 bits.
>
> What is the max size hex number you need? What is the application if
> you don't mind my asking?
Well I am under NDA so I cannot tell you what the application is - I need
numbers (dec) with up to 24 digits.
As I said, I went the other way - more data on the line (from dev 1 to dev
2) - but I feel there is no speed issue at this stage.
Seems to work.
Regards,
Philippe
PYTHON **
l2 = [1,2,3,4]
l1 = [0,2,5,9]
def sup (l1, l2): #assume same length
for i in range(len(l1) ):
if l1[i] > l2[i]:
return 1
if l1[i] < l2[i]:
return -1
return 0
def add (l1, l2): #assume same length
r = []
idx = range (len(l1))
idx.reverse()
carry = 0
for i in idx:
if l1[i] + l2[i] > 10:
carry = 1
r.insert(0,(l1[i] + l2[i]) % 10)
else:
r.insert(0,l1[i] + l2[i] + carry)
carry = 0
return r
def sub (l1,l2): #assume same length - sub l1 from l2
r = []
idx = range (len(l1))
idx.reverse()
carry = 0
for i in idx:
print l1[i] + carry, l2[i]
if ((l2[i]) - (l1[i]+carry) < 0) :
print 'CARRY'
r.insert(0,(((10 + l2[i]) - (l1[i]+carry
carry = 1
else:
r.insert(0,(l2[i]) - (l1[i]+ carry))
carry = 0
return r
print sub (l1,l2)
* AND AM JUST TESTING IT IN JAVACARD **
//
public byte CmpD(byte[] p_op1, byte[] p_op2, byte p_len) {
byte l_count = (byte)0;
for (; l_count < p_len; l_count += 1) {
short C = (short)(p_op1[l_count]);
short D = (short)(p_op2[l_count]);
if (C > D) return 1;
if (C < D) return -1;
}
return 0;
}
//
public static void SubD(byte[] p_op1, byte[] p_op2, byte[] p_dest, byte
p_len) {
byte l_count = (byte)0;
byte l_carry = (byte)0;
for (l_count = (byte)(p_len - (byte)1); l_count >= (byte)0; l_count
-= (byte)1) {
if ((p_op2[l_count] - (byte)(p_op1[l_count]+l_carry) ) < 0) {
p_dest[l_count] = (byte)( ((byte)10 + p_op2[l_count]) -
(byte)(p_op1[l_count] + l_carry)) ;
l_carry = (byte)1;
}
else {
p_dest[l_count] = (byte)( p_op2[l_count] - (byte)(p_op
[l_count] + l_carry)) ;
l_carry = -(byte)0;
}
}
}
//
public static void AddD(byte[] p_op1, byte[] p_op2, byte[] p_dest, byte
p_len) {
byte l_count = (byte)0;
byte l_carry = (byte)0;
for (l_count = (byte)(p_len - (byte)1); l_count >= (byte)0; l_count
-= (byte)1) {
if (p_op2[l_count] + (byte)(p_op1[l_count]) > 10) {
p_dest[l_count] = (byte)( ( p_op2[l_count] + p_op
[l_count] )% 10) ;
l_carry = (byte)1;
}
else {
p_dest[l_count] = (byte)( p_op2[l_count] + p_op1[l_count] +
l_carry) ;
l_carry = -(byte)0;
}
}
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin <[EMAIL PROTECTED]> writes: > Well I am under NDA so I cannot tell you what the application is - I need > numbers (dec) with up to 24 digits. You actually need to represent numbers up to 10**24?? > As I said, I went the other way - more data on the line (from dev 1 to dev > 2) - but I feel there is no speed issue at this stage. What are your memory constraints? -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Paul Rubin wrote: > Philippe Martin <[EMAIL PROTECTED]> writes: >> Well I am under NDA so I cannot tell you what the application is - I need >> numbers (dec) with up to 24 digits. > > You actually need to represent numbers up to 10**24?? > >> As I said, I went the other way - more data on the line (from dev 1 to >> dev 2) - but I feel there is no speed issue at this stage. > > What are your memory constraints? On device #1 no constraint for my purpose. On the smartcard, the tradeoff is between using EEPROM (plenty + slow + small life expectancy) for temp variables versus RAM (very little) ... but I do not think it is an issue eather in my case. Speed is what worries me most (crypto takes time). But so far so good. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Paul Rubin wrote: > Philippe Martin <[EMAIL PROTECTED]> writes: >> Well I am under NDA so I cannot tell you what the application is - I need >> numbers (dec) with up to 24 digits. > > You actually need to represent numbers up to 10**24?? > >> As I said, I went the other way - more data on the line (from dev 1 to >> dev 2) - but I feel there is no speed issue at this stage. > > What are your memory constraints? PS: in smart cards, you count RAM in hundreds of bytes and EEPROM in K-bytes. -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin <[EMAIL PROTECTED]> writes: > On device #1 no constraint for my purpose. On the smartcard, the tradeoff is > between using EEPROM (plenty + slow + small life expectancy) for temp > variables versus RAM (very little) ... but I do not think it is an issue > eather in my case. Speed is what worries me most (crypto takes time). You should not have to do this decimal-hex conversion repeatedly in a crypto operation. Do you have a public-key accelerator (or MAC unit) on that cpu? Do you really care about speed? I had thought up a cute O(n**3) scheme that might have been ok for 8 digits but probably not for 24. -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Paul Rubin wrote: > Philippe Martin <[EMAIL PROTECTED]> writes: >> On device #1 no constraint for my purpose. On the smartcard, the tradeoff >> is between using EEPROM (plenty + slow + small life expectancy) for temp >> variables versus RAM (very little) ... but I do not think it is an issue >> eather in my case. Speed is what worries me most (crypto takes time). > > You should not have to do this decimal-hex conversion repeatedly in a > crypto operation. Do you have a public-key accelerator (or MAC unit) > on that cpu? Do you really care about speed? I had thought up a cute > O(n**3) scheme that might have been ok for 8 digits but probably not > for 24. I did not explain myself correctly, the "decimal" operations are done in "clear mode" as they are made within the cards which by definition cannot be broken, requests and results that go to/from the devices are encrypted/signed with diversified keys ... but that another story ;-) Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > Yes, I came here for the "algorithm" question, not the code result. To turn BCD x to binary integer y, set y to zero for each nibble n of x: y = (((y shifted left 2) + y) shifted left 1) + n Do you need instruction on extracting nibbles, and shifting and adding integers? A problem this small and simple does not call for a prototype. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
[EMAIL PROTECTED] wrote: > > Philippe Martin wrote: >> Yes, I came here for the "algorithm" question, not the code result. > > To turn BCD x to binary integer y, > > set y to zero > for each nibble n of x: > y = (((y shifted left 2) + y) shifted left 1) + n > > Do you need instruction on extracting nibbles, and shifting and > adding integers? > > A problem this small and simple does not call for a prototype. > > > -- > --Bryan 'cause you're smart -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
[EMAIL PROTECTED] wrote: > Philippe Martin wrote: > > Yes, I came here for the "algorithm" question, not the code result. > > To turn BCD x to binary integer y, > > set y to zero > for each nibble n of x: > y = (((y shifted left 2) + y) shifted left 1) + n Yeah yeah yeah i.e. y = y * 10 + n he's been shown that already. Problem is that the OP needs an 8-decimal-digit (32-bits) answer, but steadfastly maintains that he doesn't "have access to" long (32-bit) arithmetic in his C compiler!!! > > Do you need instruction on extracting nibbles, and shifting and > adding integers? > > A problem this small and simple does not call for a prototype. -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote:
> Paul Rubin wrote:
>
> > Philippe Martin <[EMAIL PROTECTED]> writes:
> >> I actually need numbers much larger than 32 bits.
***NOW*** you tell us, after all the stuffing about re 32 bits.
> >
> > What is the max size hex number you need? What is the application if
> > you don't mind my asking?
>
> Well I am under NDA so I cannot tell you what the application is - I need
> numbers (dec) with up to 24 digits.
So why don't you get a freely available "bignum" package, throw away
the bits you don' t want, and just compile it and use it, instead of
writing your own bug-ridden (see below) routines? Oh yeah, the bignum
package might use "long" and you think that you don't have access to
32-bit longs in the C compiler for the 8-bit device that you mistook
for an arm but then said is an Smc8831 [Google can't find it] with a
CPU that you think is a SC88 [but the manual whose URL you gave is for
an S1C88] ...
>
> As I said, I went the other way - more data on the line (from dev 1 to dev
> 2) - but I feel there is no speed issue at this stage.
>
> Seems to work.
Nothing is what it seems. See below.
>
>
> Regards,
>
> Philippe
>
>
>
> PYTHON **
> l2 = [1,2,3,4]
> l1 = [0,2,5,9]
>
>
> def sup (l1, l2): #assume same length
> for i in range(len(l1) ):
> if l1[i] > l2[i]:
> return 1
> if l1[i] < l2[i]:
> return -1
> return 0
>
>
>
> def add (l1, l2): #assume same length
> r = []
> idx = range (len(l1))
> idx.reverse()
> carry = 0
> for i in idx:
>
> if l1[i] + l2[i] > 10:
SHOULD BE >=
currently add([6, 6], [4, 4] -> [10, 10]
> carry = 1
> r.insert(0,(l1[i] + l2[i]) % 10)
*** try - 10 instead of % 10
If the first operand is > 19, you have a bug!
This might save a few CPU cycles on your smartcard
> else:
> r.insert(0,l1[i] + l2[i] + carry)
> carry = 0
SHOULD CHECK FOR CARRY AT END
currently add([9], [8]) -> [7]
should return [1, 7] or handle overflow somehow
> return r
>
>
>
> def sub (l1,l2): #assume same length - sub l1 from l2
*** WHAT HAPPENS IF arg1 > arg2?
> r = []
> idx = range (len(l1))
> idx.reverse()
> carry = 0
> for i in idx:
> print l1[i] + carry, l2[i]
> if ((l2[i]) - (l1[i]+carry) < 0) :
> print 'CARRY'
> r.insert(0,(((10 + l2[i]) - (l1[i]+carry
> carry = 1
> else:
> r.insert(0,(l2[i]) - (l1[i]+ carry))
> carry = 0
> return r
>
>
> print sub (l1,l2)
>
> * AND AM JUST TESTING IT IN JAVACARD **
with the bugs in the Python functions carried forward.
>
>
> //
> public byte CmpD(byte[] p_op1, byte[] p_op2, byte p_len) {
> byte l_count = (byte)0;
> for (; l_count < p_len; l_count += 1) {
> short C = (short)(p_op1[l_count]);
> short D = (short)(p_op2[l_count]);
>
> if (C > D) return 1;
> if (C < D) return -1;
> }
>
> return 0;
>
> }
>
> //
> public static void SubD(byte[] p_op1, byte[] p_op2, byte[] p_dest, byte
> p_len) {
> byte l_count = (byte)0;
> byte l_carry = (byte)0;
> for (l_count = (byte)(p_len - (byte)1); l_count >= (byte)0; l_count
> -= (byte)1) {
> if ((p_op2[l_count] - (byte)(p_op1[l_count]+l_carry) ) < 0) {
> p_dest[l_count] = (byte)( ((byte)10 + p_op2[l_count]) -
> (byte)(p_op1[l_count] + l_carry)) ;
> l_carry = (byte)1;
> }
> else {
> p_dest[l_count] = (byte)( p_op2[l_count] - (byte)(p_op
> [l_count] + l_carry)) ;
> l_carry = -(byte)0;
MINUS ZERO?
> }
> }
>
> }
>
> //
> public static void AddD(byte[] p_op1, byte[] p_op2, byte[] p_dest, byte
> p_len) {
> byte l_count = (byte)0;
> byte l_carry = (byte)0;
> for (l_count = (byte)(p_len - (byte)1); l_count >= (byte)0; l_count
> -= (byte)1) {
> if (p_op2[l_count] + (byte)(p_op1[l_count]) > 10) {
> p_dest[l_count] = (byte)( ( p_op2[l_count] + p_op
> [l_count] )% 10) ;
> l_carry = (byte)1;
> }
> else {
> p_dest[l_count] = (byte)( p_op2[l_count] + p_op1[l_count] +
> l_carry) ;
> l_carry = -(byte)0;
MINUS ZERO?
> }
> }
>
> }
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > So why don't you get a freely available "bignum" package, throw away > the bits you don' t want, and just compile it and use it, instead of > writing your own bug-ridden (see below) routines? Oh yeah, the bignum > package might use "long" and you think that you don't have access to > 32-bit longs in the C compiler for the 8-bit device that you mistook > for an arm but then said is an Smc8831 [Google can't find it] with a > CPU that you think is a SC88 [but the manual whose URL you gave is for > an S1C88] ... > Thanks for the fixes - still looking at it. You are correct, all "bignum" packages I found needed 32 bits. Yes I still see from my documentation that there is no "long" handled by my compiler. I did make a mistake on the CPU (and I really do not care what it is) - you wanted some ref (I still do not see why) and I googled S1C88 and sent you a link as that is the name of the compiler's directory. The reason I first came here was to not have to write my "... own bug-ridden ..." (how nice) ... I have plenty of other bugs to write first. > *** WHAT HAPPENS IF arg1 > arg2? cmp is called first. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Sorry forgot a few answers/comments: John Machin wrote: > SHOULD BE >= >currently add([6, 6], [4, 4] -> [10, 10] True, thanks > *** try - 10 instead of % 10 > If the first operand is > 19, you have a bug! > This might save a few CPU cycles on your smartcard can it ? each array value will be [0..9] >> SHOULD CHECK FOR CARRY AT END >>currently add([9], [8]) -> [7] >>should return [1, 7] or handle overflow somehow True, this actually should become an error from the card to the calling device. That would be a pretty large number though. >> MINUS ZERO? I just do not want to leave it at one(1) if it is. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > John Machin wrote: > > > So why don't you get a freely available "bignum" package, throw away > > the bits you don' t want, and just compile it and use it, instead of > > writing your own bug-ridden (see below) routines? Oh yeah, the bignum > > package might use "long" and you think that you don't have access to > > 32-bit longs in the C compiler for the 8-bit device that you mistook > > for an arm but then said is an Smc8831 [Google can't find it] with a > > CPU that you think is a SC88 [but the manual whose URL you gave is for > > an S1C88] ... > > > > Thanks for the fixes - still looking at it. > > You are correct, all "bignum" packages I found needed 32 bits. > > Yes I still see from my documentation that there is no "long" handled by my > compiler. Have you actually tried it? Do you mean it barfs on the word "long" [meaning that it's not an ANSI-compliant C compiler], or that "long" is only 16 bits? > > I did make a mistake on the CPU (and I really do not care what it is) - you > wanted some ref (I still do not see why) because (1) [like I said before] gcc appears to be able to generate code for a vast number of different CPUs (2) because I find it very difficult to believe that a C compiler for the CPU on a device in current use won't support 32-bit longs -- and so far you have presented no credible evidence to the contrary > and I googled S1C88 and sent you a > link as that is the name of the compiler's directory. and is that or is it not the correct link for the documentation for the compiler that you are using?? > > The reason I first came here was to not have to write my "... own > bug-ridden ..." (how nice) ... I have plenty of other bugs to write first. > -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > Have you actually tried it? Do you mean it barfs on the word "long" > [meaning that it's not an ANSI-compliant C compiler], or that "long" is > only 16 bits? :-) if the documentation tells me there is no 32 bit support, why should I not believe it ? > because (1) [like I said before] gcc appears to be able to generate > code for a vast number of different CPUs (2) because I find it very > difficult to believe that a C compiler for the CPU on a device in > current use won't support 32-bit longs -- and so far you have presented > no credible evidence to the contrary I can recall working on a sparclite many years ago (32 bits) with a x-compiler called g++ (supported by cygnus) that handled the type "long long" = 64 bits. As far as the credible evidence ... you're hurting my feelings ;-) > >> and I googled S1C88 and sent you a >> link as that is the name of the compiler's directory. > > and is that or is it not the correct link for the documentation for the > compiler that you are using?? > Neither can I ! - never found any documentation online ... got it from my device supplier. Regards, Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe Martin wrote: > Sorry forgot a few answers/comments: > > John Machin wrote: > > SHOULD BE >= > >currently add([6, 6], [4, 4] -> [10, 10] > > True, thanks > > > *** try - 10 instead of % 10 > > If the first operand is > 19, you have a bug! > > This might save a few CPU cycles on your smartcard > > can it ? > can WHAT do WHAT? > each array value will be [0..9] if so, you can use - 10 instead of %10 if not, then whatever produced your input has a bug > > >> SHOULD CHECK FOR CARRY AT END > >>currently add([9], [8]) -> [7] > >>should return [1, 7] or handle overflow somehow > > True, this actually should become an error from the card to the calling > device. That would be a pretty large number though. > > > >> MINUS ZERO? > I just do not want to leave it at one(1) if it is. The question is "what do you think you are achieving by having a MINUS sign in front of the zero instead of plain old ordinary zero?" -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Philippe, please! The suspense is killing me. What's the cpu!? For the love of God, what's the CPU? I-can't-take-it-anymore-it's-such-a-simple-question-ingly yours, ~Simon -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Simon Forman wrote: > Philippe, please! The suspense is killing me. What's the cpu!? > > For the love of God, what's the CPU? > > I-can't-take-it-anymore-it's-such-a-simple-question-ingly yours, Yes, please . I've found a C compiler manual on the web for the Epson S1C33 CPU as well as the one for the S1C88 that Philippe pointed me at. They have two things in common: (1) explicitly mention support for 32-bit longs (2) in the bottom right corner of most pages, it has the part number (which includes S1Cxx) and the version number. Philippe has what he believes to be the manual for the C compiler for the CPU in the device, but couldn't find it on the web. Perhaps if Philippe could divulge the part number that's in the bottom right corner of the manual that he has, and/or any part number that might be mentioned in the first few pages of that manual, enlightenment may ensue Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > > Simon Forman wrote: >> Philippe, please! The suspense is killing me. What's the cpu!? >> >> For the love of God, what's the CPU? >> >> I-can't-take-it-anymore-it's-such-a-simple-question-ingly yours, > > Yes, please . > > I've found a C compiler manual on the web for the Epson S1C33 CPU as > well as the one for the S1C88 that Philippe pointed me at. They have > two things in common: > (1) explicitly mention support for 32-bit longs > (2) in the bottom right corner of most pages, it has the part number > (which includes S1Cxx) and the version number. > > Philippe has what he believes to be the manual for the C compiler for > the CPU in the device, but couldn't find it on the web. > > Perhaps if Philippe could divulge the part number that's in the bottom > right corner of the manual that he has, and/or any part number that > might be mentioned in the first few pages of that manual, enlightenment > may ensue > > Cheers, > John That was cute ... over and out ! Long live Python. A+ Philippe -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
On 2006-08-01, Philippe Martin <[EMAIL PROTECTED]> wrote: >> Perhaps if Philippe could divulge the part number that's in >> the bottom right corner of the manual that he has, and/or any >> part number that might be mentioned in the first few pages of >> that manual, enlightenment may ensue > > That was cute ... over and out ! Or perhaps it may not. Methinks it was all just a rather good troll. -- Grant Edwards grante Yow! Where's the Coke at machine? Tell me a joke!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
Grant Edwards wrote: > On 2006-08-01, Philippe Martin <[EMAIL PROTECTED]> wrote: > > >> Perhaps if Philippe could divulge the part number that's in > >> the bottom right corner of the manual that he has, and/or any > >> part number that might be mentioned in the first few pages of > >> that manual, enlightenment may ensue > > > > That was cute ... over and out ! > > Or perhaps it may not. > > Methinks it was all just a rather good troll. > > -- Now we have a few more questions i.e. apart from what CPU is in Phillipe's device: 1. WHO was Philippe replying to -- Simon or me? 2. WHAT was cute? 3. Grant thinks WHAT might have been a rather good troll by WHOM? Ah well never mind ... I think I'll just report the whole thread to thedailywtf and move on :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > [EMAIL PROTECTED] wrote: > > Philippe Martin wrote: > > > Yes, I came here for the "algorithm" question, not the code result. > > > > To turn BCD x to binary integer y, > > > > set y to zero > > for each nibble n of x: > > y = (((y shifted left 2) + y) shifted left 1) + n > > Yeah yeah yeah > i.e. y = y * 10 + n > he's been shown that already. > > Problem is that the OP needs an 8-decimal-digit (32-bits) answer, but > steadfastly maintains that he doesn't "have access to" long (32-bit) > arithmetic in his C compiler!!! And he doesn't need one. He might need the algorithms for shift and add. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
[EMAIL PROTECTED] wrote: > John Machin wrote: > > [EMAIL PROTECTED] wrote: > > > Philippe Martin wrote: > > > > Yes, I came here for the "algorithm" question, not the code result. > > > > > > To turn BCD x to binary integer y, > > > > > > set y to zero > > > for each nibble n of x: > > > y = (((y shifted left 2) + y) shifted left 1) + n > > > > Yeah yeah yeah > > i.e. y = y * 10 + n > > he's been shown that already. > > > > Problem is that the OP needs an 8-decimal-digit (32-bits) answer, but > > steadfastly maintains that he doesn't "have access to" long (32-bit) > > arithmetic in his C compiler!!! > > And he doesn't need one. He might need the algorithms for shift and > add. > I hate to impose this enormous burden on you but you may wish to read the whole thread. He was given those "algorithms". He then upped the ante to 24 decimal digits and moved the goalposts to some chip running a cut-down version of Java ... TTFN John -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > [EMAIL PROTECTED] wrote: > > John Machin wrote: > > > [EMAIL PROTECTED] wrote: > > > > To turn BCD x to binary integer y, > > > > > > > > set y to zero > > > > for each nibble n of x: > > > > y = (((y shifted left 2) + y) shifted left 1) + n > > > > > > Yeah yeah yeah > > > i.e. y = y * 10 + n > > > he's been shown that already. > > > > > > Problem is that the OP needs an 8-decimal-digit (32-bits) answer, but > > > steadfastly maintains that he doesn't "have access to" long (32-bit) > > > arithmetic in his C compiler!!! > > > > And he doesn't need one. He might need the algorithms for shift and > > add. > > I hate to impose this enormous burden on you but you may wish to read > the whole thread. He was given those "algorithms". Quite some longwinded code and arguing about platforms in the rest of the thread. My version assumes three subroutines: extracting nibbles, shifting, and adding, Those are pretty simple, so I asked if he needed them rather than presenting them. Assuming we have them, the algorithm is three lines long. Don't know why people have to make such a big deal of a BCD converter. > He then upped the > ante to 24 decimal digits and moved the goalposts to some chip running > a cut-down version of Java ... He took a while to state the problem, but was clear from the start that he had lists of digits rather than an integer datatype. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
[EMAIL PROTECTED] wrote: >My version assumes three subroutines: extracting > nibbles, shifting, and adding, Those are pretty simple, so I asked > if he needed them rather than presenting them. > Assuming we have > them, the algorithm is three lines long. Perhaps you could enlighten us by publishing (a) the spec for each of the get_nibble(s), shift, and add subroutines (b) the three-line algorithm (c) what the algorithm is intended to achieve ... > > He took a while to state the problem, but was clear from the start > that he had lists of digits rather than an integer datatype. Yes, input was a list [prototyping a byte array] of decimal digits. The OUTPUT was also a list of something. A few messages later, it became clear that the output desired was a list of hexadecimal digits. Until he revealed that the input was up to 24 decimal digits, I was pursuing the notion that a solution involving converting decimal to binary (in a 32-bit long) then to hexadecimal was the way to go. What is apparently needed is an algorithm for converting a "large" number from a representation of one base-10 digit per storage unit to one of a base-16 digit per storage unit, when the size of the number exceeds the size (8, 16, 32, etc bits) of the "registers" available. Is that what you have? Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote: > [EMAIL PROTECTED] wrote: > > >My version assumes three subroutines: extracting > > nibbles, shifting, and adding, Those are pretty simple, so I asked > > if he needed them rather than presenting them. > > Assuming we have > > them, the algorithm is three lines long. > > Perhaps you could enlighten us by publishing (a) the spec for each of > the get_nibble(s), shift, and add subroutines (b) the three-line > algorithm (c) what the algorithm is intended to achieve ... "For each nibble n of x" means to take each 4 bit piece of the BCD integer as a value from zero to sixteen (though only 0 through 9 will appear), from most significant to least significant. "Adding" integers and "shifting" binary integers is well-defined terminology. I already posted the three-line algorithm. It appeared immediately under the phrase "To turn BCD x to binary integer y," and that is what it is intended to achieve. > > He took a while to state the problem, but was clear from the start > > that he had lists of digits rather than an integer datatype. > > Yes, input was a list [prototyping a byte array] of decimal digits. The > OUTPUT was also a list of something. A few messages later, it became > clear that the output desired was a list of hexadecimal digits. Until > he revealed that the input was up to 24 decimal digits, I was pursuing > the notion that a solution involving converting decimal to binary (in a > 32-bit long) then to hexadecimal was the way to go. > > What is apparently needed is an algorithm for converting a "large" > number from a representation of one base-10 digit per storage unit to > one of a base-16 digit per storage unit, when the size of the number > exceeds the size (8, 16, 32, etc bits) of the "registers" available. I read his "Yes I realized that after writing it." response to Dennis Lee Bieber to mean Bieber was correct and what he wanted was to go from BCD to a normal binary integer, which is base 256. The point of posting the simple high-level version of the algorithm was to show a general form that works regardless of particular languages, register sizes and storage considerations. Those matters can effect the details of how one shifts a binary integer left one bit, but shifting is not complicated in any plausible case. > Is that what you have? I'm sorry my post so confused, and possibly offended you. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
[EMAIL PROTECTED] wrote:
> John Machin wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > >My version assumes three subroutines: extracting
> > > nibbles, shifting, and adding, Those are pretty simple, so I asked
> > > if he needed them rather than presenting them.
> > > Assuming we have
> > > them, the algorithm is three lines long.
> >
> > Perhaps you could enlighten us by publishing (a) the spec for each of
> > the get_nibble(s), shift, and add subroutines (b) the three-line
> > algorithm (c) what the algorithm is intended to achieve ...
>
> "For each nibble n of x" means to take each 4 bit piece of the BCD
> integer as a value from zero to sixteen (though only 0 through 9
> will appear), from most significant to least significant.
The OP's input, unvaryingly through the whole thread, even surviving to
his Javacard implementation of add() etc, is a list/array of decimal
digits (0 <= value <= 9). Extracting a nibble is so simple that
mentioning a "subroutine" might make the gentle reader wonder whether
there was something deeper that they had missed.
> "Adding"
> integers and "shifting" binary integers is well-defined
> terminology.
Yes, but it's the *representation* of those integers that's been the
problem throughout.
> I already posted the three-line algorithm. It
> appeared immediately under the phrase "To turn BCD x to binary
> integer y," and that is what it is intended to achieve.
Oh, that "algorithm". The good ol' num = num * base + digit is an
"algorithm"???
The problem with that is that the OP has always maintained that he has
no facility for handling a binary integer ("num") longer than 16 bits
-- no 32-bit long, no bignum package that didn't need "long", ...
>
> > > He took a while to state the problem, but was clear from the start
> > > that he had lists of digits rather than an integer datatype.
> >
> > Yes, input was a list [prototyping a byte array] of decimal digits. The
> > OUTPUT was also a list of something. A few messages later, it became
> > clear that the output desired was a list of hexadecimal digits. Until
> > he revealed that the input was up to 24 decimal digits, I was pursuing
> > the notion that a solution involving converting decimal to binary (in a
> > 32-bit long) then to hexadecimal was the way to go.
> >
> > What is apparently needed is an algorithm for converting a "large"
> > number from a representation of one base-10 digit per storage unit to
> > one of a base-16 digit per storage unit, when the size of the number
> > exceeds the size (8, 16, 32, etc bits) of the "registers" available.
>
> I read his "Yes I realized that after writing it." response to
> Dennis Lee Bieber to mean Bieber was correct and what he wanted
> was to go from BCD to a normal binary integer, which is base 256.
Where I come from, a "normal binary integer" is base 2. It can be
broken up into chunks of any size greater than 1 bit, but practically
according to the wordsize of the CPU: 8, 16, 32, 64, ... bits. Since
when is base 256 "normal" and in what sense of normal?
The OP maintained the line that he has no facility for handling a
base-256 number longer than 2 base-256 digits.
The dialogue between Dennis and the OP wasn't the epitome of clarity:
[OP]
My apologies, I clearly made a mistake with my calculator, yes the
resulting array I would need is [0xb,0xc,0x6,0x1,0x4,0xe]
[Dennis]
Take note that this[**1**] is NOT a BCD form for "12345678". BCD
(typically
packed) uses four bits per decimal digit. That would make "12345678" =>
0x12, 0x34, 0x56, 0x78 (ignoring matters of big/little end).
The binary representation of 12345678, in bytes, is 0xBC, 0x61, 0x4E
0xb, 0xc... is really 0x0B, 0x0C... 8-bits per byte, with MSB set to
.
Compare:
BCD 00010010 00110100 01010110 0000
binary1000 0111 01001110
your 1011 1100 0110 0001 0100 1110
[OP]
Yes I realized that [**2**] after writing it.
... [**1**] Dennis's "this" refers to the OP's *output* which is
patently not what the OP was calling BCD.
[**2**] The referent of the OP's "that" can't be determined
unambiguously, IMHO.
> The point of posting the simple high-level version of the
> algorithm was to show a general form that works regardless of
> particular languages, register sizes and storage considerations.
> Those matters can effect the details of how one shifts a binary
> integer left one bit, but shifting is not complicated in any
> plausible case.
>
> > Is that what you have?
>
> I'm sorry my post so confused, and possibly offended you.
It didn't confuse me. I was merely wondering whether you did in fact
have a method of converting from base b1 (e.g. 10) to base b2 (e.g. 16)
without assembling the number in some much larger base b3 (e.g. 256).
Offended? Experts have tried repeatedly, and not succeeded :-)
Cheers,
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
"John Machin" <[EMAIL PROTECTED]> wrote: | [EMAIL PROTECTED] wrote: | | >My version assumes three subroutines: extracting | > nibbles, shifting, and adding, Those are pretty simple, so I asked | > if he needed them rather than presenting them. | > Assuming we have | > them, the algorithm is three lines long. | | Perhaps you could enlighten us by publishing (a) the spec for each of | the get_nibble(s), shift, and add subroutines (b) the three-line | algorithm (c) what the algorithm is intended to achieve ... | | > | > He took a while to state the problem, but was clear from the start | > that he had lists of digits rather than an integer datatype. | | Yes, input was a list [prototyping a byte array] of decimal digits. The | OUTPUT was also a list of something. A few messages later, it became | clear that the output desired was a list of hexadecimal digits. Until | he revealed that the input was up to 24 decimal digits, I was pursuing | the notion that a solution involving converting decimal to binary (in a | 32-bit long) then to hexadecimal was the way to go. | | What is apparently needed is an algorithm for converting a "large" | number from a representation of one base-10 digit per storage unit to | one of a base-16 digit per storage unit, when the size of the number | exceeds the size (8, 16, 32, etc bits) of the "registers" available. Is | that what you have? | | Cheers, | John I actually read most of this thread as it happened and could not really figure out what the OP was on about. If the above is a true statement of the problem, then its more difficult to do in a high level language, when the results exceed the native size that the compiler or interpreter writers thought was a reasonable number of bits. - ten to the 24 is of the order of 80 binary bits ... So you need a (say) twelve byte result field for the binary... (thats three 32 bit values concatenated) you clear the result field out to zero. Then you feed in the decimal digits, from the most significant side, into a routine that multiplies the result by ten and then adds the digit. (yes you have to write this twelve byte Ascii/binary thing yourself) When you have done this for all the digits, you have a binary number, and getting hex from binary a nibble at a time is easy... Well its easy in assembler, even on a cripple little 8 bit processor, anyway... In python I would take a hard look at what I could do with the decimal module - doing the reverse of the above but dividing by 16 repetitively and using the remainder or the fraction to give the hex numbers in lsb to msb order, and doing a lookup (prolly using a dict) to get the hex digits... just my $0.02... - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
John Machin wrote:
> [EMAIL PROTECTED] wrote:
> > "For each nibble n of x" means to take each 4 bit piece of the BCD
> > integer as a value from zero to sixteen (though only 0 through 9
> > will appear), from most significant to least significant.
> The OP's input, unvaryingly through the whole thread, even surviving to
> his Javacard implementation of add() etc, is a list/array of decimal
> digits (0 <= value <= 9). Extracting a nibble is so simple that
> mentioning a "subroutine" might make the gentle reader wonder whether
> there was something deeper that they had missed.
Yes, it's simple; that was the point. The most complex routine I
assumed is integer addition, and it's not really hard. I'll
present an example below.
> > "Adding"
> > integers and "shifting" binary integers is well-defined
> > terminology.
>
> Yes, but it's the *representation* of those integers that's been the
> problem throughout.
Right. To solve that problem, I give the high-level algorithm and
deal with the representation in the shift and add procedures.
> > I already posted the three-line algorithm. It
> > appeared immediately under the phrase "To turn BCD x to binary
> > integer y," and that is what it is intended to achieve.
>
> Oh, that "algorithm". The good ol' num = num * base + digit is an
> "algorithm"???
You lost me. The algorithm I presented didn't use a multiply
operator. It could have, and of course it would still be an
algorithm.
> The problem with that is that the OP has always maintained that he has
> no facility for handling a binary integer ("num") longer than 16 bits
> -- no 32-bit long, no bignum package that didn't need "long", ...
No problem. Here's an example of an add procedure he might use in
C. It adds modestly-large integers, as base-256 big-endian
sequences of bytes. It doesn't need an int any larger than 8 bits.
Untested:
typedef unsigned char uint8;
#define SIZEOF_BIGINT 16
uint8 add(uint8* result, const uint8* a, const uint8* b)
/* Set result to a+b, returning carry out of MSB. */
{
uint8 carry = 0;
unsigned int i = SIZEOF_BIGINT;
while (i > 0) {
--i;
result[i] = (a[i] + b[i] + carry) & 0xFF;
carry = carry ? result[i] <= a[i] : result[i] < a[i];
}
return carry;
}
> Where I come from, a "normal binary integer" is base 2. It can be
> broken up into chunks of any size greater than 1 bit, but practically
> according to the wordsize of the CPU: 8, 16, 32, 64, ... bits. Since
> when is base 256 "normal" and in what sense of normal?
All the popular CPU's address storage in byte. In C all variable
sizes are in units of char/unsigned char, and unsigned char must
hold zero through 255.
> The OP maintained the line that he has no facility for handling a
> base-256 number longer than 2 base-256 digits.
So he'll have to build what's needed. That's why I showed the
problem broken down to shifts and adds; they're easy to build.
> The dialogue between Dennis and the OP wasn't the epitome of clarity:
Well, I found Dennis clear.
[...]
> I was merely wondering whether you did in fact
> have a method of converting from base b1 (e.g. 10) to base b2 (e.g. 16)
> without assembling the number in some much larger base b3 (e.g. 256).
I'm not sure what that means.
--
--Bryan
--
http://mail.python.org/mailman/listinfo/python-list
Re: BCD List to HEX List
ohn Machin wrote:
> [EMAIL PROTECTED] wrote:
> > "For each nibble n of x" means to take each 4 bit piece of the BCD
> > integer as a value from zero to sixteen (though only 0 through 9
> > will appear), from most significant to least significant.
> The OP's input, unvaryingly through the whole thread, even surviving to
> his Javacard implementation of add() etc, is a list/array of decimal
> digits (0 <= value <= 9). Extracting a nibble is so simple that
> mentioning a "subroutine" might make the gentle reader wonder whether
> there was something deeper that they had missed.
Yes, it's simple; that was the point. The most complex routine I
assumed is integer addition, and it's not really hard. I'll
present an example below.
> > "Adding"
> > integers and "shifting" binary integers is well-defined
> > terminology.
> Yes, but it's the *representation* of those integers that's been the
> problem throughout.
Right. To solve that problem, I give the high-level algorithm and
deal with the representation in the shift and add procedures.
> > I already posted the three-line algorithm. It
> > appeared immediately under the phrase "To turn BCD x to binary
> > integer y," and that is what it is intended to achieve.
> Oh, that "algorithm". The good ol' num = num * base + digit is an
> "algorithm"???
You lost me. The algorithm I presented didn't use a multiply
operator. It could have, and of course it would still be an
algorithm.
> The problem with that is that the OP has always maintained that he has
> no facility for handling a binary integer ("num") longer than 16 bits
> -- no 32-bit long, no bignum package that didn't need "long", ...
No problem. Here's an example of an add procedure he might use in
C. It adds modestly-large integers, as base-256 big-endian
sequences of bytes. It doesn't need an int any larger than 8 bits.
Untested:
typedef unsigned char uint8;
#define SIZEOF_BIGINT 16
uint8 add(uint8* result, const uint8* a, const uint8* b)
/* Set result to a+b, returning carry out of MSB. */
{
uint8 carry = 0;
unsigned int i = SIZEOF_BIGINT;
while (i > 0) {
--i;
result[i] = (a[i] + b[i] + carry) & 0xFF;
carry = carry ? result[i] <= a[i] : result[i] < a[i];
}
return carry;
}
> Where I come from, a "normal binary integer" is base 2. It can be
> broken up into chunks of any size greater than 1 bit, but practically
> according to the wordsize of the CPU: 8, 16, 32, 64, ... bits. Since
> when is base 256 "normal" and in what sense of normal?
All the popular CPU's address storage in byte. In C all variable
sizes are in units of char/unsigned char, and unsigned char must
hold zero through 255.
> The OP maintained the line that he has no facility for handling a
> base-256 number longer than 2 base-256 digits.
So he'll have to build what's needed. That's why I showed the
problem broken down to shifts and adds; they're easy to build.
> The dialogue between Dennis and the OP wasn't the epitome of clarity:
Well, I found Dennis clear.
[...]
> I was merely wondering whether you did in fact
> have a method of converting from base b1 (e.g. 10) to base b2 (e.g. 16)
> without assembling the number in some much larger base b3 (e.g. 256).
I'm not sure what that means.
--
--Bryan
--
http://mail.python.org/mailman/listinfo/python-list
