English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 12 December 2018, 16:06   #961
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,847
Quote:
Originally Posted by meynaf View Post
Ok then, let's go.
Code:
 move.l #4782,d0
 rts
You won
ross is offline  
Old 12 December 2018, 16:13   #962
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,514
You may also try the following :
Code:
 moveq #1,d6
 moveq #1,d7
 move.w #1000-9-1,d5
 moveq #10,d4
 moveq #2,d0
.loop
 add.l d7,d6
 exg d6,d7
 addq.l #1,d0
 cmp.l #1000000000,d7
 blo.s .loop
 divu.l d4,d6
 divu.l d4,d7
 dbf d5,.loop
 rts
... but it's probably wrong (except the return value)
meynaf is offline  
Old 12 December 2018, 16:51   #963
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,847
Quote:
Originally Posted by meynaf View Post
... but it's probably wrong (except the return value)
on exit d0.l=#1313
ross is offline  
Old 12 December 2018, 17:00   #964
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,514
Quote:
Originally Posted by ross View Post
on exit d0.l=#1313
I checked again, I get $12ae = 4782. Did you paste it without any change ?
meynaf is offline  
Old 12 December 2018, 17:23   #965
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,847
Quote:
Originally Posted by meynaf View Post
I checked again, I get $12ae = 4782. Did you paste it without any change ?
Ah, ok is 020+ code, with cut/paste the divu magically recognized as bare 68k, instead:
Code:
 divul.l d4,d6:d6
 divul.l d4,d7:d7
give the right result.
I've written pure 68k code (but ehi, 40 bytes here!!).

Now I've to understand what you've done (why those constants?).
I'm engaged in something else and I can not think about it, so if in the meantime you can explain a bit..
ross is offline  
Old 12 December 2018, 17:30   #966
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,514
Quote:
Originally Posted by ross View Post
Now I've to understand what you've done (why those constants?).
I'm engaged in something else and I can not think about it, so if in the meantime you can explain a bit..
It's probably wrong method due to rounding errors, but i've simply used decimal fixed-point instead of large arrays to compute the numbers.
meynaf is offline  
Old 12 December 2018, 17:41   #967
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 110
He's using a proper method as long as the numbers fit in 32-bit regs, and then dividing them by 10 so the next one will fit too, in hope that the rounding error won't catch up. Which turns out to be true, and you get the correct result.
a/b is offline  
Old 12 December 2018, 17:47   #968
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,847
Quote:
Originally Posted by meynaf View Post
It's probably wrong method due to rounding errors, but i've simply used decimal fixed-point instead of large arrays to compute the numbers.
Great, now I understand what the 9 mean
Well, you are lucky, It would be interesting to see when the first error occurs (if occurs).
ross is offline  
Old 12 December 2018, 17:56   #969
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,847
Now the pure 68k, usermode, 44 bytes version:

Code:
digits  EQU 1000

fibonacci:
    lea	    -digits(a7),a1
.c  clr.w   (a1)+
    cmpa.l  a1,a7
    bne.b   .c
    lea     -digits/2(a7),a7
    move.w  #$10,-2(a1)
    moveq   #1,d0
_b  move.w  #digits/2-1,d1
    addq.l  #1,d0
    exg     a7,a1
    lea     (a1),a3
    lea     (a7),a2
.a  abcd    -(a2),-(a3)
    dbf     d1,.a
    bcc.b   _b
    rts
This is interesting because can be usable only in usermode or in a protected superstate mode.
On AmigaOS you need to Forbid() before call (IRQs normally working).
Just to exhibit to litwr why a double stack is a great idea
ross is offline  
Old 12 December 2018, 18:28   #970
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,847
'Normal' 68k 46 bytes version:
Code:
digits  EQU 1000

fibonacci:
    link    a0,#-digits
    lea     (sp),a4
.c  clr.w   (a4)+
    cmpa.l  a0,a4
    bne.b   .c
    move.w  #$10,-(a4)
    lea     -digits/2(a0),a1
    moveq   #1,d0
.b  move.w  #digits/2-1,d1
    addq.l  #1,d0
    lea     (a0),a2
    lea     (a1),a3
.a  abcd    -(a2),-(a3)
    dbf     d1,.a
    exg     a0,a1
    bcc.b   .b
    unlk    a1
    rts
ross is offline  
Old 12 December 2018, 18:36   #971
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 110
46 bytes (stack is protected from overwriting):
Code:
	link	a1,#-1000
	move.l	a1,a0
	move.w	#1<<4,-(a1)
.Clear	clr.w	-(a1)
	cmp.l	a7,a1
	bne.b	.Clear
	lea	(1000/2,a1),a1

	moveq	#1,d0
.Loop	addq.l	#1,d0
	exg	a0,a1
	move.l	a0,a2
	move.l	a1,a3
	move.w	#1000/2-1,d1
.Add	abcd	-(a3),-(a2)
	dbf	d1,.Add
	bcc.b	.Loop
	unlk	a1
	rts
a/b is offline  
Old 12 December 2018, 18:36   #972
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 48
Posts: 491
Quote:
Originally Posted by ross View Post
Now the pure 68k, usermode, 44 bytes version:

