asm coding compo

[meynaf]

Yes this is another coding competition idea.

The goal is : do the exact same work as ABCD D0,D1 without using ABCD,SBCD,NBCD instructions.
Targeted audience is any 68k asm coders, however it's especially fit for those who consider this kind of instruction as total useless...

Submit code by PM to me. Don't post code here.
I will regularly update results so that you know where you are in comparison to others (but no code shown before the end).
Deadline undecided yet -- will depend on the received submissions.

020+ stuff allowed, including pack/unpk.
Winner is shortest code in number of instructions. Code size and speed are irrelevant, however every longword of data (should there be some) will be counted as one extra instruction.

Note : if you have a proposal for 68k extensions it might be interesting to see if they can be used here and how efficient it becomes. However this is for academic purposes only, there is no compo on this category (would be too difficult to judge).

[a/b]

No register other than d1 (=result) trashed, CC flags set identically?
Self-modifying allowed?

[meynaf]

Originally Posted by a/b

No register other than d1 (=result) trashed, CC flags set identically?

Yes.

Originally Posted by a/b

Self-modifying allowed?

Yeah, why not.

[ross]

I'm in too.
Tomorrow I send something, i've to better check.

[a/b]

OK, I have a decent working version that passes all 40000 test cases. Before I put more time in to try to optimize it further, here are my assumptions:

Input:
- d0.b/d1.b = valid BCD
- ccr: X, Z
Output:
- d1.b = valid BCD result
- ccr: X/C set if carry is present, cleared otherwise

Z cleared if result is nonzero, unchanged otherwise

V/N undefined (=> I do not verify these two)

- other registers and other parts of d1 unchanged
Misc:
- code is not supposed to be called as a subroute (jsr/bsr/...) and rts is not part of it, and is not included in the instruction count.

Are these correct, am I missing something, or am I perhaps overcomplicating it?

[ross]

Originally Posted by a/b

OK, I have a decent working version that passes all 40000 test cases.

Why not 2^16 test cases?

Bye,
ross

[a/b]

d0/d1: $00-$99 (in BCD)
X: 0|1
Z: 0|1
100*100*2*2=40000 combinations

If we're supposed to support invalid BCD as input, then it would be:
256*256*2*2=262144 combinations

[ross]

Originally Posted by a/b

d0/d1: $00-$99 (in BCD)
X: 0|1
Z: 0|1
100*100*2*2=40000 combinations

If we're supposed to support invalid BCD as input, then it would be:
256*256*2*2=262144 combinations

Yes, i mean 2^16 D0, D1 input value (with illegal $A-$F).
And you take to my attention that my algo take into account only 2^17 combination (D0, D1, X/C in and out).
I've totally forgotten Z provision...

Bye!
ross

[ross]

Originally Posted by a/b

Are these correct, am I missing something, or am I perhaps overcomplicating it?

Seems that i've 'overcomplicated' more than you
(i'm working on correcting Z, i've submitted the incomplete version two days ago).

[paraj]

So we don't have to handle invalid BCD inputs? The original post says "do the exact same work as ABCD D0,D1" however the 68k manual could be interpreted as saying that the instruction is only guaranteed to work for valid BCD input and the output is undefined otherwise.

I'd be OK with restricting the input to only valid BCD as getting the other cases right isn't really much fun and restricts the possible implementations.

[ross]

Originally Posted by paraj

So we don't have to handle invalid BCD inputs? The original post says "do the exact same work as ABCD D0,D1" however the 68k manual could be interpreted as saying that the instruction is only guaranteed to work for valid BCD input and the output is undefined otherwise.

I'd be OK with restricting the input to only valid BCD as getting the other cases right isn't really much fun and restricts the possible implementations.

Hi paraj, the same work is the same work
(I did somersaults to consider illegal cases too )

Why resticts the implementations? I think it amplifies them..

[EDIT: but meynaf choice, is the boss here]

[a/b]

Well, when I said 262144, that possibly isn't entirely correct. It's correct only if all the CPU models use the same algorithm. That would have to be verified.

