Moderators: hgm, Rebel, chrisw
GCC and Clang support computed goto in C.Michael Sherwin wrote:my jump table style of chess programming
That's not a project of its own since it relies on Stockfish. Means, in order to even have asmfish, you need roughly twice the manpower. With constant manpower (which is Michael's situation), you would have much less time for the algorithms.abulmo2 wrote:What about asmfish ?
I have done that myself. But it is not the optimal solution. Because you start with the framework dictated by the compiler. You might find more efficient instructions or combinations, but you are still working with how the compiler did things. For Cray Blitz, Harry and I started from scratch. Completely from scratch. Now we are able to make register assignments as we choose, and since we primarily write "leaf routines" we don't have to worry about registers getting overwritten when we don't call anything that could do so.Rebel wrote:I am not BobMichael Sherwin wrote:I don't mean to be a pain but to me it sounds like you are describing the C++ way. I know that C++ objects can be simulated in C using structures and being strict in using function calls accordingly. But then I might as well use C++. In my way of thinking C++ using objects is superior for a team project so team members do not trample all over another team members variable names and function names. For a single person working on a one file source C++ methodology does not seem (as) beneficial. I can write 32 bit assembler with the best of em. However, the nuances of 64 bit assembly is giving me a hard time or I'd be writing this primarily in assembler. My goal is writing code that is as fast as it can be. I have sort of a reputation for that or at least I did when RomiChess first came out and also my perft examples I wrote. My perft example in 32 bit assembler runs at 65 million nodes per second using a single thread on my 3.4GHz i7. Not bragging, just saying I like to stick with my programming style. And learning a new paradigm at my age is not easy. What you are suggesting that I should do by passing a pointer around I understand would not make a very noticeable difference in speed but learning a whole new paradigm at my age would certainly slow my progress. I thank you for the philosophical discussion and anything more that you would like to add. I wonder what others might think about what you are suggesting.
Bob?but what I did in the past (32 bit of course) is to write stuff in C then look at the ASM code the compiler generated and then manually optimize it. Perhaps it makes sense for 64 bit as well.
Why? I actually think that long mode in x64 (AMD 64) is a natural extension to x86, basically boils down to REX prefix (sacrificing 1-byte inc/dec instructions)bob wrote:I would add that 64 bit code (Intel world) is beyond a messy environment. It was a HUGE kludge (64 bit instructions added) on top of an already HUGE kludge
Well of course you need a good compiler. I had one. And nowadays they are (no doubt) even better. So I don't see a problem there.bob wrote:I have done that myself. But it is not the optimal solution. Because you start with the framework dictated by the compiler.Rebel wrote:I am not BobMichael Sherwin wrote:I don't mean to be a pain but to me it sounds like you are describing the C++ way. I know that C++ objects can be simulated in C using structures and being strict in using function calls accordingly. But then I might as well use C++. In my way of thinking C++ using objects is superior for a team project so team members do not trample all over another team members variable names and function names. For a single person working on a one file source C++ methodology does not seem (as) beneficial. I can write 32 bit assembler with the best of em. However, the nuances of 64 bit assembly is giving me a hard time or I'd be writing this primarily in assembler. My goal is writing code that is as fast as it can be. I have sort of a reputation for that or at least I did when RomiChess first came out and also my perft examples I wrote. My perft example in 32 bit assembler runs at 65 million nodes per second using a single thread on my 3.4GHz i7. Not bragging, just saying I like to stick with my programming style. And learning a new paradigm at my age is not easy. What you are suggesting that I should do by passing a pointer around I understand would not make a very noticeable difference in speed but learning a whole new paradigm at my age would certainly slow my progress. I thank you for the philosophical discussion and anything more that you would like to add. I wonder what others might think about what you are suggesting.
Bob?
Sure, I still could improve new stuff typically with 20-30%. The main work was to rearrange the register use of the compiler (avoiding memory use) that dd the trick among some minor stuff.bob wrote: You might find more efficient instructions or combinations, but you are still working with how the compiler did things.
bob wrote:I would add that 64 bit code (Intel world) is beyond a messy environment. It was a HUGE kludge (64 bit instructions added) on top of an already HUGE kludge (the x86 instruction is not exactly the best laid out instruction set I have seen, just like the processor architecture really suck when compared to much better ones that didn't try to maintain backward compatibility with 8 bit architectures...
I can think of lots of things that are wrong. Little endian is a retarded design that came due to backward compatibility with the original 8 bit architecture. Many machines have done it right (big endian). The restrictions on which registers can be used for what. General Purpose registers have been around forever. It is simply what you get when you keep hacking on an instruction set to add new features. At some point in time, you have to step up and re-design. Cray did this when the YMP came along. It was already a pretty good architecture, but they moved to the 32 bit addressing model rationally rather than a cobbled/hacked up instruction format.mar wrote:Why? I actually think that long mode in x64 (AMD 64) is a natural extension to x86, basically boils down to REX prefix (sacrificing 1-byte inc/dec instructions)bob wrote:I would add that 64 bit code (Intel world) is beyond a messy environment. It was a HUGE kludge (64 bit instructions added) on top of an already HUGE kludge
and defaulting to 64-bit regs for addressing modes, zeroing upper 32 bits
where destination is 32-bit register is also a good thing so I actually like that.
There's a bit more to it, but those 3 are the most important ones.
So if you know how to write 32-bit assembly then switching to x64 is actually piece of cake. And you also have twice as many registers.
What I dislike about the x86 instruction set is that I have to use cl to do variable shifts, but I can live with that.
Backwards compatibility depends on POV, you can still run 32-bit apps and for those who write x86 machine code generators, it's also welcome.
Oh and I'm really grateful that x86 arch is little endian.
Little endian has one important property, fetching smaller integer from the same address. This is the reason why BE sucks and why LE is actually useful.bob wrote:Little endian is a retarded design that came due to backward compatibility with the original 8 bit architecture. Many machines have done it right (big endian).
The customers have decided that they don't want to throw away all the software they already paid for. That's why backwards compatibility won, because it addressed the needs of the paying customers.bob wrote:It is simply what you get when you keep hacking on an instruction set to add new features.