Code:
digits  EQU 1000

fibonacci:
    lea	    -digits(a7),a1
.c  clr.w   (a1)+
    cmpa.l  a1,a7
    bne.b   .c
    lea     -digits/2(a7),a7
    move.w  #$10,-2(a1)
    moveq   #1,d0
_b  move.w  #digits/2-1,d1
    addq.l  #1,d0
    exg     a7,a1
    lea     (a1),a3
    lea     (a7),a2
.a  abcd    -(a2),-(a3)
    dbf     d1,.a
    bcc.b   _b
    rts
This is interesting because can be usable only in usermode or in a protected superstate mode.
On AmigaOS you need to Forbid() before call (IRQs normally working).
Just to exhibit to litwr why a double stack is a great idea
Nice. Why you need to call forbid prior though?
I like the exg trick

And your exit condition is off (or I am misreading it). When you get the carry on 500 digits, you are on the 1001 decimal, right?
alkis is offline  
Old 12 December 2018, 18:37   #973
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 110
Haha, damn.. just as I was posting. Yeah, pretty much the same thing.
a/b is offline  
Old 12 December 2018, 18:41   #974
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 110
No, the initial value is multiplied by 10 (16 in BCD) so all numbers are also multiplied by 10, and when you hit 1000 digits you get C flag set on final (499th) abcd and leave the loop.

Last edited by a/b; 12 December 2018 at 18:44. Reason: 999->499
a/b is offline  
Old 12 December 2018, 18:43   #975
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 48
Posts: 491
Quote:
Originally Posted by alkis View Post
Nice. Why you need to call forbid prior though?
I like the exg trick

And your exit condition is off (or I am misreading it). When you get the carry on 500 digits, you are on the 1001 decimal, right?
Never mind, I got it. You and a/b start from 10 instead of 1. Brilliant.
alkis is offline  
Old 12 December 2018, 19:13   #976
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,847
Quote:
Originally Posted by alkis View Post
Nice. Why you need to call forbid prior though?
I like the exg trick
Because AmigaOS task scheduler use (a bit) of the USP memory.
So you need to protect with a Forbid().
On fast processors this routine can be executed in a quantum (before the task switch occurs), try it on WinUAE
But technically, and some software do it, the a7 register can be used just like the others.

Quote:
Originally Posted by a/b View Post
Haha, damn.. just as I was posting. Yeah, pretty much the same thing.
ross is offline  
Old 14 December 2018, 18:09   #977
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
I have made a 80386 variant of the code for the pi-spigot, it has 136 bytes length. The version of Don_Adan has 176 bytes. It uses very strange tricks with the stack, however, they showed me that the second stack can be sometime useful for such a strange way of programming. x86 requires interrupt disabling for such cases. The segment registers provide some functionality of a primitive MMU, so they provide a plain advantage for a small program, they allows to have DOS COM-format programs. 68k is incapable for this. Thus 80386 for this case has shown much better code density than 68020, 136 < 176. 68020 code is not a normal code, it requires a lot of skills to write, it requires also OS adjustment for it, but the code for 80386 is a quite ordinary... And with the conversion to decimal ASCII 8086 still shows the better code.

Thanks to our discussion I have added the next text to the article.
Quote:
Perhaps here it is worth noting that Intel has been producing processors since 1971, which put Motorola in the position of a catch-up party, for which the 6800 was the very first processor. Motorola almost caught up with Intel with 68000/20/30/40.

Computers based on 68000 until the mid-80s were much more expensive than those based on Intel 8088, but 68000 could not work with virtual memory and did not have hardware support for working with real numbers, which made it unsuitable for use in the most advanced systems.

It is appropriate to say that Intel still has problems with the mathematical coprocessor - the accuracy of calculations of some functions, for example, the sine of some arguments is very small, sometimes no more than 4 digits. Therefore, modern compilers often calculate such functions without using the services of a coprocessor.
I have also found an evidence that 68020 ISA was too heavy to support and caused the failure of all 68k family. The text at http://www.cpushack.com/CPU/cpu3.html contains the next words

Quote:
Later, Motorola designed a successor called Coldfire (early 1995), in which complex instructions and addressing modes (added to the 68020) were removed and the instruction set was recoded, simplifying it at the expense of compatibility (source only, not binary) with the 680x0 line.

the Tandy TRS-80 Model 16, which used a 68000 CPU and Z-80 for I/O and VM support - the 68000 could not restart an instruction stopped by a memory exception, so it was suspended while the Z-80 loaded the page. Early Apollo workstations used a similar solution with a second 68000 handling paging.
The mighty 68000 needed a help from a tiny Z80!

The site https://www.mercurynews.com/2014/07/...ola-chip-wars/ claims that Moto's couldn't do things in time.

Quote:
“We recognized that the technology found in traditional microprocessors was not really going to be able to provide us with the performance we needed, ” says Bill Keating, Sun’s director of technology marketing. “If we’d waited for Motorola, we would still be waiting.”
IMHO 68k was good processors but the competition was too hard for them. However 68k could kill an interesting Z8000 architecture. So Moto could fight sometime but x86 was too tough for it.

