A mathematical demo

[meynaf]

Originally Posted by matthey

The 68k god waves his hand and says "You don't need a useless MOVZX instruction. The Intel engineers had not ascended when they mistakenly added MOVZX to the x86 and the Motorola engineers were not exalted when they added MVZ to the ColdFire. Pay no attention to the instruction saved, 2 bytes saved, single register functionality or compiler importance. The Force has spoken."

Are you kidding ?
MVZ would be one of the most useful addition to 68k.
(I feel we're gonna derail to OT if going in this direction though...)

[Thorham]

Originally Posted by meynaf

I said 20kb but in fact it's gonna be 40kb, due the result is 32-bit and not 16.
Filling such a table is easy but takes some amount of time. Or we could accept a large exe where most others are under 1kb

Use a larger exe. Versions for other CPUs would need to have a table as an option, too. Same goes for unrolling loops. It's a benchmark, and it would be nice to have table vs mul vs unrolled vs etc. across different platforms.

Originally Posted by meynaf

And the net benefit can be very small. A table lookup can be 12 (maybe 14, i don't remember exactly) cycles, with big wait states because in unexpanded A1200 we're in chipmem...

That's a good thing, because now we can see the difference between chipmem access and normal memory access on other systems.

Originally Posted by meynaf

Can't help you for variable digits, but for the timer i have the relevant code. Of course you could go for cheap vbl counter ; I do many benchmarks this way - but due to the relative high speed of the A1200, it's perhaps not precise enough.

Makes me think i've recently added this kind of function to my include files.

So here it goes, in case it could be helpful for ya :

Thanks GetSysTime is V36: http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0577.html

It was actually my first choice, but had to settle for DateStamp. Seems fine for this purpose, though.

This code times up to one day (more is easy enough):

;
; get start time
;
    move.l  #startTime,d1
    jsr     _LVODateStamp(a6)
;
; get end time
;
    move.l  #endTime,d1
    jsr     _LVODateStamp(a6)
;
; calculate total time in seconds
;
    lea     startTime,a0
    move.l  ds_Minute(a0),d0
    mulu.l  #60*TICKS_PER_SECOND,d0
    add.l   ds_Tick(a0),d0 ; ticks per day

    lea     endTime,a0
    move.l  ds_Minute(a0),d1
    mulu.l  #60*TICKS_PER_SECOND,d1
    add.l   ds_Tick(a0),d1 ; ticks per day

    sub.l   d1,d0 ; total ticks taken
    bgt     .l2
    neg.l   d0
.l2
    divul.l #TICKS_PER_SECOND,d1:d0 ; seconds
    add.l   d1,d1 ; 1/100 seconds

Edit: This code is wrong

[litwr]

Originally Posted by meynaf

Depends how you use it. With MOVEM.W you get a free extend so my unrolled code works fine.

MOVEM does the sign extension. So if we will try to get 4708 digits or more we will get a disaster. BTW what is wrong with my timer?

[Thorham]

Originally Posted by litwr

BTW what is wrong with my timer?

The resolution may not be sufficient for really fast systems if it's vertical blank based, because the resolution will only be 1/50 seconds. Same problem with the timer code I just posted.

Just checked to OS documentation, and you can still get seconds + microseconds from timer.device. It's just more annoying than on V36+.

[meynaf]

Originally Posted by litwr

MOVEM does the sign extension. So if we will try to get 4708 digits or more we will get a disaster.

Of course but then we can just return to 32-bit. There would be a small speed difference on 68030 because of data cache, but on 68020 it ought to be the same - just using more memory.

[Thorham]

Full program that accepts the number of digits as a command line argument (100 to 10000 digits) and prints the time it took in seconds with a resolution of 1/10000 seconds. Max running time that's timed correctly is around 4.5 days.

Benchmark for a 50 mhz 68030:

100 digits: 0.0523 seconds
1000 digits: 1.5863 seconds
3000 digits: 12.7265 seconds

Edit: Cleanup code bug fix

;
; PI spigot, 68020+ Kickstart 1.2+
;
    incdir  "asminc:"

    include "dos/dosextens.i"
    include "lvo/lvos.i"

execBase equ 4

start
;
; save pointer to command line argument
;
    move.l  a0,a2
;
; add message port for timer device
;
    move.l  execBase,a6

    lea     timerPort,a1
    jsr     _LVOAddPort(a6)
;
; parse argument
;
    clr.l   d0
    clr.l   d1
.loop
    move.b  (a2)+,d0

    sub.l   #"0",d0
    blt     .done

    cmp.l   #9,d0
    bgt     .done

    mulu.l  #10,d1
    add.l   d0,d1

    bra     .loop

.done
    cmp.l   #100,d1
    blt     exit

    cmp.l   #10000,d1
    bgt     exit

    move.l  d1,numDigits
;
; open dos library
;
    lea     dosName,a1
    jsr     _LVOOldOpenLibrary(a6)
    move.l  d0,dosBase
    beq     exit
;
; open timer device
;
    lea     timerName,a0
    move.l  #UNIT_MICROHZ,d0
    lea     timerIoRequest,a2
    move.l  a2,a1
    clr.l   d1
    jsr     _LVOOpenDevice(a6)
    tst.b   d0
    bne     exit
    move.l  IO_DEVICE(a2),timerBase
;
; handle number of digits
;
    move.l  numDigits,d0
    lsr.l   #2,d0
    mulu.w  #14,d0
    move.l  d0,arraySize

    addq.l  #1,d0
    lsl.l   #2,d0
    add.l   numDigits,d0
    addq.l  #2,d0
    move.l  d0,memSize
;
; allocate array and string memory
;
    move.l  memSize,d0
    clr.l   d1
    jsr     _LVOAllocMem(a6)
    move.l  d0,memBlock
    beq     exit
;
; get output handle
;
    move.l  dosBase,a6

    jsr     _LVOOutput(a6)
    move.l  d0,stdOut
;
; setup array and string pointers
;
    move.l  memBlock,d0
    move.l  d0,string
    add.l   numDigits,d0
    addq.l  #2,d0
    move.l  d0,array
;
; get start time
;
    lea     startTime,a2
    bsr     getTime
;
; fill array
;
    move.l  array,a0
    move.l  #2000*10000,d0

    clr.l   (a0)+

    move.l  arraySize,d7
    subq.l  #1,d7
.loopa
    move.l  d0,(a0)+
    dbra    d7,.loopa
;
; spigot loop
;
    lea     decTable,a4
    move.l  string,a5
    move.l  array,a2
    move.l  #10000,d6
    clr.l   d4

    move.l  arraySize,d7
.loopb
    clr.l   d0
    move.l  d7,d1

    lea     4(a2,d1.w*4),a1

    add.l   d1,d1
    subq.l  #1,d1

    bra     .l1

.loopc
    sub.l   d5,d0
    sub.l   d3,d0
    lsr.l   #1,d0
    mulu.w  d6,d3
    move.l  d3,(a1)
.l1
    add.l   -(a1),d0
    move.l  d0,d5

    divul.l d1,d3:d5

    subq.l  #2,d1
    bgt     .loopc

    mulu.w  d6,d3
    move.l  d3,(a1)
;
; write digits to string
;
    divul.l d6,d3:d0
    add.l   d4,d0

    divu.w  #100,d0
    move.w  (a4,d0.w*2),(a5)+
    swap    d0
    move.w  (a4,d0.w*2),(a5)+

    move.l  d3,d4

    sub.w   #14,d7
    bgt     .loopb
;
; print PI digits
;
    move.w  #$0a00,(a5)+ ; line feed and end of string

    move.l  dosBase,a6

    move.l  stdOut,d1
    move.l  string,d2
    move.l  numDigits,d3
    addq.l  #2,d3
    jsr     _LVOWrite(a6)
;
; get end time
;
    lea     endTime,a2
    bsr     getTime
;
; calculate total time in 1/10000 seconds
; this allows a run time of 4.5 days
;
    lea     endTime,a0
    move.l  TV_SECS(a0),d0
    move.l  TV_MICRO(a0),d1

    divul.l #400000,d4:d0
    divu.l  #100,d1
    mulu.l  #10000,d4
    add.l   d1,d4

    lea     startTime,a0
    move.l  TV_SECS(a0),d2
    move.l  TV_MICRO(a0),d3

    divul.l #400000,d5:d2
    divu.l  #100,d3
    mulu.l  #10000,d5
    add.l   d3,d5

    sub.l   d5,d4 ; total number of 1/10000 seconds
    bge     .l2 ; do abs to handle time looping back to
    neg.l   d4 ; zero when max OS time has been reached
.l2
;
; print total time in seconds.1/10000 seconds
;
    lea     timeStringEnd,a0
    lea     decTable,a1

    move.w  #$0a00,-(a0) ; line feed and end of string

    divul.l #100,d2:d4
    move.w  (a1,d2.w*2),-(a0)

    divul.l #100,d2:d4
    move.w  (a1,d2.w*2),-(a0)

    move.b  #".",-(a0) ; decimal point

.loope
    divul.l #10,d2:d4
    add.b   #"0",d2
    move.b  d2,-(a0)

    tst.l   d4
    bne     .loope

; write "\ntime: " to string

    move.l  #"me: ",-(a0)
    move.w  #"ti",-(a0)
    move.b  #10,-(a0)

; print string

    move.l  stdOut,d1
    move.l  a0,d2
    move.l  #timeStringEnd,d3
    sub.l   a0,d3
    subq.l  #1,d3
    jsr     _LVOWrite(a6)
;
; cleanup and exit
;
exit
    move.l  execBase,a6

    lea     timerPort,a1
    jsr     _LVORemPort(a6)

    move.l  dosBase,a1
    tst.l   a1
    beq     .l1
    jsr     _LVOCloseLibrary(a6)
.l1
    move.l  memBlock,a1
    tst.l   a1
    beq     .l2
    move.l  memSize,d0
    jsr     _LVOFreeMem(a6)
.l2
    tst.l   timerBase
    beq     .l3
    lea     timerIoRequest,a1
    jsr     _LVOCloseDevice(a6)
.l3
    rts
;
; getTime
;
; in:
;
; a2 = time val structure
;
getTime
    movem.l d0-a6,-(sp)

    move.l  execBase,a6

    lea     timerIoRequest,a3
    move.w  #TR_GETSYSTIME,IO_COMMAND(a3)
    move.l  #timerPort,MN_REPLYPORT(a3)

    move.l  a3,a1
    jsr     _LVODoIO(a6)

    lea     IOTV_TIME(a3),a3
    move.l  TV_SECS(a3),TV_SECS(a2)
    move.l  TV_MICRO(a3),TV_MICRO(a2)

    movem.l (sp)+,d0-a6
    rts
;
; data
;
    section data,data_p

dosBase
    dc.l    0

timerBase
    dc.l    0

memBlock
    dc.l    0

timerIoRequest
    dcb.b   IOTV_SIZE

timerPort
    dcb.b   MP_SIZE

decTable
    dc.b    "00010203040506070809"
    dc.b    "10111213141516171819"
    dc.b    "20212223242526272829"
    dc.b    "30313233343536373839"
    dc.b    "40414243444546474849"
    dc.b    "50515253545556575859"
    dc.b    "60616263646566676869"
    dc.b    "70717273747576777879"
    dc.b    "80818283848586878889"
    dc.b    "90919293949596979899"

dosName
    dc.b    "dos.library",0

timerName
    dc.b    "timer.device",0
;
; bss
;
    section data2,bss_p

stdOut
    ds.l    1

numDigits
    ds.l    1

arraySize
    ds.l    1

memSize
    ds.l    1

array
    ds.l    1

string
    ds.l    1

timeString
    ds.b    32
timeStringEnd

startTime
    ds.b    TV_SIZE

endTime
    ds.b    TV_SIZE

[matthey]

Originally Posted by meynaf

Are you kidding ?
MVZ would be one of the most useful addition to 68k.

What we think is irrelevant. THE 68k god has spoken.

http://www.apollo-core.com/knowledge.php?b=1&note=1943

[Thorham]

Originally Posted by matthey

What we think is irrelevant. THE 68k god has spoken.

Who the hell cares what that guy thinks?

[meynaf]

Originally Posted by matthey

What we think is irrelevant. THE 68k god has spoken.

http://www.apollo-core.com/knowledge.php?b=1&note=1943

Yeah, he suddenly discovered that his useless extensions need heaps of encoding space so he stole this one (and don't expect the FPU to come in next versions, as there isn't enough logic available anymore for that).
He doesn't care about code density, he doesn't care about programmability, and he even resurrected a bug that was fixed in 68010 (which wasn't needeed at all even for 68000 compatibility).
His cpu can't work without rom patches.
Not my definition of a 68k god.
What he did appears great, but who do we have to compare him with ?

[litwr]

Originally Posted by Thorham

Full program that accepts the number of digits as a command line argument (100 to 10000 digits) and prints the time it took in seconds with a resolution of 1/10000 seconds. Max running time that's timed correctly is around 4.5 days.

Benchmark for a 50 mhz 68030:

100 digits: 0.0523 seconds
1000 digits: 1.5863 seconds
3000 digits: 12.7265 seconds

Thank you for these results. May I ask you for a favor? Please run my program for Amiga-1200 with your hardware. It is interesting to compare.
4.5 days mean more than 500000 digits! However 32-bit values in the array will allow only about 60000 correct digits - it is less than 2 hours.

[Thorham]

Originally Posted by litwr

Thank you for these results. May I ask you for a favor? Please run my program for Amiga-1200 with your hardware. It is interesting to compare.

100 digits: 0.08 seconds
1000 digits: 2.12 seconds
3000 digits: 13.28 seconds

Not a big difference. Probably caused by printing during the spigot loop. My program builds a string, then prints it when the spigot loop is done (included in the timing). Saves a bunch of syscalls, and writing to the console is slow. The multiply and division take up most of the time, so shaving a few instructions off isn't going to make much of a difference.

Originally Posted by litwr

4.5 days mean more than 500000 digits! However 32-bit values in the array will allow only about 60000 correct digits - it is less than 2 hours.

It's a bit much, yes, but it just comes from the way the time is handled. 400000 seconds at a resolution of 1/10000 seconds = 4000000000, which fits nicely in 32 bits.

[litwr]

Thank you very much again. Your results show that the Intel's engineers did their job a bit better than the Moto's. Only ARM could compete with Intel after 80286...
BTW. Old BBC Micro uses 5 bytes (40 bits) for its timer with the resolution of 1/100 sec. So it allows to keep time for more than 300 years! 6502 rules! IMHO Motorola got a kind of bad karma after it helped to destroy MOS Technology.
Excuse me a bit lamer question but I had Amiga-500 only at 1989-90 and mostly for games. Is there a proper way to clear CLI screen? I'm using Ctrl-L, it works but makes irritating ": Unknown command" message.

[Samurai_Crow]

Re:clear console
There is an escape code aliased in shell-startup that can be invoked by the clear command, assuming you're using a shell rather than a CLI prompt.

[Samurai_Crow]

Originally Posted by meynaf

Yeah, he suddenly discovered that his useless extensions need heaps of encoding space so he stole this one (and don't expect the FPU to come in next versions, as there isn't enough logic available anymore for that).
He doesn't care about code density, he doesn't care about programmability, and he even resurrected a bug that was fixed in 68010 (which wasn't needeed at all even for 68000 compatibility).
His cpu can't work without rom patches.
Not my definition of a 68k god.
What he did appears great, but who do we have to compare him with ?

The FPU just needs debugging and testing. Secondly, the same results as as both mvs and mvz are accomplished using another feature unique to the Apollo core so that there is no speed loss using a two instruction sequence.

[matthey]

Originally Posted by meynaf

...
Not my definition of a 68k god.
What he did appears great, but who do we have to compare him with ?

Not all gods are great or even good. Some just want as many unquestioning servants as they can can find.

Originally Posted by litwr

Thank you very much again. Your results show that the Intel's engineers did their job a bit better than the Moto's. Only ARM could compete with Intel after 80286...

The x86 processors were very efficient at handling byte sizes which includes character text. Tiny text using programs have better code density and are usually faster than the 68k. However, the 68k has better code density and is usually faster for small to medium sized programs and has full 32 bit addressing and registers. The advantage swings back to the 68k for most useful programs. The 68020 was superior to the 80286 even if the multiply was a little slower as it was more flexible. The 80386 was a big improvement while Motorola did not do enough improving the 68020 into 68030 and took too long. The 68040 was an improvement but ran too hot to clock up. The 68060 was a solid foundation for a series of advanced 68k processors but late and Motorola killed it preferring to sell RISC hype (which failed) instead. Economies of scale boosted the x86/x86_64 allowing it to destroy the RISC hype even with that ancient archaic architecture.

The old x86 clone character mapped displays were certainly faster but it was bitmapped graphics displays which eventually won out. The Amiga in particular was slow to move to chunky graphics and update their custom chips and memory to be faster. The AmigaOS was not well optimized in those days either. There is a new layers.library for the newest version of AmigaOS which is some 20% faster and I have been able to optimize it for about another 10% for example. There are gfx cards and FPGA custom chips which remove the major gfx bottlenecks. C= didn't want to uncork the Amiga because they were too cheap and instead wanted another C64. The Amiga was in many ways ahead of its time and better than anything else out there but their management was clueless and did practically nothing with it.

Originally Posted by litwr

Excuse me a bit lamer question but I had Amiga-500 only at 1989-90 and mostly for games. Is there a proper way to clear CLI screen? I'm using Ctrl-L, it works but makes irritating ": Unknown command" message.

The S:Shell-Startup on a newer version of the AmigaOS has a cls alias. Typing "cls" will clear the CLI without the ": Unknown command". The Alias line is the following.

Alias cls "echo *Ec"

Oddly, typing "echo *Ec" still gives the ": Unknown command". You should be able to add the cls alias if it is not in the older AmigaOS anyway.

Originally Posted by Samurai_Crow

Secondly, the same results as as both mvs and mvz are accomplished using another feature unique to the Apollo core so that there is no speed loss using a two instruction sequence.

What is the 2 instruction sequence for "MVZ.B D0" then? It looks to me like it would need 3 instructions, 2 registers and 6 byes of code to do the same thing as this 1 instruction, 1 register and 2 bytes of code.

[Samurai_Crow]

Originally Posted by matthey

Not all gods are great or even good. Some just want as many unquestioning servants as they can can find.

What is the 2 instruction sequence for "MVZ.B D0" then? It looks to me like it would need 3 instructions, 2 registers and 6 byes of code to do the same thing as this 1 instruction, 1 register and 2 bytes of code.

Gunnar von Boehn has attitude, that's true.

To answer your question, is that it is a trick question. Zero extension of a register in place was never supported by the Apollo core. I can do it in one opcode and no temporary register. ANDI.L #$FF,D0 still takes 6 bytes though.

[matthey]

Originally Posted by Samurai_Crow

To answer your question, is that it is a trick question. Zero extension of a register in place was never supported by the Apollo core. I can do it in one opcode and no temporary register. ANDI.L #$FF,D0 still takes 6 bytes though.

Good catch. Yes, "AND.L #$FF,Dn" is the best way to handle a single register byte zero extend without MVZ.B but it is still expensive at 6 bytes of code. It is amazing how often "AND.L #$FF,Dn" and "AND.L #$FFFF,Dn" are used in compiled code, even when MOVEQ #0,Dn + MOVE.B/W <ea>,Dn is possible. It might be ok to get away without MVS/MVZ if all the following were true.

1) All 68k cores using this enhanced ISA had code fusion
2) Code fusion was possible 100% of the time
3) Compilers, especially superscalar schedulers, were programmed to handle fusion sequences correctly (Adds complexity to the compiler where MVS/MVZ simplifies compilers, especially with a shared 68k/CF backend which is common)
4) You really don't care about code density or you consider my "OP.L #<data>.W,Dn" addressing mode good enough (it can't handle every case and MVS/MVZ often gives better code density)

IMO, it is a similar fallacy as trying to move most of the complexity out of the processor and into the compiler. That worked out great for RISC processors like PPC didn't it?

[Thorham]

Originally Posted by matthey

ancient archaic architecture

That makes it sound as if you're talking about tech from thousands of years ago

[Samurai_Crow]

Originally Posted by matthey

Good catch. Yes, "AND.L #$FF,Dn" is the best way to handle a single register byte zero extend without MVZ.B but it is still expensive at 6 bytes of code. It is amazing how often "AND.L #$FF,Dn" and "AND.L #$FFFF,Dn" are used in compiled code, even when MOVEQ #0,Dn + MOVE.B/W <ea>,Dn is possible. It might be ok to get away without MVS/MVZ if all the following were true.

1) All 68k cores using this enhanced ISA had code fusion
2) Code fusion was possible 100% of the time
3) Compilers, especially superscalar schedulers, were programmed to handle fusion sequences correctly (Adds complexity to the compiler where MVS/MVZ simplifies compilers, especially with a shared 68k/CF backend which is common)
4) You really don't care about code density or you consider my "OP.L #<data>.W,Dn" addressing mode good enough (it can't handle every case and MVS/MVZ often gives better code density)

IMO, it is a similar fallacy as trying to move most of the complexity out of the processor and into the compiler. That worked out great for RISC processors like PPC didn't it?

