Evaluation using unsigned integers question

[Henk]

Even if you only have three bits you can inplement equal, better, much better. So three bits are enough. Why waste bits.

Actually only two are enough for three states. Why waste bits?

Alex

equal, white better, white much better, black better, black much better. I count five states.
But if that is too much only do equal, white better, black better. That is three states.

So matter of how much you want to spend.

[dangi12012]

Please note that there is no such thing as 'unsigned hardware'. The same hardware does signed andunsigned arithmetic alike.

But you cannot implement minimax by only comparing for equality. You have to implement some method for deciding which of two scores is larger. For small score differences this is easy: you can subtract those, and test the sign bit with an AND instruction. (Which then becomes a test for equality.) The problem is that the subtraction of the scores can overflow. In which case the sign bit has the opposit value of what it should be. And the score range you have with 8 bits is so small that you probably will need the whole range. If scores would run up to half of what you can represent only, subtraction would never overflow.

Oh, please excuse my dumbness))) Obviously there's no such thing as unsigned hardware - I just meant that 8-bit registers and 8-bit memory cells in
my emulated CPU/RAM are defined as uint8_t types.

And as for score comparison - I've been already thinking about that, but for now I hope to stay within +-127 bounds for both material and positional score.
Since I don't care about the strength and accuracy and only want my program to exchange pieces reasonably and from the PST perspective - just to give'em an idea of where to go hopefully that would be enough. Well at least when I've been designing the CPU arch that's what was in my mind) Let's see how it goes) Anyway I'm gonna be making progress videos on that project.

I would still develop all functions in C++ with all the comforts of operator overloading etc - and just target a very old 8 bit cpu and manually translate the very elegant assembly that 30 years of compiler optimisations will produce for you
The mapping from code to assembly should be very clear to see and should enable you to translate the asm to your custom asm.

[Harald]

Have you seen this?
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”

[mvanthoor]

I would still develop all functions in C++ with all the comforts of operator overloading etc - and just target a very old 8 bit cpu and manually translate the very elegant assembly that 30 years of compiler optimisations will produce for you
The mapping from code to assembly should be very clear to see and should enable you to translate the asm to your custom asm.

That is cheating. You know, Maksim is evolving backwards. He started out with real chess engines, then went to de-obfusticating NanoChess, and now he wants to write a chess engine in assembly; and not only asm, but imaginary asm for his own imaginary cpu. Next step will probably be to write a chess engine in Brainf*k, running in an interpreter written in this imaginary asm on the imaginary cpu on Arduino. (And the Arduino is probably emulated on a Raspberry Pi at that point.)

Maksim: You said in many of your video's: "I'm just a simple monkey, I don't understand anything." You lied to me

[maksimKorzh]

I would still develop all functions in C++ with all the comforts of operator overloading etc - and just target a very old 8 bit cpu and manually translate the very elegant assembly that 30 years of compiler optimisations will produce for you
The mapping from code to assembly should be very clear to see and should enable you to translate the asm to your custom asm.

That is cheating. You know, Maksim is evolving backwards. He started out with real chess engines, then went to de-obfusticating NanoChess, and now he wants to write a chess engine in assembly; and not only asm, but imaginary asm for his own imaginary cpu. Next step will probably be to write a chess engine in Brainf*k, running in an interpreter written in this imaginary asm on the imaginary cpu on Arduino. (And the Arduino is probably emulated on a Raspberry Pi at that point.)

Maksim: You said in many of your video's: "I'm just a simple monkey, I don't understand anything." You lied to me

AHHHHH!!!!!!! Marcel, you've made my day! Probably you're the only person on this forum who truly understand what an I doing)))))
Btw I was thinking about writing chess in brainfu*k and there was even a thread on this forum in the past, some thought I was trolling, but I was serious.
However that is too impractical so what I'm doing now seems to be the floor already. I just wanted to have a completely independent run-time environment and physical memory limitation and now I have that :

2 registers, program counter, stack pointer, zero flag, 1k of RAM and 41 imaginary instructions)))

Exclusively for you I have a few links)
CMK computer - real hardware demo (test programs + Chrome DIno game):
Print board routine in CMK assembly:

re: You said in many of your video's: "I'm just a simple monkey, I don't understand anything." You lied to me
- No, not at all))) any monkey can write a huge switch case statement to emulate imaginary instructions - no need to be smart for that)

[mvanthoor]

re: You said in many of your video's: "I'm just a simple monkey, I don't understand anything." You lied to me
- No, not at all))) any monkey can write a huge switch case statement to emulate imaginary instructions - no need to be smart for that)

I'll have a look at those video's you posted

Instead of a switch case, make it a function pointer table. Much cleaner. Some pseudo-code:

Code: Select all

op_codes = array [
    ld => ld(),
    add => add(),
    sub => sub(),
    ...
]

main() {
    quit = false;
    while !quit {
        code = read_code();
        key = in_array(code)

        // Excutes the function belonging
        // to the received code
        op_codes[key]();
    }
}

function ld() {
    ...
}

function add() {
    ...
}

...

It takes some more code, but it is much more easy to maintain.

[dangi12012]

re: You said in many of your video's: "I'm just a simple monkey, I don't understand anything." You lied to me
- No, not at all))) any monkey can write a huge switch case statement to emulate imaginary instructions - no need to be smart for that)

I'll have a look at those video's you posted

Instead of a switch case, make it a function pointer table. Much cleaner. Some pseudo-code:

Code: Select all

op_codes = array [
    ld => ld(),
    add => add(),
    sub => sub(),
    ...
]

main() {
    quit = false;
    while !quit {
        code = read_code();
        key = in_array(code)

        // Excutes the function belonging
        // to the received code
        op_codes[key]();
    }
}

function ld() {
    ...
}

function add() {
    ...
}

...

It takes some more code, but it is much more easy to maintain.

Bad idea - most compilers dont do function pointer inlining. You get the cost of a call even with O3 which is very bad. On switch the compiler will just return the body if the argument is inferable.

Ideas ranked from worst to best:
Function pointer array
If else chain
Switch

The best part is: If the switch gets too big the compiler will emit a function pointer array anyways but it will be much more optimized and the compiler choses what to do because it understands what you are trying to do.