Anyone up for an ASM coding competition?

[Leffmann]

Originally Posted by meynaf

There is absolutely no need to test the CCR bits individually and this code runs on all machines. Just use the BLS/BHI branch condition (or SHS/SHI to set a register if you prefer).

Yeah I see now, you're instead testing if 2/3 of B is lower or equal to A. I don't think there's any way to make it shorter than that.

Let me see if I can come up with another one, and this time I'll be more clear about the requirements.

[meynaf]

Originally Posted by Leffmann

Let me see if I can come up with another one, and this time I'll be more clear about the requirements.

And don't forget to specify if results should be given by PM

[Leffmann]

Ok I got another one. The first one ended a bit too fast, but I don't think anyone could beat Meynaf's 5-line solution anyway. My own solution was 8 lines and I couldn't have made it a single line shorter.

For the next one, in honor of the original Amiga, you will print 1000-bit integers:

Write a subroutine that takes a pointer A0 to a 1000-bit integer, and a pointer A1 to where you will print the integer.

The input at A0 is a big-endian two's complement signed integer, so no different from a regular 4-byte/32-bit integer, other than being 125 bytes/1000 bits long in memory. The integer can take all possible values, and is aligned on an even address in memory. You're not allowed to modify the input.

The integer must be written to an output string pointed to by A1, and it must be pretty-printed as plain null-terminated ASCII with a minus-sign if negative, but no leading zeroes, no spaces, and no plus-sign. It must also be adjusted in memory so the first character is where A1 points to. The string has 400 bytes of space (you will need ~300 at most), but may not be aligned in memory.

This is acceptable output:

123

0

-456

This is not:

000

0123

-   0

+2300

         55

You have 1024 bytes of stack space for temporary use. The code must be plain M68000 user-mode code and run on all machines, so forward-compatible and no SMC. You don't have to save the contents of any registers.

You're allowed to use look-up tables, but they will count towards the final size of your code. Shortest subroutine wins.

Originally Posted by roomeo

@Leffman
We should set a deadline, and pm the answers to a dedicated person.
Great little exercise btw...

Originally Posted by alpine9000

I like the idea of PMing answers.

Originally Posted by meynaf

And don't forget to specify if results should be given by PM

Let's do it this way: when you're done, go to pastebin.com and select 10 days expiration, unlisted exposure, and save the link. Let's put the deadline at Sunday 22.00 UTC.

Also, today is Friday the 13th, so be careful when coding.................

[meynaf]

Can the original 1000-bit data be modified in the process or is it read only ?

[Thorham]

Why 68000 only? 68000 limitations suck.

[Leffmann]

Originally Posted by meynaf

Can the original 1000-bit data be modified in the process or is it read only ?

It's read-only. Let's use the more sensible computing model where the program can't just grab and trash whatever memory it wants.

I've updated my post with more details.

Originally Posted by Thorham

Why 68000 only? 68000 limitations suck.

Yeah I guess, but I think more people can participate this way.

[meynaf]

Originally Posted by Leffmann

Yeah I guess, but I think more people can participate this way.

Just my 2 cents here, but skilled coders probably know 020+ and this challenge appears a little bit tough for beginners.

[Leffmann]

Originally Posted by meynaf

Just my 2 cents here, but skilled coders probably know 020+ and this challenge appears a little bit tough for beginners.

Ok, but let's wait and see if someone still wants to tackle it. I have a couple of simpler and more fun problems I can post in the meantime if people are still interested.

[alpine9000]

I'd love to have a go at it, but the deadline is too short for me.

I would only be able to something basic in that timeframe using the small subset of the processor I am currently comfortable with.

I like the idea of this comp as a way to force myself to further research the instruction set and more advanced ways of doing things.

I have almost finished my first game and I have probably only used 15 different instructions

[meynaf]

Perhaps every coder could post his own challenge ?

[alpine9000]

I'd really liked the original idea that Dan had for doing stuff that can end up in your utils.s

I would love to have an integer to ascii routine of the quality I expect you guys will produce for example

[meynaf]

Originally Posted by alpine9000

I would love to have an integer to ascii routine of the quality I expect you guys will produce for example

I have such a routine in my own utility include, but it's for 32-bit integers (i can give it to you if you want).
The 1000-bit integer stuff we have here is another kind of beast.

[alpine9000]

Originally Posted by meynaf

I have such a routine in my own utility include, but it's for 32-bit integers (i can give it to you if you want).
The 1000-bit integer stuff we have here is another kind of beast.

32 bit version would be much appreciated. I don't anticipate needing 1000bit integers in the foreseeable future

[meynaf]

Here is my current routine.
It takes the int in D0 and returns A0=string (in a static buffer).
For unsigned int ; if signed, test and append "-" then neg, if it was negative.
Requires 68020+.

 movem.l d0-d2,-(a7)
 lea staticbuff+10,a0
 moveq #10,d2
.loop
 moveq #0,d1
 divu.l d2,d1:d0
 addi.b #"0",d1
 move.b d1,-(a0)
 tst.l d0
 bne.s .loop
 movem.l (a7)+,d0-d2
 rts

[alpine9000]

Thanks - I will convert it to 16bit 68000 and will be perfect for what I need.

[Leffmann]

I sense there's some irritation and lack of interest in the 1000-bit problem, so let's forget I posted it.

The idea was that people would use long division, like we used to do with pen and paper, where longer numbers is just a matter of repeating the division step more times. So if you've already printed an integer to ASCII then you're almost there, you just have to apply it in a loop and consider the whole length of the number.

Maybe someone else can post a better challenge?

[alpine9000]

Originally Posted by Leffmann

I sense there's some irritation and lack of interest in the 1000-bit problem, so let's forget I posted it.

The idea was that people would use long division, like we used to do with pen and paper, where longer numbers is just a matter of repeating the division step more times. So if you've already printed an integer to ASCII then you're almost there, you just have to apply it in a loop and consider the whole length of the number.

Maybe someone else can post a better challenge?

I'd still be interested in seeing your 1000bit solution if you already have it.

[meynaf]

Dunno if it can be considered as better (perhaps it's even a lot worse ), but i might have one.

It's quite simple : reverse the bit order of a 16-bit int.
This can easily be done with a table, so i put in a limitation : not more than 80 bytes, including data.
The winner is the fastest routine (020/030 timing). All 020+ instructions are allowed. All regs can be used.

Results can be published here. I won't personnally participate (but i can give my routine at the end if asked).
At second thoughts, the challenge may be interesting even if someone rushes in with a good routine : someone else can then find an optimization in that routine and win the game

And trust me : this cannot be done with just a 5 liner

[alkis]

An algorithm with no division
http://www.eng.utah.edu/~nmcdonal/Tu...onversion.html

Technically is binary2bcd, but you can go bcd2string pretty easy.

[meynaf]

Originally Posted by alkis

An algorithm with no division
http://www.eng.utah.edu/~nmcdonal/Tu...onversion.html

Technically is binary2bcd, but you can go bcd2string pretty easy.

Unfortunately it doesn't work this well for large numbers (>8 bits), does it ?