Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #21832
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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