sudoku sequence generator

[NoCforMe]

No, at this point I think you're I/O bound. The time it takes to write the file is probably dominating.

Could be wrong: you could run time trials with the code as-is and with the writing code disabled.

[zedd151]

No, at this point I think you're I/O bound. The time it takes to write the file is probably dominating.

Could be wrong: you could run time trials with the code as-is and with the writing code disabled.

If I ever did incorporate the list into a sudoku solver or tester program the list does not have to be an ascii text file. That was only done to aid in verifying for correctness of the results. In actual practice a listing of binary data or even dwords could be used.  This was basically a coding exercise to see where speed improvements could be made. To that extent, that task has been accomplished.    Until a faster algorithm surfaces. 
Thank you for your improvements.

[daydreamer]

No, at this point I think you're I/O bound. The time it takes to write the file is probably dominating.

Could be wrong: you could run time trials with the code as-is and with the writing code disabled.

Faster alternative is allocate memory buffer and write to mem buffer in the loop instead of write to file and after loop use only one big binary write buffer call
I prefer use
lea esi,numberchars
Mov ebx,362880
Dec ebx
Faster/smaller than
Inc ebx
Cmp ebx,362880

[zedd151]

You're probably right Magnus, you're probably right. 
I'll look at it at a later time ... I'm working on other pressing matters right now ... 

[FORTRANS]

Hi,

   While following this thread, I asked myself "Instead of generating
all numbers and selecting the ones that meet your criteria, why not
just generate the ones you want?".  Well, by trying to code up such
a program, I answered that question.  I got the program working
for the first two digits.  Really ugly code that thus needed a fair bit of
debugging.  So tomorrow I will use the wonders of "copy and paste"
to get the other seven digits.  And then consign it to the bit bucket.

   I should know better by now?

Cheers,

Steve N.

[NoCforMe]

@Fortrans, did you try my bitfield technique for checking for valid Sudoku-ness? Works really well.

[zedd151]

HI STEVE! (All caps=off  )
I'd like to see what you come up with. How's Brett doing? 

I should know better by now?

    The sudoku guru.

[FORTRANS]

Hi,

   @NoCForMe, no, it was a quick (not really) and dirty (oh yes)
program.  I used bytes to hold the flags.  I could have used a bit
field of some sort, but it would probably have taken longer.  I
guess I could have copied your code, but I sort of wrote the
code on the fly.

   @Zed151, okay, I can post the code.  But it is MS-DOS at its
rudest.  And rather ugly.  Might get a squawk from hutch--.

   Brett?

Regards,

Steve N.

[zedd151]

   Brett?

The old sudo.com conversion ...    snippet:

Code: [Select]

The source code:


        @=$100
        bclr.w  #10,sr


;***********************************************************************
; read 81 digits from stdin, anything else is ignored, 0 for unknown
;***********************************************************************


        move.l  #brett,r5
        move.l  #81,r2


Might get a squawk from hutch--

Nah. Its not the main topic, but a sideline. Go for it. Either that, or post it in 16 bit DOS subforum as a new topic...or attach it here as a .zip file.
On second thought, I probably would not be able to make heads nor tails of it. And no way to interface it with anything I would otherwise use it for, if it were 32 bit - leaving me frustrated and in a dilemma.
I'm sure that you are familiar with those issues.

[jj2007]

Code: [Select]

The source code:


        @=$100
        bclr.w  #10,sr


;***********************************************************************
; read 81 digits from stdin, anything else is ignored, 0 for unknown
;***********************************************************************


        move.l  #brett,r5
        move.l  #81,r2


68000 Assembly, memories of 1986...

Code: [Select]

               MOVEM.L A0-A4/D0-D4,-(SP) *PUSH: alle Register ok

               MOVE.L  12(A3),A0            *Varptr(Df$/Pbit$)
               MOVE.L  D2,D0                *.L ok
               DIVU    #6,D0                *ergibt .W! Max. 65000 Zeilen
               MOVE.L  D3,D1
               DIVU    #6,D1
               MOVE.B  (A0,D0.W),D4         *S0$=Mid$(Df$,I%+1,1)
               MOVE.B  (A0,D1.W),(A0,D0.W)  *Mid$(Df$,I%+1,1)=Mid$(Df$,N%+1,1)
               MOVE.B  D4,(A0,D1.W)         *Mid$(Df$,N%+1,1)=S0$

               MOVE.L  A2,A0           *Desc(Bla%)
               ADD.L   D2,A0

               MOVE.L  A2,A1           *Desc(Bla%)
               ADD.L   D3,A1
