TalkChess.com

With my last engine Satana i've experimented programming a chess engine in C++; surely it is my own limitation but i can't get a decent program, that way. I thinked that programming in C++ would easyer the developing stage (i use C++ for business application, so i know it) and above all speed-up debugging but i was wrong. I find that the bugs are the same and the time needed to find them is not less in C++ than in assembly: they both depends on me, not on the language.

So i decided to come back to assembly programming, now that i can use the full power of the new 64bit registers. I've used partially MMX registers in Freccia but never the R8...R15 and XMM, available in Intel and AMD CPUs . It would be not fully portable, my engine, but i could continue the journey made with Drago -> Raffaela -> Freccia, in a more modern and fast way.

Above all, i'm the fool who still program in assembly, that's my role!

stegemma wrote:With my last engine Satana i've experimented programming a chess engine in C++; surely it is my own limitation but i can't get a decent program, that way. I thinked that programming in C++ would easyer the developing stage (i use C++ for business application, so i know it) and above all speed-up debugging but i was wrong. I find that the bugs are the same and the time needed to find them is not less in C++ than in assembly: they both depends on me, not on the language.

So i decided to come back to assembly programming, now that i can use the full power of the new 64bit registers. I've used partially MMX registers in Freccia but never the R8...R15 and XMM, available in Intel and AMD CPUs . It would be not fully portable, my engine, but i could continue the journey made with Drago -> Raffaela -> Freccia, in a more modern and fast way.

Above all, i'm the fool who still program in assembly, that's my role!

I go for less nodes instead of speed.

You might be interested in this port of stockfish to asm

https://github.com/tthsqe12/asm

(it is a work in progress it seems)

stegemma wrote:With my last engine Satana i've experimented programming a chess engine in C++; surely it is my own limitation but i can't get a decent program, that way. I thinked that programming in C++ would easyer the developing stage (i use C++ for business application, so i know it) and above all speed-up debugging but i was wrong. I find that the bugs are the same and the time needed to find them is not less in C++ than in assembly

To arrive at this conclusion, you must have been using C++ completely the wrong way. Even plain C, if used correctly, allows you to write code at a much higher level than assembly and use bricks or standard lib that are well tested.

And what of portability ? Once you've written your engine for x86-64 using some very specific hardware tricks all over the code, how will you port it to ARMv7, ARMv8 (or other) ? Will you rewrite large chunks of code for every new CPU feature that comes up ?

Anyway, if you have fun writing asembly, then that's what you should do. But if you think it will increase your productivity...

lucasart wrote:

stegemma wrote:With my last engine Satana i've experimented programming a chess engine in C++; surely it is my own limitation but i can't get a decent program, that way. I thinked that programming in C++ would easyer the developing stage (i use C++ for business application, so i know it) and above all speed-up debugging but i was wrong. I find that the bugs are the same and the time needed to find them is not less in C++ than in assembly

To arrive at this conclusion, you must have been using C++ completely the wrong way. Even plain C, if used correctly, allows you to write code at a much higher level than assembly and use bricks or standard lib that are well tested.

And what of portability ? Once you've written your engine for x86-64 using some very specific hardware tricks all over the code, how will you port it to ARMv7, ARMv8 (or other) ? Will you rewrite large chunks of code for every new CPU feature that comes up ?

Anyway, if you have fun writing asembly, then that's what you should do. But if you think it will increase your productivity...

Maybe one could write QuiesenceSearch in an intermediate language like MSIL for Microsoft.

lucasart wrote:

stegemma wrote:With my last engine Satana i've experimented programming a chess engine in C++; surely it is my own limitation but i can't get a decent program, that way. I thinked that programming in C++ would easyer the developing stage (i use C++ for business application, so i know it) and above all speed-up debugging but i was wrong. I find that the bugs are the same and the time needed to find them is not less in C++ than in assembly

To arrive at this conclusion, you must have been using C++ completely the wrong way. Even plain C, if used correctly, allows you to write code at a much higher level than assembly and use bricks or standard lib that are well tested.

And what of portability ? Once you've written your engine for x86-64 using some very specific hardware tricks all over the code, how will you port it to ARMv7, ARMv8 (or other) ? Will you rewrite large chunks of code for every new CPU feature that comes up ?

Anyway, if you have fun writing asembly, then that's what you should do. But if you think it will increase your productivity...

Yes, this is what i was thinking when i've started the C++ engine and all it's right. What i've found is just that productivity has not been increased working in C++ and the same for debugging. This one was the most hard part of the work but it is do not for the language itself but for the complexity of the chess tree. Likely, writing the C++ engine i've found that most of the bug were the same than in assembly: they was done because of my bad knowledge of some algorithm and i have repeated the same bugs both in assembly and C++. My "back to assembly" would starts to remove the algorithm bugs from Freccia (the last asm engine) the same as i have seen in Satana (the C++ one).

As many "older" programmers, i've learn assembly before C and C++... so my personal neural network has grown from that base

I was thinking about to write a simple preprocessor, that let me easly traslate intel assembly code into C or other cpu assembly. It would be something less than C, because it just traslate single istructions, without any further optimization:
This way i can program in assembly and keep portability. Of course i would add to the preprocessor only those instructions that i really use, i don't need a general purpose tool.

Using intermediate languages would increase complexity and lower the speed, i think. My experiment to use genetical algorithm lead to nothing, to me.

Of course the interface between the engine and WinBoard is still in C++, i want to rewrite only the engine itself.

stegemma wrote:I was thinking about to write a simple preprocessor, that let me easly traslate intel assembly code into C or other cpu assembly. It would be something less than C, because it just traslate single istructions, without any further optimization:

Code: Select all

test proc
mov R8, 1
ret
endp

->
// global CPU registers
uint64_t R8,R9,R10,R11,R12,R13,R14,R15;
void test()
{
  R8 = 1;
}

This way i can program in assembly and keep portability. Of course i would add to the preprocessor only those instructions that i really use, i don't need a general purpose tool.

Using intermediate languages would increase complexity and lower the speed, i think. My experiment to use genetical algorithm lead to nothing, to me.

Of course the interface between the engine and WinBoard is still in C++, i want to rewrite only the engine itself.

Experimenting with automatic tuners is for extreme lazy developers only. Just start and stop the tuner all days long. So lets start. First I have to create the tools. That's the draw back.

So there some other fool out there!

stegemma wrote:I was thinking about to write a simple preprocessor, that let me easly traslate intel assembly code into C or other cpu assembly. It would be something less than C, because it just traslate single istructions, without any further optimization:

Code: Select all

test proc
mov R8, 1
ret
endp

->
// global CPU registers
uint64_t R8,R9,R10,R11,R12,R13,R14,R15;
void test()
{
  R8 = 1;
}

This way i can program in assembly and keep portability. Of course i would add to the preprocessor only those instructions that i really use, i don't need a general purpose tool.

Using intermediate languages would increase complexity and lower the speed, i think. My experiment to use genetical algorithm lead to nothing, to me.

Of course the interface between the engine and WinBoard is still in C++, i want to rewrite only the engine itself.

You might find that a challenge. The instruction sets of non-intel machines vary WILDLY from what Intel does. So there is no one-to-one translation possible. For example, a SPARC only has a memory load and store instruction to access data in memory, while intel can use one memory operand in most instructions. Things like imul/idiv are way different as well. not to mention simple things like the loop instruction. Some don't have compare instructions, some combine the compare and jump into one instruction, etc...

And then there is the memory addressing where the intel "scale factor" doesn't exist in the same way ([array + 8 * esi] as just one example. This might be harder than a c compiler if you try to cover all architectures.