Re: Faster HexToBuffer Routines


Betov wrote:

Dream on. I am not here for writing your absurd Library, clown.

How typical, you go on about how you can write code with 1/10th the
number of instructions;

???!!!... Where, please?

You forgot already?
Try reading back in this newsgroup just a week or so ago when you
claimed the library code was ten times as big as it needed to be.


I have always said that uncompetent programmers, like you, are
the ones, exactly, who care of size and speed optimizations,

Unlike people like you, who don't even know how to optimize for speed
or size?

because they have to face their own failure, and i have always
defended _Strategy_ Optimization.

Well, optimize your strategies all you want. As best you've
demonstrated thus far, however, your "strategy optimization" (whatever
that is) isn't helping you write a faster hex to buffer output routine
nor is it helping you write one in 1/10th the size. It's just a bunch
of big words you're spouting that really have no meaning. The proof is
in the pudding. As Julienne pointed out, you make all these claims and
never come through with the examples to prove your point. As such, no
one believes a word you say.




you claim that you can write the code that is
much faster.

"Claim"???!!!...

Yes. Try a little of your "strategic optimization" and prove your
point.



Not exactly, clown. What i write is faster. Period.

So why not post an example of a hex to buffer routine that is
significantly faster and prove your point? Why not copy the one out of
your disassembler and display it here for all to see. That way we'll
know how you write such faster code. I realize you're deathly afraid of
"helping" me by posting better code, but as your disassembler's code is
open source, surely posting it here won't matter because I already have
a copy of it, no?


It simply
_is_ and, so forth, i have no use of "claiming" anything. A
flat description is not a "claim", clown

Well, as long as your "flatly describing" how much faster your code is
(isn't that a bit of "self-selling", btw?), why don't you post your
code that is so much faster and let us see what a genius you are?
Again, you seem to make a lot of big claims, but you almost *never*
post code around here. This is an assembly language programming
newsgroup. Why don't you post some of this "assembly code" that you
claim to be so good at writing?

..


But, of course, when asked to produce the goods you just
weasle out of it with statements like the above.

Well, as i told you so many times, there are much enough Demos
available for all of the various Assemblers, in all Styles, of
all Sizes and of all compexities, for making very easily the
comparisons in between the various Assemblers Speeds, and your
lies and swindling will never change an inch to something that
anybody can see by himself.

This has nothing to do with speeds of assemblers or anything like that.
It has to do with the claim that you could write a faster hex to buffer
routine. I have no doubt that *someone* could write faster code than
what I've posted here, I just doubt that *you* are the person to do it.
So prove me wrong. Prove you're right. Post some code that is
significantly faster than what I've posted. And as long as you're
claiming your disassembler and assembler are so fast, why not just post
the code out of those programs?


Now, about your absurd Library, which tries to defeats any
concept of Assembly Programming by making it even more absurd
than what the most weird HLL could do, feel free to masturbate
alone on your conversions routines: For the real Asmers, they
all already know how to do it, depending on the requirements.

Yes, we've seen examples in this thread how "real" assembly programmers
complain about the complexity of the code I've posted (suggesting that
it should use a simpler algorithm so beginners can understand it) and
we've seen posted examples where someone has been using the same
routine for the past 25 years. While the examples given are good in
their own right, you will notice that the title to this thread is
"FASTER HexToBuffer Routines", not "easier-to-read", "easier-to-write",
"easier-to-understand", or "the same routine I've been using for 25
years." Now numeric to string conversion routines have been a
*frequent* subject in various assembly language newsgroups (including
this one). It's not like there haven't been 100s of solutions posted
over the years. I've looked at a whole bunch of them. The big problem
with *all* of these conversion routines written by "real assembly
language programmers" is that they tend to settle on simplistic
algorithms that are easy enough to understand rather than going for
speed. Again, I'm not going to claim that my routine is the fastest;
I've not bothered with instruction scheduling or anything like that
(whose performance properties vary by processor), but I've written a
*bunch* of different variations and compared their execution speed. On
my PIV, the algorithm I've posted is a pretty good one. Neither you,
nor any of the other respondants to this thread, have suggested
anything faster. For that matter, no one has *attempted* to provide
anything faster. Just a bunch of hand-waving about how "real assembly
programmers" could beat this. As I've said, thus far no "real assembly
programmer" has done this. Do you care to be the first?



By the way, did you noticed that you "Integer to Buffer" ***
did not get any echo, even from your prefered minions?

Did you notice I'm posting assembly code around here? Why do you try
that some time?
Cheers,
Randy Hyde

.

Quantcast