From an old source of mine, 3000 lines/100kB, comments still in German

[zedd151]

@jj 
That was FORTRANS's code. Fortunately I never had to suffer through 68000. Back then I had zero knowledge of computers, let alone programming. I was a 'late starter'.    or.    Depending on your point of view. 
It wasn't until I was into my 40's when I got my first computer. An eMachines box with the ubiquitous Windows xp. The glory days. 
Don't remember the specs, but as a casual user at that time, had no need for that info.

[FORTRANS]

   Brett?

The old sudo.com conversion ...    snippet:

Code: [Select]

The source code:


        @=$100
        bclr.w  #10,sr


;***********************************************************************
; read 81 digits from stdin, anything else is ignored, 0 for unknown
;***********************************************************************


        move.l  #brett,r5
        move.l  #81,r2


   Oh, okay.  With _japheth's debugger I "fixed" my copy of the program
and got it to assemble.  (And run.)

Might get a squawk from hutch--

Nah. Its not the main topic, but a sideline. Go for it. Either that, or post it in 16 bit DOS subforum as a new topic...or attach it here as a .zip file.
On second thought, I probably would not be able to make heads nor tails of it. And no way to interface it with anything I would otherwise use it for, if it were 32 bit - leaving me frustrated and in a dilemma.
I'm sure that you are familiar with those issues.

   Okay, attached.  Code, DOS executable, and sample output.  I quit at three
digit numbers.  If you look at the code you will get the idea  with just that.
After all no one is going to use it anyway.

   The code is fairly straight forward.  (I think/hope.)  You should have no
problems understanding it.  If you do ... ask a question?  And you should be
able to use whatever looks interesting without too much effort.  After all,
16-bit code is supported with the 32-bit X86 instruction set.  I think only
three DOS functions are used, so translating those should not pose
insurmountable problems.  The only gotcha I see is the 16- bit addressing
of the data.

HTH,

Steve N.

[zedd151]

Hi Steve,
I will surely have a look at that later on today. Thanks. I know that you spent quite a bit of time with it.

MASM Forum Sudoku Thingy

Cute name. 
The code doesn't look so daunting. I'll have a better look later on today, after a couple cups of coffee and after both dogs have been walked. I'll have more time for this then.   

Added later ...
I see what you were doing already, by looking at the output.

... I made the mistake of saying I will post the code on the MASM Forum.

It happens.     You could have retracted that offer, and I nor anyone else would have held that against you. But I am glad that you did, it gave me a different perspective of the problem and a possibly faster solution. 

[NoCforMe]

@jj 
Fortunately I never had to suffer through 68000.

Suffer through 68000? Suffer? My friend, you'd be glad you had to "suffer" that processor; in many ways it beats X86 with one interrupt controller tied behind its back. Like the number of registers available for use: only 4 GP registers on the '86 (EAX, EBX, ECX, EDX), but the 68000 has 8, D0-D7.

I wish I'd had a chance to program for that machine. (I'd still like to try my hand at Z80 programming; one of the most underrated machines ever create by man in my opinion. Not claiming it's superior to X86, tho.)

[zedd151]

Suffer through 68000? Suffer?

C'mon, don't be so dramatic.    Yes the MC68000 was great. I was first introduced to it as the TI92 plus programmable graphing calculator by Texas Instruments had used it. TI also had what they callled TI-BASIC; a quite simple programming language to write small programs/functions for the calculator. I had once looked at some 68000 source code in the SDK for 68000. At that time, it seemed to complex for me to understand. I barely grasped TI-BASIC at that time. (Still had never yet had a computer at that point, much less knew how to write even a simple "Hello World" program)

Okay so 'suffer' may not have been the best choice of words there.     But 68000 assembly to me is like writing 16 code. All foreign to me. (well, mostly foreign except for the registers {16 bit})