8086 ALP TO CONVERT BCD -HEXA DECIMAL

[s***@crayne.org]

Hi every body this is kamalesh,am new to assembly level programming so
i want a help frm u .please give me the solution for the following
question.


the question is :
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.

[Phil Carmody]

Post by s***@crayne.org
Hi every body this is kamalesh,am new to assembly level programming so
i want a help frm u .please give me the solution for the following
question.
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.

The problem is that you've presented that question as obviously
a homework exercise. And homework exists for a reason. If others
do your homework for you, then you'll both not learn, and secondly
it's unfair on the rest of the students on your course who do
actually put in the effort if you can get better scores in your
homework than they do, despite you having put no effort in.

However, we tend to be fair here, and we'll meet you in the middle.

Tell us which parts of the question you understand, and which
parts you don't. Tell us what you've tried and how/why it didn't
work. Then we can assist you.

Phil

[[e-mail]]

Post by Phil Carmody

Post by s***@crayne.org
Hi every body this is kamalesh,am new to assembly level programming so
i want a help frm u .please give me the solution for the following
question.
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.

The problem is that you've presented that question as obviously
a homework exercise. And homework exists for a reason. If others
do your homework for you, then you'll both not learn, and secondly
it's unfair on the rest of the students on your course who do
actually put in the effort if you can get better scores in your
homework than they do, despite you having put no effort in.
However, we tend to be fair here, and we'll meet you in the middle.
Tell us which parts of the question you understand, and which
parts you don't. Tell us what you've tried and how/why it didn't
work. Then we can assist you.
Phil
--
"Home taping is killing big business profits. We left this side blank
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.

oh guys i haven't tried anything
this question was appeared in the internal exams which i was unable to
resolve it.As this question was going to appear in the finals i want
the answer immediately as i was going to write this
exam(microprocessor)on the day next .so moderator plz help me.this
question is going to ppear in my external exam for 14 marks which is
very hard to loose

[Tim Roberts]

Post by ***@gmail.com

Post by s***@crayne.org
Hi every body this is kamalesh,am new to assembly level programming so
i want a help frm u .please give me the solution for the following
question.
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.

oh guys i haven't tried anything
this question was appeared in the internal exams which i was unable to
resolve it.As this question was going to appear in the finals i want
the answer immediately as i was going to write this
exam(microprocessor)on the day next .so moderator plz help me.this
question is going to ppear in my external exam for 14 marks which is
very hard to loose

If you haven't done any work on the problem, and still aren't prepared to
answer the question, then it seems to me that you do not deserve to earn 14
marks for it.

[[Jongware]]

Post by s***@crayne.org
Hi every body this is kamalesh,am new to assembly level programming so
i want a help frm u .please give me the solution for the following
question.
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.

No problem.

.start
mov eax,[bcd_number]
call bcd-hex
ret

This does quite close to what your professor asked.

[Jongware]

[[e-mail]]

Post by s***@crayne.org
Hi every body this is kamalesh,am new to assembly level programming so
i want a help frm u .please give me the solution for the following
question.
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.

The HLA Standard Library contains such code. Perhaps you should take a
look at that library. You can find it at http://webster.cs.ucr.edu.
Follow the "High-Level Assembly" links.
Cheers,
Randy Hyde

[Frank Kotler]

Post by ***@cs.ucr.edu

Post by s***@crayne.org
Hi every body this is kamalesh,am new to assembly level programming so
i want a help frm u .please give me the solution for the following
question.
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.

The HLA Standard Library contains such code. Perhaps you should take a
look at that library. You can find it at http://webster.cs.ucr.edu.
Follow the "High-Level Assembly" links.

Maybe I'm following the wrong links, but I don't see any bcd code,
except entwined with floating-point code... which I don't think is what
handsomeandmodestkamalesh was looking for. :)

You'd better start trying stuff, dude!!!

Seems to me that "four digit" bcd suggests 16-bit code... Okay...
(easier in 32-bit). Seems similar to doing ascii to hex (that is, ascii
to number) in a way... We want to multiply the "result so far" by ten,
and add each digit as we process it. The difference is, we don't need to
"sub dl, '0'" - it isn't ascii - and we've got one digit per nibble, not
one digit per byte.