Studying the benchmark data for 68030 and 80386 shows that 80386 was rather a bit faster at the same frequency so I was rather wrong. I was also affected by the huge 68k promotion made by Moto.

EDIT The Wiki's article about 68030 states that "The 68030 also lacks some of the 68020's instructions". I'm am very curious what instructions are those instructions? Sorry I couldn't find the answer by googling.
Attached Files
File Type: zip pi-386-136.zip (1.3 KB, 6 views)

Last edited by litwr; 14 December 2018 at 18:25.
litwr is offline  
Old 14 December 2018, 19:07   #978
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 51
Posts: 1,145
CALLM and RTM instructions are removed. Both perhaps never used on Amiga.
Don_Adan is offline  
Old 14 December 2018, 21:18   #979
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
Quote:
Originally Posted by meynaf View Post
Code:
 movem.l planes,a1-a4
That's only +1 instruction. Count again +1 to load a0, +1 for the dbf loop, and you end up with 7.
9 > 7 and thus x86 has more instructions for the case.
Don't forget that the 68k has a very powerful move instruction
I like MOVEM too but ARM has its more powerful variant and x86 has PUSHA/POPA one byte length. Your code requires to keep 4 long words, it is an equivalent of 6-8 (!) instructions. So even with your example x86 shows better code density. However I agree that 68k has rather good code density for 16-bit coding. BTW thanks for your codes for the BCD addition.

@ross Thanks for your BCD-code, but it is rather too much slow and we need ASCII.
@a/b Thanks.

I am really baffled with a point about making MOVE from SR privileged. It created difficulty with the use of some programs with A1200 and other Amigas with non-68000 CPU for many users and gave absolutely nothing but the theoretical advantage for a few system programmers. Moto did mistakes. Nothing is perfect. I am just studying 68k architecture and I have to say that I want to have several months to spend doing Amiga programming. I have found out recently that Amiga has very good graphic memory layout maybe even the best. And I have still missed sprites, blitter, ...

Last edited by litwr; 14 December 2018 at 21:40.
litwr is offline  
Old 14 December 2018, 21:50   #980
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,281
Quote:
Originally Posted by litwr
I have also found an evidence that 68020 ISA was too heavy to support and caused the failure of all 68k family. The text at http://www.cpushack.com/CPU/cpu3.html contains the next words
The removal of instructions from Coldfire had everything to do with the target market (low power use/embedded hardware) and nothing with what you're claiming here.
Quote:
The mighty 68000 needed a help from a tiny Z80!
What a surprise, a CPU that does not support virtual memory due to lacking an MMU needs some form of MMU (in this case a software one running on a Z80) to achieve it
Quote:
The site https://www.mercurynews.com/2014/07/...ola-chip-wars/ claims that Moto's couldn't do things in time.
You clearly did not read the article very well.

The point being made is not this little snippet you cherry picked (which, by the way, doesn't say what you think it does), but rather that RISC processing might just change the market altogether and that both Motorola and Intel stood to lose out:
"That pushed Motorola to introduce its own RISC chip, the 88000. And Intel, a well-known RISC detractor, surprised many in the industry when it rolled out the 80860 RISC processor in February. Analysts say that by betting on both horses, Motorola and Intel hope to forestall their RISC competitors while using faster conventional products like the 68040 and 486 to prevent further defections."

I could quote several more paragraphs that go on about this subject to show how your interpretation is not correct, but I don't feel comfortable in quoting half an article.

Quote:
Studying the benchmark data for 68030 and 80386 shows that 80386 was rather a bit faster at the same frequency so I was rather wrong. I was also affected by the huge 68k promotion made by Moto.
Ok then, show me this benchmark data.

Quote:
Originally Posted by litwr View Post
I am really baffled with a point about making MOVE from SR priviliged. It created difficulty with the use of some programs with A1200 and other Amigas with non-68000 CPU for many users and gave absolutely nothing but the theoretical advantage for a few system programmers.
Repeating a falsehood many times won't make it true. There were immediate real world advantages. These have been pointed out to you. We've even pointed out how consumer level hardware got affordable and fast virtualization on M68K machines several decades prior to Intel achieving the same*.

It's all the more stunning you keep repeating this nonsense given that Intel themselves have in fact implemented all that stuff you consider useless (in the form of Intel VT, which amongst many other things does indeed limit access to certain parts of the processor status register when active).

*) x86 virtualization prior to Intel implementing all that 'theoretical' stuff no one needed in hardware themselves (i.e. Intel VT) was dead slow and highly complicated to get and keep running. The difference in performance when 2nd gen+ Intel VT is used properly is staggering.

Last edited by roondar; 15 December 2018 at 11:41.
roondar is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Any software to see technical OS details? necronom support.Other 3 02 April 2016 12:05
2-star rarity details? stet HOL suggestions and feedback 0 14 December 2015 05:24
EAB's FTP details... Basquemactee1 project.EAB File Server 2 30 October 2013 22:54
req details for sdl turrican3 request.Other 0 20 April 2008 22:06
Forum Details BippyM request.Other 0 15 May 2006 00:56

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 22:31.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.12878 seconds with 16 queries