topic Re: Binary search in assembly language in Operating System - Linux

Binary search in assembly language

Dodo_5 — Wed, 30 Jul 2008 01:00:21 GMT

I have written Perl code for binary search.I have the code in attached file.In code I have given input by using external file "table" having some animal names in sorted order & printed the index position of required animal name.
Can anyone please help me to convert it into assembly language?
If anyone can provide assembly language code for binary search (having different program logic),that will be also helpfull.
Thanks in advance..

Re: Binary search in assembly language

Steven Schweda — Wed, 30 Jul 2008 01:43:29 GMT

Assembly language for which CPU type? There
is more than one assembly language, you know.

Why would a sane person (or you) wish to
convert a program like this into a
non-portable assembly language, rather than
into some high(er)-level language like C?

Homework? Challenge? Mental disorder?

Re: Binary search in assembly language

Dodo_5 — Wed, 30 Jul 2008 05:53:44 GMT

thanks for your comments.
I want the code in HLASM assembly language.I want to put the assembler code in mainframe to replace the "SEARCH ALL" command in COBOL for binary search for performance improvement.
So Can anyone please provide me the HLASM assembler code for binary search?

Re: Binary search in assembly language

Steven Schweda — Wed, 30 Jul 2008 07:01:09 GMT

Why not code the binary search in COBOL (if
you think that the built-in is so slow)?

Or C? Or anything other than assembly?
Modern compilers for modern CPUs can often
optimize high-level-language code to get a
better result than even a good assembly
programmer will typically get.

Why do you believe that the binary search is
your performance bottleneck?

Re: Binary search in assembly language

Dennis Handly — Fri, 01 Aug 2008 07:44:23 GMT

>replace the "SEARCH ALL" command in COBOL for binary search for performance improvement.

Why would you think you can do better than what the compiler can do?

My COBOLII/iX compiler totally inlined SEARCH ALL, handling multiple keys with combination of ascending/descending.
The reason I did this, was the previous architecture had a runtime that was too complicated because it had to interpret how to compare the data types.

Re: Binary search in assembly language

Dodo_5 — Fri, 01 Aug 2008 23:44:30 GMT

I think converting HLL to assembly language will make execution faste.So I am trying it to convert.
Other than that if you have any other idea,you can share with me.
Also I want to know about the inlined code of "SEARCH ALL".What kind of modifications have you done in code & compiler?

Re: Binary search in assembly language

Steven Schweda — Sat, 02 Aug 2008 01:47:37 GMT

> I think converting HLL to assembly language
> will make execution faste.

What, you think that (1) the COBOL-generated
code is doing something stupid, and that (2)
you can generate better code than the
compiler's code generator?

(1): I doubt it.
(2): I doubt it.

http://www.thefreedictionary.com/dodo

See definition 3.

If (1) _is_ true, then you should be able to
do better using some other, easier-to-use
language than assembly. If that works, then
you can worry about what further improvement
you might get from converting your new code
to assembly (assuming that (2) is also true).

Re: Binary search in assembly language

Srimalik — Sat, 02 Aug 2008 06:09:50 GMT

Are you serious!!!!

You may not get any benifits out of it(including performance).

The oppourtunity cost(http://en.wikipedia.org/wiki/Opportunity_cost) lost will be too high in doing this.

I suggest converting the program to C will be eaiser/simpler/better.

Re: Binary search in assembly language

Dennis Handly — Sat, 02 Aug 2008 08:58:38 GMT

>I think converting HLL to assembly language will make execution faster.

Unless your COBOL compiler is pretty stupid, that probably won't help.

>Also I want to know about the inlined code of "SEARCH ALL". What kind of modifications have you done in code & compiler?

This won't help you because you would have to use the COBOLII/iX compiler on MPE/iX, which is out of support. ;-)

I was just mentioning it because I know how good the code can be. It's not rocket science.
Of course from the previous compiler, you can do a bad job too, where it is all done in the runtime library, with interpretation on every compare and worst of all, didn't know how to handle multiple sort keys. :-(