There are more fusions available in the gold 2 core. It must be this way because old 90's vintage compilers suck. Lastly, custom lowering psuedo ops to fusions adds very little complexity to a compiler anyway.

[meynaf]

Originally Posted by litwr

Excuse me a bit lamer question but I had Amiga-500 only at 1989-90 and mostly for games. Is there a proper way to clear CLI screen? I'm using Ctrl-L, it works but makes irritating ": Unknown command" message.

Type command echo, followed by Ctrl-L.

Originally Posted by Samurai_Crow

The FPU just needs debugging and testing.

Yea, this is what they say. But it's not easy to debug and test something that's disabled...

Originally Posted by Samurai_Crow

Secondly, the same results as as both mvs and mvz are accomplished using another feature unique to the Apollo core so that there is no speed loss using a two instruction sequence.

"speed" isn't the only issue here. And anyway, this prevents fusing MVZ with another instruction, and can slow things down if ICache is at its limits.
Note : Gunnar has support for MVS fusing only unless i'm mistaken, and the case for MVZ is more common...
No, the real reason is that he needed the encoding space for his 64-bit stuff (which can be made by fusing as well, but this is another story).

Originally Posted by matthey

Not all gods are great or even good. Some just want as many unquestioning servants as they can can find.

Evil god he is, then ? Then his servants must be evil as well ? If so, we must kill the hellspawn bastards !

Originally Posted by matthey

IMO, it is a similar fallacy as trying to move most of the complexity out of the processor and into the compiler. That worked out great for RISC processors like PPC didn't it?

Yeah, as if the compiler wasn't already the most complex part of the puzzle !

Originally Posted by Thorham

That makes it sound as if you're talking about tech from thousands of years ago

8086 traces back to 1977 and was inspired by 8080 which is... well, more ancient.