Chuck Guzis wrote:
On 4/5/2006 at
12:03 PM Don Y wrote:
But yes, I do miss having access to the carry bit, but the level of code
I'm writing nowadays has made that less of an
issue.
Some machine don't have a carry bit, so there's nothing to access.
IMOHO, the biggest problem with HLL's versus assembly is when an
architecture provides for a very useful instruction, but said instruction
doesn't exactly fit into the language. For example, the MMX instrtuctions
on the Pentium aren't terribly accessible from most Cs. So they're
implemented as intrinsics at best--and at that point, you might as well be
writing assembly.
On the other hand, HLLs are very useful for automatically selecting
instructions and optimizing them. I don't know what real-world gains are
made by realing the gain from the fact that LOOP is slower on a 486 than a
DEC CX, JNZ pair, but it's nice not to have to code for it. On the other
hand, few C compilers can generate parallel versions of the same subroutine
and say "If I'm running on machne that supports <fill in the blank
feature>, I'll just use the other version. I've got lots of x86 assembly
code that does just that when its determined that MMX is present or 386+
(32 bit registers) is available. The speed improvements in some cases can
be substantial.
One pleasure of a good optimizer is clever removal of invariants from the
inside of a loop. It allows one to write what one means without worrying
that the implementation is inefficient.
Does anyone know of any optimizing assemblers ? That is, ones that will
move instructions around for optimum scheduling?
Cheers,
Chuck
Jerome Fine replies:
About 20 years ago, I wrote some code in C which used
a much less than optimal algorithm to locate prime numbers.
To make a long story as short as possible, the inner loop
made use of code which looked like (I can't remember exactly):
unsigned integer i, itemp, k, l
NULL INTEGER N
...
itemp = l(i)
if k .lt. l(i++) then
gosub abc
else if k .ne. itemp / ELSE IF N
gosub def
else
gosub ghi
end if
Obviously, when I make the first test, the carry bit
is being tested ( Bhis / Bcc ) and a branch made
around the subroutine call. This would be in a
system where the hardware actually has a carry bit
available as well as auto-increment for the compare
instruction. However, an extremely clever compiler
would also be able to realize that the second test
requires ONLY one additional instruction in the form
of a Bne around the second subroutine call.
What I could never understand was why a null variable
was not allowed which assumed that the arithmetic
instruction had already taken place and the only
requirement was to test the condition code in the
required manner. This capability would, in hardware
that produced the correct condition codes, allow
repeated tests such as for the example above WHERE
THE CODE IN CAPITAL LETTERS IS USED INSTEAD.
For the actual example, when I wanted to produce a
production version, I only needed to edit the
assembler version of the code and remove extra
instructions which were not needed. In real examples
where a sufficiently intelligent compilier is not
available, is that is the best way to optomize
the code? I would appreciate a comment what attempts
to provide an answer to this specific question.
As for the use of the mmx instructions, I thought
that they allow for the use of 64 bit registers.
Doesn't that correspond to:
long long integer ivalue
As for an assembler that moves instructions around,
I have only just looked at the instruction set for
the Pentium with a view to using some of the features
to speed up the E11 emulator for some PDP-11 routines -
UDiv32 and UMul32 are ones that are first candidates.
Later I will likely attempt multi-precision arithmetic.
by the way, do mmx instructions allow 64 bit integers?
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