[on the old 8-bit Atari, they used to refer to "unpacked bcd" - one
digit per byte - and "packed bcd" - one digit per nibble. I am assuming
that "packed bcd" is what we're talking about here.]

We've got 4 digits to process, so:

mov cx, 4

might be useful. We want to clear a register for the "result so far".
Probably want to return it in ax, and it's a convenient destination for
the "mul" we'll want...

xor ax, ax ; or "mov ax, 0", if you must

We'll be wanting to multiply that by ten, so:

mov si, 10

Suppose we've got the 4 bcd digits in bx (if not, make it so). We want
it one digit at a time...

commence:
mul si ; multiply result so far by ten
ror bx, 4 ; put the top nibble in the bottom nibble
mov dx, bx ; make a copy to process
and dx, 0Fh ; mask off just the one digit
add ax, dx ; add this digit to result so far
loop commence ; do all 4 digits

That should put the number in ax...

ret

You'll probably want to modify that to preserve bx and si, maybe more
regs, arrange to pass in the bcd value... do you know how to pass a
parameter on the stack? If not, just pass it in bx... (don't need to
"preserve" bx if you do that - it gets rotated around to be what it was)

That (untested... "something like that") should do what you want... if I
understand the question...

Best,
Frank

[[e-mail]]

Post by Frank Kotler
Maybe I'm following the wrong links, but I don't see any bcd code,

Do you *really* think this is what he's asking for?
99% of the time when someone is asking for this, they're reading the
(poorly written) homework assignment right off the sheet and not
providing the background for it. Chances are pretty good it *is* atoi.
And if not, the algorithm is still the same.
Cheers,
Randy Hyde

[Wolfgang Kern]

Frank Kotler wrote:

[...]

Post by Frank Kotler
Seems to me that "four digit" bcd suggests 16-bit code... Okay...
(easier in 32-bit). Seems similar to doing ascii to hex (that is, ascii
to number) in a way... We want to multiply the "result so far" by ten,
and add each digit as we process it. The difference is, we don't need to
"sub dl, '0'" - it isn't ascii - and we've got one digit per nibble, not
one digit per byte.
[on the old 8-bit Atari, they used to refer to "unpacked bcd" - one
digit per byte - and "packed bcd" - one digit per nibble. I am assuming
that "packed bcd" is what we're talking about here.]

[...]

How to convert Packed BCD into HEX ???
[for me, pBCD is just a limited subset of HEX]
I use only one routine for both:

--snippet of my RSET_hex_out--
MOV ebx,[esi] ;or any other source
MOV cl,... ;desired output size (max =8)
L0:
MOV al,bl
RR ebx,4
AND al,0F
CMP al,0a ;* needed for hex only (exc: BCD error check),
JC L1> ;* but as I rare use BCD
ADD al,07 ;* I can live with the lost 1.5 cycles.
L1:
ADD al,030
CALL .... ;char to buffer/screen/printer/..
DEC cl
JNZ L0<
----

May I assume we all misunderstood the question ? :)
Or was it about "bcd2bin" ?
Or uBCD to HEX or bin ?

__
wolfgang

[Frank Kotler]

Post by Wolfgang Kern
[...]

Post by Frank Kotler
Seems to me that "four digit" bcd suggests 16-bit code... Okay...
(easier in 32-bit). Seems similar to doing ascii to hex (that is, ascii
to number) in a way... We want to multiply the "result so far" by ten,
and add each digit as we process it. The difference is, we don't need to
"sub dl, '0'" - it isn't ascii - and we've got one digit per nibble, not
one digit per byte.
[on the old 8-bit Atari, they used to refer to "unpacked bcd" - one
digit per byte - and "packed bcd" - one digit per nibble. I am assuming
that "packed bcd" is what we're talking about here.]

[...]
How to convert Packed BCD into HEX ???
[for me, pBCD is just a limited subset of HEX]
--snippet of my RSET_hex_out--
MOV ebx,[esi] ;or any other source
MOV cl,... ;desired output size (max =8)
MOV al,bl
RR ebx,4
AND al,0F
CMP al,0a ;* needed for hex only (exc: BCD error check),
JC L1> ;* but as I rare use BCD
ADD al,07 ;* I can live with the lost 1.5 cycles.
ADD al,030
CALL .... ;char to buffer/screen/printer/..
DEC cl
JNZ L0<
----
May I assume we all misunderstood the question ? :)

Seems like a good bet. In any case, I meant "rol", not "ror" - sorry!
(You, too?)

Kamalesh originally wrote:

------------------
the question is :
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.
-------------------

It isn't actually a "question", it's an "imperative" or "command" -
possibly the source of my confusion. :)

