Cpuid

[Mrs Beanbag]

is there an easy and/or reliable way to tell from asm what CPU your program is running on?

[Lonewolf10]

Not sure if it's reliable (I have never used it yet), but I have some code that is supposed to do it. I'll just go and dig it up...


Edit: Found the code. Not sure where I got this from...

***************************************************************************
*                        T E S T   C P U   T Y P E                        *
***************************************************************************
;	INPUT:	None
;
;	OUTPUT:	Result stored in "cpu" variable
;
; Tests the type of CPU installed.
***************************************************************************

test_cpu_type:
	movem.l	d0-d1/a0,-(a7)
	move.l	4.w,a0
	move.b	$129(a0),d0
	move.l	#68040,d1	;68040
	btst	#$03,d0
	bne.b	.exit
	move.l	#68030,d1	;68030
	btst	#$02,d0
	bne.b	.exit
	move.l	#68020,d1	;68020
	btst	#$01,d0
	bne.b	.exit
	move.l	#68010,d1	;68010
	btst	#$00,d0
	bne.b	.exit
	move.l	#68000,d1	;68000
.exit
	move.l	d1,cpu
	movem.l	(a7)+,d0-d1/a0
	rts

cpu:	dc.l	0

[Mrs Beanbag]

ok! i never looked at the Execbase structure as much as i should, what if you have a 68060 though?

[spud]

Test bit 7. (Thanks to Stingray)

[Lonewolf10]

Originally Posted by Mrs Beanbag

ok! i never looked at the Execbase structure as much as i should

Glad I could help you out

Originally Posted by spud

Test bit 7. (Thanks to Stingray)

Any ideas what bits 4,5 and 6 are used for? Just for completeness

[musashi5150]

Originally Posted by spud

Test bit 7. (Thanks to Stingray)

IIRC think that's only valid after a Setpatch on my 3.9 system? So it wouldn't work from a bootblock for example

[hooverphonique]

Originally Posted by Lonewolf10

Any ideas what bits 4,5 and 6 are used for? Just for completeness

******* Bit defines for AttnFlags (see above) *******************************

*  Processors and Co-processors:
	BITDEF	AF,68010,0	; also set for 68020
	BITDEF	AF,68020,1	; also set for 68030
	BITDEF	AF,68030,2	; also set for 68040
	BITDEF	AF,68040,3
	BITDEF	AF,68881,4	; also set for 68882
	BITDEF	AF,68882,5
	BITDEF	AF,FPU40,6	; Set if 68040 FPU
;
; The AFB_FPU40 bit is set when a working 68040 FPU
; is in the system.  If this bit is set and both the
; AFB_68881 and AFB_68882 bits are not set, then the 68040
; math emulation code has not been loaded and only 68040
; FPU instructions are available.  This bit is valid *ONLY*
; if the AFB_68040 bit is set.
;
;	BITDEF	AF,RESERVED8,8
;	BITDEF	AF,RESERVED9,9
	BITDEF	AF,PRIVATE,15	; Just what it says

[Mrs Beanbag]

I suppose I really want to know if CPU has certain features or not, rather than the exact model (i.e. does it have 68020 addressing modes), and don't want to rely on OS patches or even OS versions. Maybe something like the following would work?

  moveq #2,D0
  move.w data(PC,D0*2),D0
...
data:
  dc.w 0, 0, $ff

If CPU doesn't support scaled indexing, it won't throw an exception, it will just reference the "wrong" address.

[Leffmann]

In that case you can just stick to checking the AttnFlags in execbase, because the 68020 is supported since Kickstart 1.2, and this flag will be set during early startup.

[Mrs Beanbag]

ah ok, so the 68020 bit is set even for 68030+ as well

[Lonewolf10]

Originally Posted by Mrs Beanbag

ah ok, so the 68020 bit is set even for 68030+ as well

Yes, see hooverphonique's reply to my question.

As I understand it the bit relevant to the cpu is set, aswell as the bits to all the earlier cpu's. So if a 68040 was detected, the flag for the 68040 and the flags for the 68030,68020 and 68010 would all be set.

[Mrs Beanbag]

d'oh, looks like i've not been paying attention in class

[Lonewolf10]

Originally Posted by Mrs Beanbag

d'oh, looks like i've not been paying attention in class

No problem

I just hope the teacher doesn't surprise us with a test...

[Photon]

I could upload my RigInfo source to Coppershade, there's no sure fire way to tell the diff between 040 and 060 easily tho.

[Gunnar]

Originally Posted by Photon

I could upload my RigInfo source to Coppershade, there's no sure fire way to tell the diff between 040 and 060 easily tho.

you can identify whether its a 060 or 040.


pseudo_example:

lea its_a_060,A0
move.l A0,illegalvector

movep
its_a_040



If you want to see whether your CPU support Scaling address mode then
I would just prope it.

moveq #1,D0
lea data,A0
move.b -1(A0,D0*2),D1

-- The value in D1 will tell you whether your CPU supports scaling

data dc,b 0,1


EDIT just noticed someone posted the same before...

[Toni Wilen]

I wouldn't use MOVEP because future "super" 68060 re-implementation may implement it (also UAE for performance reasons implements all instructions in fast CPU modes unless specifically disabled)

EDIT: Of course testing only for MOVEP to check if emulation is missing (=getting exception) instead of crashing is probably good enough reason to test it

For best compatibility I'd use exact same tests that KS ROM and 68040/060 libraries use (because obviously any re-implementation must pass those tests correctly too!). Only use if there is really need for "low level" check.

MOVEC to/from VBR -> 68000 if exception
MOVEC CACR -> 68010 if exception
Set 68020 inst cache bit in CACR, read it back, if still set, at least 68020+
Set 68030 data cache bit in CACR, read it back, if still set, must be 68030
Set 68040/060 inst cache bit in CACR, read it back, if set, at least 68040+
MOVEC from PCR -> 68040 (or older) if exception

[Photon]

Tests that pass current hardware is good enough, and emulators should not be considered when coding for Amiga.

Toni's last line there to diff 060 from 040 does the job though, so why not use it?

Turns out RigInfo.S was already uploaded :P

With the CPU bit being

     ;---cpu----------
	moveq #"6",d0
	move.b $129(a5),d4	;processorinfo
	bmi.s .go060		;"default"
	subq.w #2,d0
	btst #3,d4
	bne.s .cpuok		;040
	subq.w #1,d0
	btst #2,d4
	bne.s .cpuok		;030
	subq.w #1,d0
	btst #1,d4
	bne.s .cpuok		;020
	subq.w #1,d0
	btst #0,d4
	bne.s .cpuok		;010
	subq.w #1,d0		;000
.cpuok: