Back to assembly

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
stegemma
Posts: 859
Joined: Mon Aug 10, 2009 8:05 pm
Location: Italy
Full name: Stefano Gemma
Contact:

Back to assembly

Post by stegemma » Fri Feb 13, 2015 7:37 am

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! ;)

Henk
Posts: 5797
Joined: Mon May 27, 2013 8:31 am

Re: Back to assembly

Post by Henk » Fri Feb 13, 2015 8:11 am

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.

yolin
Posts: 30
Joined: Thu Mar 30, 2006 4:12 pm

Re: Back to assembly

Post by yolin » Fri Feb 13, 2015 10:21 pm

You might be interested in this port of stockfish to asm

https://github.com/tthsqe12/asm

(it is a work in progress it seems)

User avatar
lucasart
Posts: 3037
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: Back to assembly

Post by lucasart » Sat Feb 14, 2015 12:47 am

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... :lol:
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

Henk
Posts: 5797
Joined: Mon May 27, 2013 8:31 am

Re: Back to assembly

Post by Henk » Sat Feb 14, 2015 8:21 am

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... :lol:
Maybe one could write QuiesenceSearch in an intermediate language like MSIL for Microsoft.

User avatar
stegemma
Posts: 859
Joined: Mon Aug 10, 2009 8:05 pm
Location: Italy
Full name: Stefano Gemma
Contact:

Re: Back to assembly

Post by stegemma » Sat Feb 14, 2015 8:25 am

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... :lol:
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 ;)

User avatar
stegemma
Posts: 859
Joined: Mon Aug 10, 2009 8:05 pm
Location: Italy
Full name: Stefano Gemma
Contact:

Re: Back to assembly

Post by stegemma » Sat Feb 14, 2015 8:38 am

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.

Henk
Posts: 5797
Joined: Mon May 27, 2013 8:31 am

Re: Back to assembly

Post by Henk » Sat Feb 14, 2015 9:17 am

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.

User avatar
stegemma
Posts: 859
Joined: Mon Aug 10, 2009 8:05 pm
Location: Italy
Full name: Stefano Gemma
Contact:

Re: Back to assembly

Post by stegemma » Sat Feb 14, 2015 9:40 am

So there some other fool out there! ;)

bob
Posts: 20473
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Back to assembly

Post by bob » Sat Feb 14, 2015 3:44 pm

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.

Post Reply