Number 27

Right, yes, I get the message thank you. Do a StuChat. Ok. This is a somewhat overdue piece if I do say so myself, and I do say so quite often. Indeed not as often as say "Gis a cream doughnut" for example, but often enough to become somewhat monotonous in a grinding kind of way. I know you're thinking, "Oh for gawd's sake, get on with it already". Umm, maybe I should. This I think is a case of waffling whilst thinking. OK, I've found the page in my diary with my notes for this, so settle down at the back there.

OK, here's the format. First some interesting pieces from some recent customer support, then some opinion (and why not :-)).

First up, two questions that neatly fill this piece. It's the kind of question you hate to get (nah, not really): "How do I do "this" with Fantasm". In this case it was mix PPC and 68K. Sufficed to say it is exactly the kind of question you don't want to get, cause you know hard examples are the order of the day, and hard examples are easy to "screw up" :-) Luckily I had just got a nice fresh cup of coffee and was feeling in a general kind of "customer supporty" sort of way. So here we go.

No, before I start, I'd just like to say that Mac programmers really have a hard time of it. Not only do we have to support and write for the fastest chips in desktopdom, but sometimes we have to write for another processor too! Yeah, Mac programmers have to be good.

Mixing it

Ok, so you have a nice PPC project rocking along, but now you need to speak to some 68K code for whatever reason, and this 68K code needs to be your own, so it's not just a case of passing a UPP to some OS function. Why would you need to speak to 68K code; that's not for me to say - it may be because you are about to call a load of 68K OS calls and you'd really rather prevent hundreds of mode switches so you swtich to 68K and call them from there. There's a few ways of doing it; I'll show you one way in order that you can just cut and paste and then hack to your needs. It'll save you a few days work and make Fantasm that much more flexible for you.

The first thing you need to decide is how to talk to your 68K code - how to pass the parameters. There are an inifinte number of ways (well, a good ten anyway) of passing parameters; you could pass them on the stack C or Pascal style, or you could pass a pointer to a parameter block, or...You get the idea. Seeing as this is our code, we'll pass in registers - plonk them in some PPC registers, and hopefully they'll appear in the 68K registers when we get there (they will). We need to return something, so again, we'll put it in d0 and it'll appear in r3 when we return.

We will put the 68K code directly in the PPC code section. This may strike you as somewhat insane, but it is the fastest way of talking to the code, and keeps it in a neat location - you get a reference to it in the TOC with zero effort on your part. You don't need another project, we'll do it from within the PPC project. It is a good idea to create a new user folder in your project window, and keep the 68K source files in there. Because the 68K code is in the PPC code section you can't expect to just write to data as you normally would - with Virtual Memory (VM) on, the PPC code section is write protected! This code will fail when running in the PPC code section IF VM is on (it'll run quite happy with VM off. For now.):

  lea fred(pc),a0
  move.l  d0,(a0) *Crash! 
  rts
fred: ds.l 1

So, you need to think about your data. You can either pass a ptr in to the 68K code from the PPC side, which points to somewhere in the data section OR you can get some memory from the system with a NewPtr or NewHandle call and use that.

The essence of the operation is to perform a mode switch from PPC to 68K. When the 68K code eventually RTS's it'll perform a mode switch back to PPC (note 1). Inside Mac PowerPC System Software doesn't make the syntax of CallUniversalProc very clear in my opinion - this will hopefully make it easier for you.

Performing an arbitary mode switch is done with CallUniversalProc. As I noted, we want to pass parameters in registers; so the code below passes 4 parameters in r5,6,7 and 8 - these will appear in d0-d3 in the 68K code. It also tells mixedmode that the called code will return one 32 bit value, again in a register.

**We're passing 4 parameters which go in r5 to r8 - these appear in 
**registers d0-d3 in the 68k code.
	lwz	r8,(r20)	  *param4
	lwz	r7,12(r20)	*param3
	mr	 r6,r21	    *param2
	li	 r5,0	      *param1
 
	lwz	r3,[t]my_68K_code(rtoc)	*address of 68K code
	lwz	r4,proc_info(rtoc)	     *see below
	lwz	r4,(r4)
	Xcall	CallUniversalProc	*call the 68K code - See IM PPC SSW pg 2-42
**The 68K code must put the 32 bit result in d0 before returning
**and the result appears in r3
	stw	r3,return_value(`bss)	*The return from the 68K code 
	carry on...
 
***************************DATA
**Our ProcInfo for CallUniversalProc
proc_info:    dc.l	0x3D671832		*4 data regs in, 1 long out, 
                                           *IM PPC SSW pg2-17
	dc.b	0		*resvd
	dc.b	0		*Routine is 68K (PPC=1)
	dc.w	0		*Routine flags 4=native + 2=needs init + 1=offset
	align    4

Now, your 68K code needs to be defined as (preferably in a separate file):

**Note the use of proc_ppc and proc_68K directives. 
**NOTE ALSO THAT ALL 68K CODE AND REGISTERS ETC ARE IN UPPER CASE. LOWERCASE WONT 
**WORK AS WE ARE REALLY A PPC PROJECT AND THE PPC ASSEMBLER ONLY UNDERSTANDS 
**UPPER CASE 68K CODE.
 
**Params come in in registers d0-d3 in that order
**GOTTA SAVE A5!!!!!!!
	PROC_PPC	*Use PPC fantasm to register the routine in the toc
MY_68K_CODE:	TOC_ROUTINE
	PROC_68K	*Use 68K fantasm to assemble our 68K code into the PPC code section.
	MOVEM.L	D3-D7/A3-A6,-(SP)	*GOOD PRACTICE TO SAVE THESE REGISTERS
                                       *JUST IN CASE THE EMULATOR IS HAVING A BAD DAY.
 
**Do your 68K thing here - put any return in d0, which will apear in r3
 
	MOVEM.L	(SP)+,D3-D7/A3-A6	*And restore them before returning to native code
	RTS		 *This will switch us back to native immediately
			    *after the CallUniversalProc.
 
*Pad to 4 bytes. VERY IMPORTANT PC IS QUAD
*ALIGNED HERE as following PPC code MUST
*BE quad aligned.
 
	PROC_PPC	*Back to PPC Fantasm
**Because this is in it's own file, we need it to link up, so we define my_68k_code
**as global
	GLOBAL	MY_68K_CODE

And that is how you do it. I know it looks easy, but if you need to do it, this will save you a lot of hair pulling and crashes. Note also, that you can pass your TOC as one of the parameters, and offsets from TOC will work in the 68K code, thus giving the 68K code access to your PPC globals. You can do the same for bss. Just remember that different sizes apply (PPC half=68K word etc)

As an addendum to this:

Note also, that when you get into your 68K code, you may be in user mode (you will be if VM is on), and you might want to be in supervisor mode. In this case you can use EnterSuperVisorMode to switch - but be sure to reset back to user mode before switching out of the 68K code.

EnterSuperVisorMode is

	moveq	#8,d0
	dc.w	 0xa08d	*debugutil - enter supervisor mode
 
**old SR is returned in d0 - save it away

To return to user mode:

	move.w	d0,sr	*Where d0 contain the old SR returned by the above call

Note 1: The MixedMode manager does this by putting a line-F opcode on the stack that the RTS returns to.

ResEdit

This one is pasted straight out of my reply to another question...

>How do I view the [68K] code in these resources?

OK, first make sure you are using ResEdit off the Fantasm CD as it has the 68K code viewer installed.

Now, open the file with Resedit - you'll see the code you want to view - in this example I have opened the xxx file, and I can see the code in a resource called YYYY. If we double click the YYYY resource in Resedit it comes out as hex :(

So, open Resedit with itself and open the resource labelled RMAP.

This is a translation list that tells Resedit how to view resources. Make a new RMAP (APPLE K) and in the top field enter CODE and in the editor field enter 1. Close the new RMAP resource. Now get info on this new RMAP resource and change the name to the resource you want to disassemble - in this case YYYY. Now close Resedit. Now open the file again, double click the YYYY resource and hey presto you should be looking at disassembled 68K.

And Chat

BTW, like the background GIF? Very "Springy/Eastery" I thought. Talking of Easter, what's the first thing it makes you think of? Me, I think "Kings".

When I think of Kings I think Scotland, and with any luck, that's where I'll be next week. Although knowing my luck it's more likely to be "Hello Macsbug" rather than "Fancy a wee dram McAdam?". But seriously, a holiday would be nice. There's so much bickering and a lot of name calling going on these days. And what's worse, it seems as if many developers are caught up in it, for example Sun trying to rally people against Microsoft. This is truly a bad thing.

JAVA

Java. Hmm. I can see Java for what it is, and what it isn't is the universal language everybody wants. I'm afraid Java is flawed by design - through it's own sheer innocence if you like. Java as a concept is great. Java as an implementation is not going to happen on the scale most people would wish. You take a universal language and immediately it is useless because it is designed to be universal.

I dread to think of the amount of dollars pumped into Java over the last few years - billions surely. And what happens? You boot up your fave browser (shudder - both the big names seem to have "lost it" as far as browsers go), log onto some Java driven WWW chat site and within 30 secs your Mac is completely frozen. Why? Because a Mac is not a PC, and a PC is not an SGI workstation, and an SGI is not an XYZ box. You can absolutely design a universal language as long as you don't want it to talk to any hardware, then I'm afraid it will die as sure as God made little green apples. In theory it shouldn't die because it is an interpreted language, and interpreters shouldn't crash. Right? Yes, but unfortunately interpreted languages run rather, well, slowly - the phrase "This is a joke right?" springs to mind. So people demand more speed and the "people in charge" say, OK, we'll design a fast "just in time" compiler to compile it to native code. And how do they do that? By slacking on the error checking to keep the speed up. Immediately they loose stability, and doing that with applications coming down a network is suicide. Prove it yourself - load up any Java App that isn't a self contained entity and watch it die (along with your machine). It's a great concept and not a new one - it was ditched in the early eighties, but it was called p-code then and the base language was Pascal - indeed (and ironically) that did actually work because the machines were far simpler, albeit less powerful, so speed was still nothing to shout about.

I'm afraid that the late nineties will go down in history as the dark ages of computing - when billions were wasted on futile efforts to generate a write once run everywhere language. People don't seem to "get it". As long as there's a buck to be made out of proprietry systems (and this is what it's all about folks, no matter what Sun may say in public) it ain't going to happen. As HP have just recently demonstrated much to Sun's chagrin. But lets face it, Sun is just trying to make money by declaring their proprietry language is to be a world wide standard. Call me a cynic, but...

Here's what I'd like to see. Within the next few years, processors with more than one CPU on a chip will become common-place. Why are we not switching to a purpose designed parallel language? "Like what"? you may ask. Well like ADA for example. This is a truly great language (it's very hard to work with at first, but once you get "into it", it becomes very powerful very quickly). ADA is a very nice, true high level language. If you want to know about it's reliability credentials, it is used by the military the world over. It's also pretty damn speedy. So why all this pooey Java nonsense? Because Sun wants to make money

DVD

And whilst on "my box", another great marketing exercise just "revving up" is all this nonsense (read "complete and utter bollocks") about Digital Versatile Disk. "You get to watch movies on your computer!" Oh please give me a break. Look we all know the hoohaa in '96 over writing in multiple depths on a CD - a couple of companies lost out, and a few won. Great, so I get 7 Gig's on a CD. Is that it? Millions of computing years after 640 megs became available, we get 7 Gigs? The truth is that the better system (which would've given double that amount) lost out for one reason or another - mainly politics and/or corruption I'd hazard a guess at. It's inferior technology folks, but it's about to be foisted on us as the latest and greatest. It is not.

I got some mail today asking what I think about Apple's change in developer prices (i.e. charging more for less). My thoughts are that Apple is a business with shareholders that needs to make money. They have switched from being "Apple" to being "Apple making money". Most people actually prefer it this way.