Back to assembly

[stegemma]

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.

That's true but my approach is simpler, as you can see from the code sample: convert intel assembly directly to C, to handle any different platform. This let me enjoy with intel assembly programming, keeping the engine portable. On other platforms, the C compiler would take care about optimization, i'm interested in the performance only on intel platform. Still, i could find that assembly-converted-to-C engine is faster than the original, maybe even on intel platform... but this would be a great result by itself.

[bob]

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.

That's true but my approach is simpler, as you can see from the code sample: convert intel assembly directly to C, to handle any different platform. This let me enjoy with intel assembly programming, keeping the engine portable. On other platforms, the C compiler would take care about optimization, i'm interested in the performance only on intel platform. Still, i could find that assembly-converted-to-C engine is faster than the original, maybe even on intel platform... but this would be a great result by itself.

There are already tools to disassemble and convert to C.

[sje]

The most important lesson one learns from writing a chess program in assembly language is to never write another chess program in assembly language.

[stegemma]

The most important lesson one learns from writing a chess program in assembly language is to never write another chess program in assembly language.

Hehehehe... i've missed this lesson multiple times!

[stegemma]

[...]

There are already tools to disassemble and convert to C.

Yes, but i would like to keep a one to one correspondence between assembly source lines and C lines, so that i can debug both versions comparing the results. This way, even a change in C code could be reflected (automatically or manually) in assembly code and vice versa. It is not a complicated tool, just a little more than a set of replace. Of course i would need some kind of directives to instruct about loops (they are somehow hidden in assembly), i don't want to add too many intelligence in this tool.

[Henk]

The most important lesson one learns from writing a chess program in assembly language is to never write another chess program in assembly language.

Does that also hold for LISP or why did you stop with your chess engine ?

[bob]

The most important lesson one learns from writing a chess program in assembly language is to never write another chess program in assembly language.

Unless their goal is to greatly improve their assembly language programming skills. When I was an undergraduate, my first serious CS classes were a two-course series, the first we wrote a full assembler, the second we wrote a full compiler. I wrote my assembler in IBM /360 assembly language since I had just finished the /360 asm course, and I had already developed an interest in operating system stuff which was all in assembly at the time...

I learned a ton about assembly language programming by doing that, even if it was a pretty painful experience...

[bob]

The most important lesson one learns from writing a chess program in assembly language is to never write another chess program in assembly language.

Does that also hold for LISP or why did you stop with your chess engine ?

LISP = the world's first write-only programming language.

[stegemma]

[...]Unless their goal is to greatly improve their assembly language programming skills.[..]

I learned a ton about assembly language programming by doing that, even if it was a pretty painful experience...

I've found that my base knowledge of assembly help me sometimes, while debugging C++ programs. There are some situation when you know what is happening only viewing the assembly code, in debug mode. In the past, i've found some bug in Visual Basic runtime, that makes my software doing strange things. This maybe are rare situations but they happened to me, in business application developing. Improving assembly knowledge could help you even if you don't write a single line of assembly code, in your life.

[stegemma]

Some day ago i've build a virtual machine with DOS 6.22, just to test if i could see my old Drago working. It works very well, and it has a very high moves and nodes/second. Compared to Satana C++ 64 bit, the 8 bit Drago in assembly looks faster and potentially stronger. I say "potentially" because Drago has a fixed depth, no iterative deepening and some bug in legal move generation. Another problem in running Drago on modern host, via virtualbox, is that the timing of the software was calibrated to old CPUs, so it makes a refresh of the screen any X moves, instead of any X ms. This way, it lose a lot of time just to refresh an hourglass bitmap, without this refresh it could go more faster, maybe even double times faster. Removing bitmap refresh, and adding iterative deepening i think that Drago 8 bit would becomes stronger than Satana and maybe even than Raffaela/Freccia, because the engine will fit almost integrally in the CPU cache. I plan to add Drago engine as an option in Satana, so to keep all the WinBoard stuffs. Next step would be to correct Raffaela/Freccia bug in iterative deepening, that were the same as those in Satana 2.0.8 (not released). Next again would be to collect all the engine in an unique interface to WinBoard, so that one can run different engines just changing a command line parameter (even Freccia, for sample, doesn't have winboard interface). Then, finally, i can try the new assembly engine and compare all of them.