Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: ?a/b on 10 Feb 2006 04:24 On 9 Feb 2006 09:51:55 -0800, "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: >?a\/b wrote: >> >If you have a "minimal x86 cpu", why not just use a C compiler? >> >> because i like more assembly than C, because i think there are many >> routines and functions that have to be written in assembly (e.g. >> numerical routines, OS routines, games etc) > >But in those very areas you mention, far *more* routines and functions >are written in HLLs, like C. There are, of course, several special >cases that require assembly or benefit from coding in assembly, but in >the real world most of the code you mention is written in C or some >other HLL. So the question remains, why not just use a C compiler and >drop into assembly for those *few* routines that need it? You have, of >course, answered the question. The answer is "because I like assembly >more than C" Period. Stop there. The rest of your statement doesn't >support the answer you give. numeric routines, OS routines, game routines, have the need of a language more near the machine than C >> >In fact, I write in assembly to use the specifics of x86, the MMX >> >the SSE instructions. >> >> i think like Betov: 25 instruction are enough; > >Theoretically, we can show that *one* instruction is enough (indeed, >one-instruction CPUs have actually been built as research projects >IIRC). Having fewer instructions makes the instruction set easier to >learn. to learn and to use >It does not make it easier to program i don't agree >and it certainly doesn't >help you gain an advantage over HLLs or other CPUs with more >instructions. It just makes it easier to memorize the instruction set. i don't agree >Now granted, a *typical* application may only use 25-50 instructions. >But the exact subset of the instruction set applications employ >*varies* across different applications. Multimedia apps are likely to >use instructions that database apps don't use, and vice-versa. If you >only write applications in one area, you *might* be able to get away >with using only a subset of the instruction set. >But if you write a >large number of different applications, it's unlikely you'll be writing >the most efficient code if you do this. After all, you can stick to the >original 8086 instruction set (which probably has far more instructions >than you want). Surely there must be some reason for all the new 286, >386, 486, and Pentium * instructions that have been added over the >years? >> than can change cpu >> registers size but the instructions are the same. to add more >> instructons is not an advantage for an assembly programmer > >Then why have they added all these new instructions over the years? don't know why they add FPU instructions in a 386 cpu; because i think it is possible and easer to write fixed-point routines using 32 bits registers. i like 386 cpu and think follow instructions can be divided in easy 386 instructions. if this is not efficient one can imagine 386 cpu with 64 bits registers too :) >Yes, it is more work to *learn* all these instructions. That could be >construed as a disadvantage, but the whole point of coding in assembly >language rather than a HLL like C is because you can take advantage of >all the instructions (which most HLLs cannot do). this is *the point* where we are not agree too the point is there are routines that *are* assembly routines if you write them in another language you have to replace 1-cpu-instruction with 3-4 cpu instructions for each instruction then and most important all you seem not have a good [or the] definition of assembly language nor all you have assemblers that reduce instruction dimension and allow indentation with 1..10 instructions for line in your hands assembly language has 1/100 of the really power it has
From: Betov on 10 Feb 2006 05:13 "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> ?crivait news:1139530418.441538.201780(a)f14g2000cwb.googlegroups.com: > Then again, FASM, which does a *much* > better job than RosAsm at optimizing code sequences is better than 2x > faster on all the tests I've run, so it doesn't seem like Rene's > optimization was all that "strategic". :)) Too bad for you, that the FASM guys _refuse_ to even _consider_ your bullshits. :)) Betov. < http://rosasm.org >
From: Betov on 10 Feb 2006 05:18 "Charles A. Crayne" <ccrayne(a)crayne.org> ?crivait news:20060209181653.6a25db5c(a)heimdall.crayne.org: > On 9 Feb 2006 16:33:55 -0800 > "Dragontamer" <prtiglao(a)gmail.com> wrote: > > :[The First Rule of Program Optimization] Don't do it. > > The version I like best is: > > "Coding without design leads to optimizing without end." I prefer mine: "When you see a guy talking of Code Level Optimization, this is the demonstration, that he is not an Assembly Programmer". Betov. < http://rosasm.org >
From: randyhyde@earthlink.net on 15 Feb 2006 15:15 Dragontamer wrote: > > I take it you haven't been reading much recently on Software > Engineering... The first rule of optimization is don't... > > It has been well known for years you shouldn't optimize your > code. The majority of the industry (in my eye anyway) seems > to spend no time optimizing, regardless of their language. You might read the complete essay: http://weblogs.mozillazine.org/roc/archives/2005/11/immature_optimization.html Here's the pertinent quote: >>>> There's a folklore quote "premature optimization is the root of all evil", attributed to Tony Hoare and Donald Knuth. A variant is due to my PhD advisor's father Michael Jackson: "The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.". Unfortunately --- and I'm not the first to note this --- this advice, taken out of context and followed slavishly, often leads people into deep trouble. The problem is that it collides with another well-known feature of software development: it gets more expensive to make changes to the system later in its development, especially cross-cutting changes that impact module interfaces. If you leave optimization to late in development, then profile it and find that fixing the performance bottleneck requires a major change in your design, or forces major module interface changes, then you have a serious problem. <<<< Cheers, Randy Hyde
From: Dave on 16 Feb 2006 00:44
I think that optimization should be done last or near last, if and only if it is provable that the current implementation will not provide adequate performance. The first thing that must be done is to design an efficient program/system. The low-level optimization we usually refer to in an assembly newsgroup is for much later when your tools or processor are just not enough to get it done. If the design and algorithm are good only a few things such as games need a final assembly optimization pass. Then I would suggest you have measured what is slow and go for the biggest gains for the most used code. On 15 Feb 2006 12:15:26 -0800, "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: > >Dragontamer wrote: >> >> I take it you haven't been reading much recently on Software >> Engineering... The first rule of optimization is don't... >> >> It has been well known for years you shouldn't optimize your >> code. The majority of the industry (in my eye anyway) seems >> to spend no time optimizing, regardless of their language. > >You might read the complete essay: > >http://weblogs.mozillazine.org/roc/archives/2005/11/immature_optimization.html > >Here's the pertinent quote: > >>>>> >There's a folklore quote "premature optimization is the root of all >evil", attributed to Tony Hoare and Donald Knuth. A variant is due to >my PhD advisor's father Michael Jackson: "The First Rule of Program >Optimization: Don't do it. The Second Rule of Program Optimization (for >experts only!): Don't do it yet.". Unfortunately --- and I'm not the >first to note this --- this advice, taken out of context and followed >slavishly, often leads people into deep trouble. The problem is that it >collides with another well-known feature of software development: it >gets more expensive to make changes to the system later in its >development, especially cross-cutting changes that impact module >interfaces. If you leave optimization to late in development, then >profile it and find that fixing the performance bottleneck requires a >major change in your design, or forces major module interface changes, >then you have a serious problem. ><<<< >Cheers, >Randy Hyde |