• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 587
  • Last Modified:

Assembly inline function

i have a senario where i want to treat all my numeric values as characters but still do all the arithmetic operations on that character data which basically comprises of numbers. i also do not want to use all the conversion fuctions available in c or c++ to convert into arithmetic value and do operations because it reduces performance of the application. so i am thinking of using assembly inline fuctions for the arithmetic operations alone. my environment of developement in VC++. can i use assembly inline fuctions?.
0
vabdussamad
Asked:
vabdussamad
  • 7
  • 6
  • 4
  • +2
1 Solution
 
vabdussamadAuthor Commented:
Edited text of question.
0
 
WxWCommented:
You can put inline assembly in a function with the asm {

for example :

void x(...)
  {
  ...
  asm {
    mov eax,4
    ...
    }
  }

A better approach is to create an ASM file , assemble to OBJ and then link it against your C++ program.
0
 
vabdussamadAuthor Commented:
Sorry WxW. My purpose of asking the question was will i be able to treate a charater data to do all arithmetic operations using assembly language,
say i have like,

char *a = "1238178912";
char *b = "87687817367.6783";

will i be able to add this two numbers in the form of characters using assembly language, and also i should not have restriction on the lenght of my number in the form of character. I would appreciate if i get a sample code in assembly that adds the above two numbers. The rest of the operations like subtract, divide, i can manage by seeing the code.

thanks in advance.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
vabdussamadAuthor Commented:
Sorry WxW. My purpose of asking the question was will i be able to treate a charater data to do all arithmetic operations using assembly language,
say i have like,

char *a = "1238178912";
char *b = "87687817367.6783";

will i be able to add this two numbers in the form of characters using assembly language, and also i should not have restriction on the lenght of my number in the form of character. I would appreciate if i get a sample code in assembly that adds the above two numbers. The rest of the operations like subtract, divide, i can manage by seeing the code.

thanks in advance.
0
 
WxWCommented:
I don't think that simple atof(a) + atof(b) will take much more time than inline assembly . Is that really important for you if you increase the speed a bit , but risk a confusion in the function and maybe bugs in assembly code ?
0
 
nietodCommented:
>> simple atof(a) + atof(b) will take
>> much more time than inline assembly
Atof is likely to take many 100s of thousands of clock cycles.  Then you need to perform math on the floating point values, which is relatively quick, and then convert back to ASCII again, which is extremely slow again.

In many cases it is much faster to do all the math in BCD, which eliminates the conversions to and from floating point.  In addition BCD can be done to arbitrary levels of precission, like Like hundreds of decimal digits, 80 bit floating opoint only provides a little more than 20 decimal digits of precission.

vabdussamad, you certanly can do this in VC, I DO.  Your best best is to write the functions entirely in C++ though, then profile the functions and convert the bottlenecks to assembly.  I can tell you from experience that there is no need to write it all in assembly.  
0
 
vabdussamadAuthor Commented:
i dont understand whether nietod says what i asked can be done or it cannot be. as far as i have i have understood i think he says it can be done. But point is i am working in a project where we are are writing a filter that converts a LINC application which runs on UNISYS mainframe into VC++. The LINC treats all datatypes as characters and does calculations based on length of the number rather than number itself like,

      temp = 000027656
      if length of temp equal to 9
            do some operation
      else
            do some operation

here even zeros remain prefixed but in c++ if we asign a number prefixed with zeros to any numeric datatype the the zeros are removed. And also LINC has very lengthy numeric representation like more than 20 digits which is very difficult to represent in c++. so we could no more use them like how LINC does. The C++ method like atof(a) has already been implemented but we found performance very low. so we thought of treating all datatypes in LINC as characters in C++ also. So i would appreciate if you could give me a sample code that adds two charater numbers like

      char a = "765757572";
      char b = "7886886.091208";
0
 
nietodCommented:
It certainly can be done.  The techique you want to use is called "Binary Coded Decinmal" or BCD.  In C++ you store the numbers as an ASCII string that represents the number.  (There are other storage options, some of which are more space efficient, but this is likely to be easiest for you.)  You also need to store the sign associated with the number (+ or -), you could store this inside the string, but I find that adds complications.  Instead I would store it deperately as a boolean.  

To use this in C++, I would create a class that stores the digit string and sign boolean and then define the necessary mathematical operations for that class.  For example,

class BCDNum
{
   string Digits;
   bool   Positive;
};

I'm afraid that due to propriatary reasons, I cannot release any code I've written in connection with BCD arithmatic.  All I can suggest is that you just make the computer do the arithmatic exactly like you would on paper.  For each digit position you will add two digits and an optional carry (1) and store the result in the same position of the resulting number.  When you start out, the carry will be 0, each time you add a pair of digits you will use the carry from the previous pair.  When you start out, you begin with the least significant position (rightmost).   Then you will move to more significant (left) digits each time. When you add a pair of digits (and the previous carry) for a position, if the result is greater than 9, subtract 10 from it and set the cary to 1, then store the result.  If the result is less than 10, then just clear the carry (set it to 0) and store the result.

Does that help?
0
 
vabdussamadAuthor Commented:
Thanks a lot nietod. That was really a good answer well said. I dont want to again ask for sample but can you atleast tell me some good source. A book where examples are given and not only the explanations for assembly instructions because i dont have time to read and also i have pretty good knowledge of 8086 programming. also suggest me if this way of programming would improve the performance of my application from using the c++ function like atof() etc.


thanks
0
 
mbormannCommented:
do check out
http://www.cs.uiowa.edu/~jones/bcd/bcd.html
and see if it's useful

dont have time to explain everytthing ,relaxing from work for a while.
0
 
mbormannCommented:
>>>>>
For
example, when a numeric field of a record in a text file must be incremented, the methods presented
here will be significantly faster than converting the textual value to a binary integer, incrementing, and
then converting back to text
0
 
mikeblasCommented:
nietod> Atof is likely to take many 100s of thousands of clock cycles.  
You're off by at least one order of magnitude. If you're talking about the Visual C++ implementation of the function, you're off by two.

      atof("13514.13434");

takes about 750 clock cycles,

while

      atof("10.3e15");

takes a few more than 1000 clock cycles.

With modern numeric coprocessors so readily available (built into every 486DX chip and newer; built into all DEC Alpha processors; built into all 68040 and better processors), your implied performance comparison between BCD and floating point math is not very valid.

 nietod> All I can suggest is that you just make the
 nietod> computer do the arithmatic exactly like you would on paper.  

If you do this, you'll find that any performance advantage you think BCD has goes up in smoke. There's lots faster ways to do BCD math--some of the best publicly available algorithms are available in the "Seminumerical Algorithms" volume of Donald Knuth's "The Art of Computer Programming" series.

..B ekiM
0
 
mbormannCommented:
>>>>>some of the best publicly available algorithms are available
in the "Seminumerical Algorithms" volume of Donald Knuth's "The
Art of Computer Programming" series

vabdussamad,
but they r in 'Mix' - a hypothetical assembly language.

Luck to u ,but I dont think many people would help u out in code.
0
 
mikeblasCommented:
Dang it!  I was in the middle of double-checking my answer when I tapped [ENTER] on the wrong keyboard.  It turns out that _these_ are the correct measurements:

      atof("13514.13434");

takes about 750 millionths of a second to execute on my Pentium Pro 400 MHz machine. That translates to about 300000 clock cycles, assuming there was no task switching. Since 750 millionths of a second is much (much!) smaller than a Windows time quantum, that's unlikely.

It turns out that Nietod's range of times for the expense of atof() _are_ correct.  My meausrement mechanism takes into account some debugger overhead, though...

But I stand by the comparison of BCD with FP. Actual _math_ is not so expensive because the coprocessor is optimized to do the work in silicon.

The good news is that, beyond the shadow of doubt, the recommendation of the Knuth book is irrefutable.

..B ekiM
0
 
mikeblasCommented:
Hmmm.  This has turned into an interesting problem.

It seems like my original quick-and-dirty method of timing the code was much (much!) coarser than I thought. Using QueryPerformanceCounter(), it looks like  atof() takes only 9300 clock cycles.

But, can I really draw a conclusion on that?

..B ekiM
0
 
mikeblasCommented:
> but they r in 'Mix' - a hypothetical assembly language.

No, they "r" not. These routines "r" spelled-out as algorithms--step by step instructions written in English. "u" don't need "2" learn MIX, but "u" do need "2" read the steps and decide what they mean in the language "u" "r" using.

..B ekiM
0
 
mikeblasCommented:
> Luck to u ,but I dont think many people would help u out in code.

See the BCD.DLL sample in my book. It does integer addition, subtraction, and multiplication. It's based on the algorithms presented by Knuth in his book.

..B ekiM
0
 
vabdussamadAuthor Commented:
mikeblas you said your book but what is the name and where to find it whether it will be available in india. please reply as soon as possible because i need this done very urgently.
0
 
mikeblasCommented:
> said your book but what is the name

The current edition is called "Professional MFC with Visual C++ 6", and the previous is with VC++ 5.

 > and where to find it

Any good bookstore can order it, if they don't have it on the shelf. amazon.com, barnsandnoble.com, and fatbrain.com all sell it online. I think the publisher (wrox.com) sells it online, too.

 > whether it will be available in India

I've received email from readers in India, so I assume it must be avialable there.

..B ekiM
0
 
nietodCommented:
Sorry, I've not responded, I've had unbelievable computer problems!  What's more I'm now connected to the net again and leaving tomorrow for a week.  

>> If you do this, you'll find that any performance
>> advantage you think BCD has goes up in smoke
Probably a bit extreme, but definitely some truth to it.

The real advantage to BCD is not speed.  In simple cases (limited precission) it is not likely to be faster than floating point, and even if it is, both are likely to be so fast that you probalby won't see a difference.  BCD's real advantage is that it can support any necessary level of precission.  i.e they can support any number of digits needed with complete accuracy.  Floating point numbers round after a certain number of significant digits.
0
 
mikeblasCommented:
> The real advantage to BCD is not speed.  

Certainly not!

 > both are likely to be so fast that you probalby won't see a difference.  

It depends on how much precision you're using.

..B ekiM
0
 
nietodCommented:
>> It depends on how much precision you're using.

Assuming the precission is about that of the floating point number.   (limiting the floating point number range so that it specifies the 1's place .)  In that case the BCD math isn't likely to be more than an order of magnitude slower than the floating point, and most applications aren't likely to be so math intensive to notice this.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 7
  • 6
  • 4
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now