("ALP"???)
(Oh, and "BCD-HEX" wouldn't be a legal name...)

Post by Wolfgang Kern
Or was it about "bcd2bin" ?
Or uBCD to HEX or bin ?

Depends how you name it... What I posted was intended to be
"bcd-to-number", presumably to be followed by "number to hex ascii".
Quite a useless operation - probably why HLA Std Lib doesn't have it. As
you point out, if we want to "display bcd", we just use the "display
number as hex ascii" routine (and don't print the "0x" or "h"). Randy
thought he was probably actually looking for "atoi" (damnedest way to
ask for "atoi" I ever saw, but could be...).

Phil had the correct reply: "tell us which parts you understand, and
which you don't". If the part you don't understand is what the
assignment is looking for (my problem, apparently), we aren't going to
be able to help - go back to the instructor!

I'll bet we never find out what he actually wanted, either!

Best,
Frank

[[e-mail]]

Post by Frank Kotler

Post by ***@cs.ucr.edu

Post by s***@crayne.org
Hi every body this is kamalesh,am new to assembly level programming so
i want a help frm u .please give me the solution for the following
question.
write a ALP(assembly level program )to convert 4 digit BCD to HEXA
DECIMAL which includes a sub routine BCD-HEX.

The HLA Standard Library contains such code. Perhaps you should take a
look at that library. You can find it athttp://webster.cs.ucr.edu.
Follow the "High-Level Assembly" links.

Maybe I'm following the wrong links, but I don't see any bcd code,
except entwined with floating-point code... which I don't think is what
handsomeandmodestkamalesh was looking for. :)
You'd better start trying stuff, dude!!!

If packed BCD is what the OP was *really* asking for, the stdlib does
it just fine:

static
bcd16 :word;
i16 :word;
stemp :str.strval(10);
.
.
.
str.put( stemp, bcd16 );
conv.strToi16( stemp );
mov( ax, i16 );

Cheers,
Randy Hyde

[Terence]

Did everybody miss that DCB uses a multiplier of 10 per nibble and hex
uses a multiplier of 16?
So a converter to binary for both BCD and HEX only differ in the
initialization of the multiplier value. Then the reverse conversion
case only differs in the divisor.

[Wolfgang Kern]

Post by Terence
Did everybody miss that DCB uses a multiplier of 10 per nibble and hex
uses a multiplier of 16?
So a converter to binary for both BCD and HEX only differ in the
initialization of the multiplier value. Then the reverse conversion
case only differs in the divisor.

Sure, but who will use MUL/DIV to multiply/divide by 16 ?? :)

__
wolfgang

[Terence]

Wolfgang wrote:-
"Sure, but who will use MUL/DIV to multiply/divide by 16 ??"

The point is, the same multiple-entry routine which multiples or
divides by 10 OR 16 does the job of conversion to and from BCD and HEX
and binary. This use of one routine instead of four or six at a cost
of a fractional time difference, (IF ANY !)on using mult and div
operations instead of shift and masking in different routines. 16-bit
integer multiply is probably as fast as shifta and mask.

[Charles Crayne]

On 6 Apr 2007 18:44:29 -0700

Post by Terence
The point is, the same multiple-entry routine which multiples or
divides by 10 OR 16 does the job of conversion to and from BCD and HEX
and binary.

Which, of course, is what the standard C library function "strtol"
does, except that it does it for all bases between 2 and 32, and,
instead of having 31 different entry points, it accepts the base as an
input parameter.

[It also accepts zero as a base, but that is a different story.]

-- Chuck

[Wolfgang Kern]

I wrote:-
"Sure, but who will use MUL/DIV to multiply/divide by 16 ??"
The point is, the same multiple-entry routine which multiples or
divides by 10 OR 16 does the job of conversion to and from BCD and HEX
and binary. This use of one routine instead of four or six at a cost
of a fractional time difference, (IF ANY !)on using mult and div
operations instead of shift and masking in different routines. 16-bit
integer multiply is probably as fast as shifta and mask.

May be fine for MUL to save on additional routines,
but for DIV I'd go for it.

IF ANY? time difference:

SHL any,4
.... ;no need for a MASK here
is quite faster (even on the slow shifting Intel's) than:

MOV any,16
PUSH edx
MOV eax,....
MUL any
POP edx

and:
IMUL anyreg,imm8
is restricted to signed


Also if a 64 bit result is desired:

XOR edx,edx
SHLD edx,eax,4
SHL eax,4

MUL will be slower.

__
wolfgang

[[e-mail]]

Post by Terence
Did everybody miss that DCB uses a multiplier of 10 per nibble and hex
uses a multiplier of 16?
So a converter to binary for both BCD and HEX only differ in the
initialization of the multiplier value. Then the reverse conversion
case only differs in the divisor.

This being an assembly language newsgroup, I think you'll find most
participants are more interested in faster code than generalized code.
Your solution would save space if the OP needed to convert values in
different radixes to binary, but it would unquestionably be slower
(and not by a small amount, mind you) than a specific routine for the
job.

Ultimately, the amount of memory used by these types of functions
matters very little. Whether you have one routine, two routines, or 16
routines is really irrelevant on modern machines except in some *very*
rare cases (e.g., you're using all of them simultaneously and their
use causes cache thrashing). In practice, however, a typical program
is going to use hex and/or decimal and the amount of space required
for two specific routines is inconsequential. And if you really don't
care about the few cycles you're losing, you may as well use a HLL
standard library routine that does the job. Undoubtedly, this is a
homework problem, so performance doesn't really matter (hence my
solution -- which is easy on the programmer, not particularly fast),
but in general when someone assigns a homework problem asking for
conversions like this, they're looking for a specific solution. And I
*still* argue that it's unlikely the homework problem *really*
involved BDC. I suspect it's just asking for an atoi routine.
hLater,
Randy Hyde

