BCD List to HEX List

[Philippe Martin]

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

[Marc 'BlackJack' Rintsch]

In <5S8zg.1553$W93.658@dukeread05>, 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

[Philippe Martin]

Marc 'BlackJack' Rintsch wrote:

In <5S8zg.1553$W93.658@dukeread05>, 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

[Marc 'BlackJack' Rintsch]

In <ti9zg.1555$W93.1057@dukeread05>, 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

[Philippe Martin]

Marc 'BlackJack' Rintsch wrote:

In <ti9zg.1555$W93.1057@dukeread05>, 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

[John Machin]

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

[Philippe Martin]

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

[Paul Rubin]

Philippe Martin <pm*****@snakecard.comwrites:

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))))]

[Philippe Martin]

Paul Rubin wrote:

Philippe Martin <pm*****@snakecard.comwrites:

>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

[John Machin]

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

[Philippe Martin]

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

[Philippe Martin]

Dennis Lee Bieber wrote:

On Sun, 30 Jul 2006 16:39:47 -0500, Philippe Martin
<pm*****@snakecard.comdeclaimed 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
0000.

Compare:
BCD 00010010 00110100 01010110 01111000
binary 10111100 01100001 01001110
your 00001011 00001100 00000110 00000001 00000100 00001110
--
Wulfraed Dennis Lee Bieber KD6MOG
wl*****@ix.netcom.com wu******@bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: we******@bestiaria.com)
HTTP://www.bestiaria.com/

Yes I realized that after writing it.

Regards,

Philippe

[Paul Rubin]

Philippe Martin <pm*****@snakecard.comwrites:

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.

[Philippe Martin]

Paul Rubin wrote:

Philippe Martin <pm*****@snakecard.comwrites:

>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

[John Machin]

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?

[Philippe Martin]

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

[Paul Rubin]

Philippe Martin <pm*****@snakecard.comwrites:

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.

[Philippe Martin]

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)

[John Machin]

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
?

[Philippe Martin]

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

[John Machin]

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) ...

[John Machin]

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?

[Philippe Martin]

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

[Philippe Martin]

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

[John Machin]

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) & 0xFFFF

def shr32by4(hi, lo):
newhi = (hi >4) & 0xFFFF
newlo = ((lo >4) | ((hi & 0xF) << 12)) & 0xFFFF

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

[John Machin]

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??????

[Grant Edwards]

On 2006-07-30, John Machin <sj******@lexicon.netwrote:

>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

[Grant Edwards]

On 2006-07-31, John Machin <sj******@lexicon.netwrote:

>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.com Bomb in PAISLEY--

[Philippe Martin]

Dennis Lee Bieber wrote:

On Sun, 30 Jul 2006 17:07:57 -0500, Philippe Martin
<pm*****@snakecard.comdeclaimed 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... <G>

That /is/ the algorithm... Implementation is a detail for the
student <G>
--
Wulfraed Dennis Lee Bieber KD6MOG
wl*****@ix.netcom.com wu******@bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: we******@bestiaria.com)
HTTP://www.bestiaria.com/

Thank you very much

[Philippe Martin]

Grant Edwards wrote:

On 2006-07-31, John Machin <sj******@lexicon.netwrote:

>>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.com Bomb in PAISLEY--

Yes I had arm in mind (for some reason) while it is the Smc8831
(http://www.google.com/url?sa=U&start...Ev3.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

[Philippe Martin]

Philippe Martin wrote:

Grant Edwards wrote:

>On 2006-07-31, John Machin <sj******@lexicon.netwrote:

>>>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.com Bomb in PAISLEY--

Yes I had arm in mind (for some reason) while it is the Smc8831

(http://www.google.com/url?sa=U&start...Ev3.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.

[Philippe Martin]

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) & 0xFFFF

def shr32by4(hi, lo):
newhi = (hi >4) & 0xFFFF
newlo = ((lo >4) | ((hi & 0xF) << 12)) & 0xFFFF

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

[John Machin]

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??????

[John Machin]

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...Ev3.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 ...

[Paul Rubin]

Philippe Martin <pm*****@snakecard.comwrites:

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.

[Philippe Martin]

Paul Rubin wrote:

Philippe Martin <pm*****@snakecard.comwrites:

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

[Philippe Martin]

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

[Philippe Martin]

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...Ev3.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

[Paul Rubin]

Philippe Martin <pm*****@snakecard.comwrites:

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?

[Philippe Martin]

Paul Rubin wrote:

Philippe Martin <pm*****@snakecard.comwrites:

>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;
}
}

}

[Paul Rubin]

Philippe Martin <pm*****@snakecard.comwrites:

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?

[Philippe Martin]

Paul Rubin wrote:

Philippe Martin <pm*****@snakecard.comwrites:

>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

[Philippe Martin]

Paul Rubin wrote:

Philippe Martin <pm*****@snakecard.comwrites:

>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.

[Paul Rubin]

Philippe Martin <pm*****@snakecard.comwrites:

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.

[Philippe Martin]

Paul Rubin wrote:

Philippe Martin <pm*****@snakecard.comwrites:

>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

[bryanjugglercryptographer]

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

[Philippe Martin]

br***********************@yahoo.com 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

[John Machin]

br***********************@yahoo.com 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.

[John Machin]

Philippe Martin wrote:

Paul Rubin wrote:

Philippe Martin <pm*****@snakecard.comwrites:

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?

}
}

}

[Philippe Martin]

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