29 April 2012, 17:07 | #41 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,595
|
Quote:
TAS seems to work fine if there is no competing DMA active. TAS Dx is perfectly safe, it does not do any memory accesses. |
|
29 April 2012, 17:10 | #42 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,351
|
Quote:
You could try running a test program, something like this: Code:
Loop: tas d0 tas d0 tas d0 tas d0 bra.b Loop There's an old newsgroup posting which mentions some of the possible issues with TAS, see this. |
|
29 April 2012, 22:04 | #43 |
Registered User
Join Date: Jul 2009
Location: Nottingham / UK
Posts: 155
|
Cool topic
|
29 April 2012, 23:13 | #44 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,753
|
Many caveats in HRM can be taken with a grain of salt, and the TAS warning like the other ones can be ignored - if you know where it's appropriate.
TAS, even to memory, is fine. But it has to be executed when no DMA (or memory refresh slots) want to fight its bus ownership. What happens is that the CPU does whatever it wants with the bus, and these other two users of the bus can't set its DMA or memory refresh address or data. This can of course cause havoc including losing data in memory, and DMA writing to the wrong address including executing programs. You could avoid the former if you do your own memory refresh of desired ranges in memory you care about, such as where the running code and data and the hardware vectors are, and avoid the latter by disabling the copper and never executing TAS instructions while blitting or bitplane/sprite/audio DMA is active, but I think this limits its usefulness somewhat... TAS Dn can of course be used anytime, anywhere, since it doesn't hog the bus. |
29 April 2012, 23:47 | #45 |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,032
|
I simply never use it, because i'll know damn well, i'll forget about not using it to access memory and then be scratching my head wondering why the fuck my program doesn't work!!!
|
30 April 2012, 12:22 | #46 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,351
|
Quote:
Code:
suba.l a0,a0 ;Address 0 is in chip memory Loop: tas (a0) tas (a0) tas (a0) tas (a0) bra.b Loop Code:
suba.l a0,a0 ;Address 0 is in chip memory Loop1: moveq #-1,d0 Loop2: tas (a0) dbf d0,Loop2 bra.b Loop1 |
|
30 April 2012, 14:12 | #47 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,753
|
As stated, if you don't perform the tests in a DMA- and memory refresh-controlled environment, memory rows will be lost until you are running random words instead of code.
If you don't take care of those two things AND turn the system off, you will get trashed memory, rogue coppers, and a crash. If system is off and it's running in real fastram, the effects should be limited to rogue coppers, if disk DMA is off and blits have finished. Last edited by Photon; 30 April 2012 at 14:20. |
30 April 2012, 19:08 | #48 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,223
|
There are softcores on the way for the NatAmi and possibly the FPGAArcade Replay board that will not support the instructions that are not legal on the Amiga. The encoding for TAS, CAS and such was kind of added on as an afterthought in the instruction set but the possibilities of adding more useful single-core opcodes to the Apollo N68070 are likely to yield better performance in the long run.
|
30 April 2012, 21:10 | #49 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,927
|
Thanks guys for explaining the TAS problem Could be useful when used with a data register. Shame that CAS/CAS2 always work on memory.
Quote:
|
|
30 April 2012, 21:30 | #50 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
I agree with Thorham on that.
I thought the Natami was supposed to be compatible with classic Amigas? Not supporting all the opcodes that the native Amiga CPUs use surely automatically makes it less than 100% compatible. |
01 May 2012, 01:17 | #51 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,223
|
The goal for the FPGAArcade Replay is compatibility at all costs.
The goal for the NatAmi is a bit different. We want performance at all costs with just enough compatibility to run WHDLoad and all of its slaves. If you look at our homepage you'll see that we want to leave out legacy drawbacks in order to make way for more performance. Besides the legal threshold for the word "compatible" is 90% of software running on it. I think we can meet that threshold easily. |
01 May 2012, 02:24 | #52 |
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
The Natami's Apollo fpga CPU currently supports TAS in hardware without the read-modify-write but it's recommended NOT to use it in case it could be used later for it's intended purpose. The following instructions will likely be trapped:
MOVEP, MOVES, PACK, UNPK They should not be used as they will be slow and the encoding space could be reused at a later time. It would be wise to replace them in any patches. MOVEP is trapped on the 68060 as well. Instructions that will likely not be supported and may have their encoding space reused are: CAS, CAS2, CMP2, CHK2, CALLM, RTM and BKPT CAS and CAS2 are not reliable on the Amiga. CMP2 and CHK2 are trapped on the 68060. CALLM/RTM are only on the 68020 and not really useful. If anyone sees a glaring 68k compatibility problem with this then speak up. The Apollo core should be very forgiving of self-modifying code which will probably be better for 68k compatibility than supporting some rarely used instructions. |
01 May 2012, 23:20 | #53 | |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,753
|
PRE-EDIT: gosh, why do I reply to the message in the inbox. Kept the below text cos I think it voices similar previously expressed opinions in more detail.
Quote:
In the same list of "illegal" instructions are: clr.w certain custom chip registers, yet you wouldn't remove the clr instruction, would you? Betcha a movep to BLTSIZ wouldn't be very healthy either! Backwards compatibility is easy, forwards compatibility is harder. Now possibly made impossible by not supporting an instruction that has been in every 680x0 CPU! Please tell me they are reconsidering. Imagine that, a single sentence in a book becoming law. I think this is how myths become religions. Also: betcha I can make CAS work fine on accelerated Amigas. Trapping for patches is ...*oof* fine I guess... *grumble* *suspicious look* |
|
02 May 2012, 01:21 | #54 | |||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,927
|
Quote:
Quote:
Quote:
Perhaps FPGAArcade is a better choice for classic users, seeing how Natami removes what ever it wants so that it can reuse the encoding space. All those extra instructions aren't any good anyway. Software that would work perfectly fine on 680x0, won't work now. Natami is looking less attractive by the second. |
|||
02 May 2012, 01:53 | #55 | ||
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
Quote:
CAS 19 cycles TAS 17 cycles (in memory) You can do the same faster with replacement code. If it was faster in any case on the Amiga then someone would have used it but it's not and that's why it's gone unused. CAS is useless without a working read-modify-write cycle that's slow on a modern processor. |
||
02 May 2012, 02:45 | #56 | ||||
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
Quote:
Quote:
Quote:
|
||||
02 May 2012, 08:22 | #57 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
I won't say anything about what I do or don't think are the rights and wrongs of Natami compatibility or about who I do or don't agree with in the preceding discussion.
The reason I won't is that I can see that my (our) nice cosy 68000 optimisations thread, that up until now has been very useful, will very quickly descend into an off topic Natami compatibility thread. As it happens I think a thread about Natami CPU compatibility would be very interesting, but please, really do go and make it another thread. |
02 May 2012, 10:33 | #58 |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
may you explain to me these two optimizations?
|
02 May 2012, 11:10 | #59 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,927
|
Quote:
Here's one. It clamps d0 to 255 at an overflow. Use after a vlaue has been added to d0: Code:
subx.b d1,d1 or.b d1,d0 |
|
02 May 2012, 22:07 | #60 | |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,753
|
Quote:
CAS was mentioned. The thing is, compatibility has never been about performance but in the case of Amiga, not have to rely on Amiga programmers who have perhaps moved on (in any sense) to update software to not have it become obsolete. It might have already been used in 4K ztravaganza ztrordinairez, or I might do one just to spite you! (Well, not really feeling like it but there's the size aspect of optimization as well.) There's always been a limit to how many % of software a given ever so compatible Amiga or Amiga successor platform can support, but it's been due to other things than yanking out instructions and more about instruction behavior, caching, speed, and OS code. A compiler can make the programmer forget about the instruction set altogether, but this forum IS basically about the instruction set. And the chipsets. I'm not poking my finger in a potential success story like Natami and trapping and patching is one way (grumble) for compatibility, but as pointed out for real Amiga users to not use instructions demonstrably working on an Amiga is... not really relevant to optimization which is this topic. I think specifics of Natami supports points to its nearing conclusion, which is exciting! - and I'll help move any posts you wish regarding it or other nextgen Amiga clones to the NextGen forum. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
68000 boot code | billt | Coders. General | 15 | 05 May 2012 20:13 |
Wasted Dreams on 68000 | sanjyuubi | support.Games | 5 | 27 May 2011 17:11 |
680x0 to 68000 | Counia | Hardware mods | 1 | 01 March 2011 10:18 |
quitting on 68000? | Hungry Horace | project.WHDLoad | 60 | 19 December 2006 20:17 |
3D code and/or internet code for Blitz Basic 2.1 | EdzUp | Retrogaming General Discussion | 0 | 10 February 2002 11:40 |
|
|