[Terence]

I had a lot of trouble posting this; I hope thre are not multiple
ccopies...

This being an assembly language newsgroup, ...

Yes, Randy.

Ultimately, the amount of memory used by these types of functions
matters very little.

This it where we differ.
Most of my life has been used in writing code for small machines from
Mercury Star, 1401 and 1620 up. (1400 byte through 16k byte and even
wasteful 64 k. Then came the AT...). I even wrote a tape
perating systems that ran in overlaying 7-bit, 132 byte memory!

My busieness is still built on this. Evreything I do has to be tightly
coded.

If I use Fortran (when I'm not using ASM) I uses a DOS compiler, not a
Windows one, to get small code for the same job (32k instead of
1.5Meg) . And all my code calls on ASM routines to do things not
avialable in a highr level language (or do it better). I have a
library which provides a windows-type mouse and colour interface TUI
for dos-based programs

My point was (as others have ampiflied) to use ONE routine for
multiple radices and get a small overall almost-as-fast-as-optimum for
your trouble; rather than one for each flavour.

If you are busily converting to and from ascii, binary, BCD and HEX,
you have a user interface and a user in the way. Speed is not as
important as space when you wait for someone typing. I actually did
tiny code like I am discussing, to run on the tiny 8k control chip
inside a typical fax machine, to use it as an image processor for 65-
metre well logs in the oil industry.

Whether you have one routine, two routines, or 16 routines is really irrelevant on modern machines except in some *very* rare cases...

I don't think they are that rare.
After all, who are these people reading this site, if not users of ASM
and macinine code for tight situations? Else they would be using a
high level language or C++ in a "we-need-fast" situation such as a
compiler, and so be somwhere else.

[[e-mail]]

Post by Terence
I don't think they are that rare.
After all, who are these people reading this site, if not users of ASM
and macinine code for tight situations? Else they would be using a
high level language or C++ in a "we-need-fast" situation such as a
compiler, and so be somwhere else.

You know? My machine has 2GB RAM installed. Putting a couple of
different routines, say 1K each, into an object module winds up using
something like 0.00001% of my available memory (assuming I got the
number of zeros correct:-)). Granted, if *every* routine in a fair
sized program wound up getting duplicated like this, that would be bad
news, but that just doesn't happen in practice. And to answer your
comment -- most people *do* use high-level languages.

Clearly, in memory-constrained environments, duplicating code in this
manner is not a good idea. In those situations, you rarely need to
convert values in multiple radixes to binary. If you do, then I would
agree that a single routine involving multiplication isn't a bad idea.
It just doesn't come up that often on modern machines.
hLater,
Randy Hyde

[Jim Leonard]

Post by Terence
If I use Fortran (when I'm not using ASM) I uses a DOS compiler, not a
Windows one, to get small code for the same job (32k instead of
1.5Meg) .

Not to throw a wrench in the works, but you may be missing the forest
for the trees. A windows compiler, assuming it was written/updated in
the last 10 years, will produce faster code than your DOS compiler.
It may take advantage of the architectural changes of modern
processors, whereas the DOS compiler probably won't know anything
beyond basic Pentium.

There is an advantage in having a program so small it fits into L1
cache ;-) but since you're probably doing intense math, the windows
compiled may produce faster code.

[Terence]

Now I have to reply.

I don't want fast in a human environment; I want reliability.
A lot of clients can only get (or afford) 386 and AT computers or PII
and PIII machines with Windows 95 and 98 boxes. I'm talking mainly
Latin America, East Europe and North Africa.

Any client with the latest computer can run our code as fast as he
likes; there is perhaps a three-second end-to-end diference in
processing between slowest and fastest; disk speeds seem to be most
important in access to the data. And when there'a a human in the loop,
there's no difference I can see. What DOES hold things up is the
printer producing reports, whether in RTF format via WORD or laser or
matrix printer on fan-fold. So I'd suggest to buy a better printer
before upgrading a cpu in a business environment.

But a DVF Fortran compiled Windows executable is about 1.5 meg versus
32K for EXACTLY the same program compiled for DOS execution by an F77
compiler. That difference means dificulty in distribution of updates
(read telephone modems, not broadband), and hand-delivered 1.4meg
floppies with 60 programs on board