Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #21832

Re: My opinion re LISP

Newsgroups comp.lang.forth
Date 2013-04-22 21:41 -0700
References <kkjs0j$hvt$2@dont-email.me> <471240d3-0b19-4d8c-9f98-0afd6fc5c8a0@pd6g2000pbc.googlegroups.com> <7fa22bd0-de44-4b0c-ac6d-0209cf8019df@di5g2000pbc.googlegroups.com> <kl3s3v$1j5$2@online.de>
Message-ID <e9fa709e-e257-4d84-b077-8f3692eba44d@k6g2000pbq.googlegroups.com> (permalink)
Subject Re: My opinion re LISP
From Hugh Aguilar <hughaguilar96@yahoo.com>

Show all headers | View raw


On Apr 22, 10:30 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Hugh Aguilar wrote:
> > Also, if you really must put NOP instructions inside of functions
> > (more than one loop, for example), you don't need to use 5 NOP
> > instructions --- there are multi-byte instructions that are effective
> > NOP instructions, but which are faster because only one instruction is
> > being decoded and executed, rather than several.
>
> Yes, the Intel optimizing manual lists a number of nops and ways to generate
> longer nops without making the decoder slow by using e.g. size prefixes
> (something doing nothing can do that with 16 or 32 bit integers and
> addresses).

The Intel Optimizing manual (vol 2) says a lot of things, but it is
difficult to put it all together into a comprehensive picture. For
example, it says to paragraph align function entries and jump
destinations, as the decoder loads whole 16-byte paragraphs at a time,
as if this were canon. But it also says that there are a limited
number of 64-byte pages available in the code cache. So there is a
conflict here!

I started out in my Forth dutifully paragraph aligning everything, but
then I realized that it is much more important to minimize page usage,
so now I only paragraph align the really speed critical stuff. Also,
as I said, paragraph aligning doesn't matter anyway if the length of
the function is such that the end of the function is closer to a
paragraph boundary than the front of the function is to its paragraph
boundary, because you get the same number of paragraphs loaded no
matter what you do. Also, I was told on CLAX that the decoder doesn't
have to reload paragraphs and decode the code in a small tight loop,
because it is able to just go with what it has decoded already.

Over on the FASM forum, I asked about a smart ALIGN macro that does
multi-byte nop instructions, and which also only paragraph aligns if
it is less than 8 bytes from the paragraph boundary, but does nothing
if it is more than that. Nobody had anything, so I suppose I will have
to write it myself. I also brought up the idea of a program that would
examine the listing file that FASM generates, and rearrange the order
of the functions such that it minimizes the number of decoder loads
that will be needed for all of the functions, and also minimizes the
amount of wasted memory between all of the functions. This would be
like the Traveling Salesman problem --- a real combinatorial
explosion! Nobody has done anything like this. I could probably write
such a program, although it would be tough. It would mostly only be
useful for writing a VM, because in that case you have hundreds of
short functions, and it is very important to get them all to fit in
the 32K code-cache, and also to make them execute as quickly as
possible --- it wouldn't be useful for the typical assembly-language
program, which has relatively few functions, and they are all
gigantic.

I'm just a newbie at x86 assembly-language. I haven't messed with the
x86 since the mid 1990s, and that was the Pentium. In those days,
assembly-language was super-simple. We had the U and V pipes, and we
could pretty much know at compile-time exactly what was going to
happen at run-time. Now, everything is much more complicated and
occult! I don't really like assembly-language. It is like voodoo ---
you get all of these rituals (like paragraph aligning functions), but
you don't know how well they work or even why they work, because the
internals of the x86 are proprietary. That Intel Optimization manual
that you mentioned really reminds me a lot of a grimoire! We can't
understand what is going on, the way that we could with the Pentium,
so we just do the rituals and hope for the best.

Back to comp.lang.forth | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

re: My opinion re LISP "WJ" <w_a_x_man@yahoo.com> - 2013-04-16 15:50 +0000
  Re: My opinion re LISP Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-04-20 21:20 -0700
    Re: My opinion re LISP Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-04-21 16:46 -0700
      Re: My opinion re LISP Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-22 19:30 +0200
        Re: My opinion re LISP Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-04-22 21:41 -0700
          Re: My opinion re LISP Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-23 23:04 +0200
            Re: My opinion re LISP Ron Aaron <rambamist@gmail.com> - 2013-04-24 06:10 +0300
            Re: My opinion re LISP Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-04-23 22:17 -0700
            Re: My opinion re LISP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-24 11:59 +0000
      Re: My opinion re LISP Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-04-22 21:49 -0700

csiph-web