Then there is another thing, if you are using WinUEA to test your code, what do you get?
I briefly checked the sources (gencpu.cpp, line 3339):

		printf ("\tuae_u16 newv_lo = (src & 0xF) + (dst & 0xF) + (GET_XFLG () ? 1 : 0);\n");
		printf ("\tuae_u16 newv_hi = (src & 0xF0) + (dst & 0xF0);\n");
		printf ("\tuae_u16 newv, tmp_newv;\n");
		printf ("\tint cflg;\n");
		printf ("\tnewv = tmp_newv = newv_hi + newv_lo;");
		printf ("\tif (newv_lo > 9) { newv += 6; }\n");
		printf ("\tcflg = (newv & 0x3F0) > 0x90;\n");
		printf ("\tif (cflg) newv += 0x60;\n");
		printf ("\tSET_CFLG (cflg);\n");

It doesn't validate input data. And there is also a 68040 check because apparently it doesn't modify N/V at all.

[ross]

Originally Posted by a/b

Well, when I said 262144, that possibly isn't entirely correct. It's correct only if all the CPU models use the same algorithm. That would have to be verified.

Then there is another thing, if you are using WinUEA to test your code, what do you get?
I briefly checked the sources (gencpu.cpp, line 3339):
<snip>
It doesn't validate input data. And there is also a 68040 check because apparently it doesn't modify N/V at all.

I started assuming that all 68k processors did the same thing.
What do you mean by 'doesn't validate input data'?
You cannot restrict input data, the illegal value give defined, reproducible results so the hardware designer needed to respect the rules in later processors.
ABCD instruction was a pain for every 68k emulator, used very little but with strange behaviour and source of incompatibility.
And for N/V: undefined is undefined. $A-$F is illegal but defined

Bye!
ross

[paraj]

Originally Posted by ross

Hi paraj, the same work is the same work
(I did somersaults to consider illegal cases too )

Why resticts the implementations? I think it amplifies them..

[EDIT: but meynaf choice, is the boss here]

Well it's probably just because I'm not as great a 68k-wizard as y'all (and I've done very little work with BCD before), but I have like 10 variants that work fine for legal inputs, but getting the exact same result as ABCD for all inputs is more tricky

[ross]

Originally Posted by paraj

Well it's probably just because I'm not as great a 68k-wizard as y'all (and I've done very little work with BCD before), but I have like 10 variants that work fine for legal inputs, but getting the exact same result as ABCD for all inputs is more tricky

paraj, you are a great 68k programmer and you know it.
And yes, there is several variants working, but much more with illegal.

Said this, making the illegal value works is fun

Bye!

[Thorham]

Originally Posted by meynaf

do the exact same work as ABCD D0,D1 without using ABCD,SBCD,NBCD instructions

It would be more interesting to do something that yields useful code.

[meynaf]

Originally Posted by a/b

Are these correct, am I missing something, or am I perhaps overcomplicating it?

Seems your assumptions are correct. Asking for "exact" same work was probably a little bit overkill...

I don't regard "correct" handling of invalid values as a target. What's correct anyway, the result is totally bogus in these cases - which are not even detected. A more correct implementation would have been to set V and not alter the output - like DIV does - but heck, it's too late for that.
You may care about these values if you want, however that's just for the fun.

Same story for N,V.
Do all 680x0 behave the same in regard to these two bits and invalid values anyway ? If they don't, problem solved.

Originally Posted by Thorham

It would be more interesting to do something that yields useful code.

Create your own compo then.

For this one, at least next time someone tells me bcd instructions are useless, i'll reply "okay but look at how hard it is to do their job when you don't have them"

[paraj]

Noted. I will try to finish an entry in the coming week then even if I'll be losing again (even without full results of the last compo I'm already badly beaten )

I'm very much looking forward to seeing how ross is achieving perfection because I'm having a really hard time keeping instruction count down when trying to handle all "illegal" cases.

Anyway I like the compo, it's been fun looking at BCD-numbers and exploring - for me - unknown instructions (*BCD,PACK,UNPK).

[ross]

Ok, alone in this crusade versus code illegality

Final version submitted.

Bye,
ross

[ross]

Originally Posted by paraj

I'm very much looking forward to seeing how ross is achieving perfection because I'm having a really hard time keeping instruction count down when trying to handle all "illegal" cases.

Hi paraj, my final code is FULL of code tricks.
Maybe can be better but sure is magic.

Bye!
ross