BCD List to HEX List

[Paul Rubin]

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]

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 > l2:
return 1
if l1 < l2:
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 + l2 > 10:
carry = 1
r.insert(0,(l1 + l2) % 10)
else:
r.insert(0,l1 + l2 + 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 + carry, l2
if ((l2) - (l1+carry) < 0) :
print 'CARRY'
r.insert(0,(((10 + l2) - (l1+carry))))
carry = 1
else:
r.insert(0,(l2) - (l1+ 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]

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]

You actually need to represent numbers up to 10**24??


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]

You actually need to represent numbers up to 10**24??


What are your memory constraints?

PS: in smart cards, you count RAM in hundreds of bytes and EEPROM in
K-bytes.

 

[Paul Rubin]

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]

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]

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.

 

[Philippe Martin]

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.

'cause you're smart

 

[John Machin]

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

 

[John Machin]

***NOW*** you tell us, after all the stuffing about re 32 bits.

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 > l2:
return 1
if l1 < l2:
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 + l2 > 10:

**** SHOULD BE >=
currently add([6, 6], [4, 4] -> [10, 10]

carry = 1
r.insert(0,(l1 + l2) % 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 + l2 + 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 + carry, l2
if ((l2) - (l1+carry) < 0) :
print 'CARRY'
r.insert(0,(((10 + l2) - (l1+carry))))
carry = 1
else:
r.insert(0,(l2) - (l1+ 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]

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

 

[Philippe Martin]

Sorry forgot a few answers/comments:

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

I just do not want to leave it at one(1) if it is.


Regards,

Philippe

 

[John Machin]

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

 

[Philippe Martin]

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

 

[John Machin]

Sorry forgot a few answers/comments:

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

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

 

[Simon Forman]

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

 

[John Machin]

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

 

[Philippe Martin]

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

 

[Grant Edwards]

That was cute ... over and out !

Or perhaps it may not.

Methinks it was all just a rather good troll.