BCD List to HEX List

[Philippe Martin]

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]

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]

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]

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]

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:

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
alist = 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

 

[Dennis Lee Bieber]

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
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[John Machin]

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.

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]

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]

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.

 

[Philippe Martin]

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
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

Thank you very much

 

[Philippe Martin]

He obviously doesn't want to have to kill all of us.


That's the only "arm" processor I know about.



--
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&star...0a00015d6ba/$FILE/S5U1C88000C_2Ev3.pdf&e=9797)


What device manager ? think about it before being rude

Regards,

Philippe

 

[Philippe Martin]

Yes I had arm in mind (for some reason) while it is the Smc8831
(http://www.google.com/url?sa=U&star...0a00015d6ba/$FILE/S5U1C88000C_2Ev3.pdf&e=9797)

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]

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
alist = 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]

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]

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

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]

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.


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

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]

(http://www.google.com/url?sa=U&star...0a00015d6ba/$FILE/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...e374f7492570a00015d65e/$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