Intro...

This is my working diary, put on these pages in the vain hope that somebody, somewhere will learn something from my mistakes. These are my actual notes from "today", and I don't spell check or even read them - they just get entered as I go along, so please ignore any gramatics or sp's I make.

**30 Jan 98
Just a little note. About two days after I wrote StuChat #25 I found on one of the Mac news sites 
(MacOSRumours I think) that Apple is indeed planning a QTML chip and/or TriMedia chip sometime
this year. Weird huh? You read it here first folks. And another weird one. Look back to 6 May 96
and you'll find I was predicting emotion simulation was the way forward in AI; it's everywhere
now. Sheesh.

And what's happening? Well, Anvil 2 is up to a14 and has the little pop up labels thingy which pops 
up a menu with a list of sorted labels in the file which you can jump to and is
tres handy. Build is up to V4 and is mighty fast with it's new caching algorithms.

Rumour has it that a big announcement is due Monday regards Apple - possibly some kind of Oracle tie 
up or a merger or even a straight takeover? 

Back to work.

**3 Jan 1998.
Happy New Year. I got an email from my daughter this morning that read "Dad, if 
I'm not up by 10 O'Clock, please PUSH ME OUT OF BED!". So I just have, she's not happy :-)


**11 Dec 1997.
:-)
That was to be my diary entry today.
I have all but finished the conversion of Anvil. I'm writing this with it. 100% native code is cool isn't
it - well it would be if we didn't have to call the OS. Man, is there some 68K code in there or what?!
Microseconds is 68K? Jeeze! Even better, the code section is write protected so it should be even more
stable than the current version. Gonna switch to the TBR in the native version methinks.

Anyway, I fully expected this version to build slower than the 68K version simply because of all the mode 
switching going on between the native CCP and the OS. Nope :-).It rebuilds about 25% faster.
God knows how fast it will be with all the tools fully native.
I've also finished LXT - haven't had a bug for two days and with the whole of Anvil being compiled by
it I figure it must be working. Added two exensions - qmove does a move but sets no flags and qmoveq
does a moveq and sets no flags - generally these either come out at one or two PPC instructions
which has really speeded things up. There really isn't much point in adding extensions, most of the 
code generators are pretty sensible now. For example hyperlinking between files is some three times 
the speed of the old version. I really thought I'd have to drop in to PPC assembler in places to get the 
speed up, but this does not appear to be the case.

Getting the a5 register set up for a 68K tool was, well, fun. I KNOW there is an OS call called 
SetEmulatorRegister. God knows I've crashed into it enough times :-) Could I get any info on it?
Nope. Solved it anyway - called an in-line 68K patch that get's passed the tools a5
from Anvil which then calls the tool after loading a5 - looks like:
**0. argc = always zero
**1. argv
**2. Tool a5
**3. Tool run address
**All in registers d0 to d3 in that order
	PROC_PPC	*PPC assembler
TOOL_IN_PATCH:	TOC_ROUTINE
	PROC_68K	*68K assembler
	MOVEM.L	D3-D7/A3-A6,-(SP)	*d0-d2/a0-a2 are volatile. I really don't think we need to save these...
	MOVE.L	D2,A5	*SET TOOL A5 - What I really, really want.
	MOVE.L	D1,-(SP)	*C calling
	MOVE.L	D0,-(SP)
	MOVE.L	D3,A0
	JSR	(A0)		*To tool
	ADDQ.L	#8,SP	*Remove params from stack
	MOVEM.L	(SP)+,D3-D7/A3-A6	*Restore
	RTS				*Back through mixed mode
	NOP				*Pad to 4 byte alignment
	PROC_PPC		*Back to PPC assembler
	GLOBAL	TOOL_IN_PATCH

Rob had a great weekend! Saturday - reverses his car into a taxi and has to bung the guy 70 notes
to keep him happy. Sunday, pulls up handbrake and it comes off in his hand!. Monday morning - car
won't start. I was rolling on the floor as he recounted this to me. Seriously, Rob and cars
just don't get on. 

Tonight we were discussing a planned "forget" directive for Fant. A tree node 
in Fantasm 5 has a slot for "item is defined" or undefined (seeing as the code was whipped straight 
out of the C preprocessor which naturally has an undef directive) - this is how the sets work - at 
the end of pass 1 they are all made undefined. 

You could define a macro, but "forget" it if it wasn't needed, or even better "forget" a real code label 
- weird. The discussion wandered onto "What if you forgot a macro in the middle of processing code out of 
it? And then, even better, would people be allowed to forget internal variables? What would happen if 
you forget the internal variable "life"? I would feel totally compelled to trap that one :-)

And there goes another year - that one went very fast. And it's closer to Christmas still. 
"Ding dong merrily on high"; carols up t'church on Sunday with Jess - oh boy!


**5 Dec 1997
Well it's getting a little Xmassy now. Getting a bit excited. Jess has finally, definitely, most
certainly decided she wants Father Christmas to bring her a PlayStation 'cause it has more games
than the N64. Fine. We've been through bikes, Barbie, a faster Mac and Telliethingy's - at least a definite
"I want this for sure" is a step in the right direction! We'll leave it another week though "just in case"
a new fad starts up in school right before the holidays and then a PlayStation would be as much fun as
having to "tidy one's bedroom up".

Patch is fine and bouncing all over the place. I took him out to the garden this morning before the "big cats" 
woke up. It's the first time he's ever been outside and I was expecting some kind of big nervous reaction, 
but no. He was fine, took it all in his stride. Wandered up to the top, did a wee on the rose bed and 
wandered back in meowing for food. Last night when we got him home from the vets he was a little shaken, 
but still managed to wolf a tin of Kit-e-kat before falling asleep for 12 hours.

Big job of the day is converting Anvil's project file window driver to smaller more manageable sized 
chunks.Currrently it is all done in one huge source file of about 9000 lines and now I want it in 
four or five files. I have found the best way is to layout the files like this:
**code
paste code here
**data
paste data here
**Linkage
figure out linkage here

Which seems managable although currently I'm getting zillions of linkage errors.

Rob's now converting the demo to fat via LXT which he got yesterday. We had a discussion about why
I did not use an underscore in the OS call macro identifiers. For example, OSNewHandle should 
according to Rob be OS_NewHandle. I pointed out that if I did that, the conversion of Anvil 
would've taken 15 hours longer because of the extra typing which seemed a good enough reason to me:-) 
We had a huge argument about the Microseconds call. I have religously followed the C calling 
conventions, so OSMicroseconds takes a pointer to 64 bits of storage. In 68K, microseconds returns 
the data in a0 and d0 which the macro has to poke into memory. Rob wanted to know why I had done it 
this way as it was taking an extra instruction. My reasoning was that I was not going to break 
convention for one poxy instruction on one obscure call. After about an 
hour he gave in with the explanation that he was just playing "devil's advocate". Yeah, ok then :-)

One of the things we've been playing with this week is setting up a local ftp server. We used ARA as
the PPP server (surely it has the world's most useless user manual?) and then tried FTP'd and NetPresenz. 
NetPresenz seems to rather slow, and FTP'd, whilst faster hasn't the same facilities (although
both are nicely implemented). The other thing we're currently searching for is a talk client that 
actually works. Peter Lewis's does not work on our machines (crashes badly sometimes) and there 
seems to be a dearth of talk clients?

Looking back over my diary entries, I see that for the 19 Nov I wrote that "I'm sure I've introduced a 
few bugs" during conversion. Well I wasn't wrong there! Every bug I've had for the last two days have 
been precisely that with the exception of the lsl code generator when working with a negative 16 
bit scalar. Currently the editor is working great - one of the test files I use is the POV user 
manual which is over 19000 lines in length. This new Anvil works great as long as the line number 
is less than 16384 - that tells me that one of my little code gens isn't working quite as it should, 
but hey, if there is a problem the old project window driver will show it up pretty sharpish (I hope!). 
I want to get this conversion finished and  working this week, then I can optimize LXT and getting 
it working smoother and faster.

And sure enough :-). cmpi.b	#x,dn was not quite correct. Deep joy.

My word, the old Fantasm mailing list has been busy this month!



**4 dec
"Come on Barby let's go party!". Boy, am I glad that's on the way out of the charts. What a terrible song!
It certainly wasn't Patch's tune this morning :-) Actually, it was a bit sad. There he was bouncing all 
over the place as usual, completely unaware he was going to the vets to get "done". Even in the cat basket
walking up, he was still completely happy, meowing at people, trying to jump at birds and shaking my hand
through the bars of the door. Got into the vets, meow to all the nice people there, then cut and "snip".
He will never forgive me, and I feel terrible. I know it is the best thing but I still feel very guilty
about it.

Work on the next version of Fantasm is going fine. I have a problem in that it is perfectly OK
for a tool to assume Anvil has a 68K CCP entry point, and so within the tool a simple jsr will normally
call the CCP. Of course, we want native tools to know the CCP is native so there is no need for a universal
procedure pointer with a native Anvil and a native tool. Luckily, this was all planned out years ago because
we pass the tool a flag stating whther the CCP is native or 68K. All current tools ignore this with the exception
of the chroma coder which is fat in Fantasm 5.0.
So, I intend to hardwire a 68K mode switch into the CCP entry point. This at first seems impossible as
all PPC data definitions go in the data section - you simply can't put data in the code section. The data
I'm talking about is 68K instructions. What I need to define is a 68K mode switch "in-line" with the 
PPC code in 68K code. How? Easy. Just switch to the 68K assembler (proc_68k directive) and the 68K code 
will be assembled right into the PPC code section exactly where I want it. Nifty huh?

Of course, new native tools take note of the CCP architecture flag and because the CCP callback address
is passed in the message, and Anvil passes a different address, this one with no 68K code so there's
no delay for native tools, whereas 68K tools obviously get the mode change CCP address, all
will be hunky. This way, 68K tools do not need to use a mode switch when accessing the CCP, and neither
do PPC tools, which keeps tool size down, and everything runs as fast as possible.

That's the theory anyway, and that's what I'm currently engaged in. The chroma coder is working beautifully
with the new Anvil, and dare I say, a little faster too. I notice the new Anvil also opens big files much 
faster than version 1, which is good :-) I almost made the mistake of calling all tools through a UPP.
This would of course have been perfectly acceptable, BUT Anvil knows the architecture of the tool
and can save memory by only using a mode switch for 68K tools - PPC tools are called as a normal
function, just a slightly modified Xcall if you like.

I do hope Patch will be alright with all that anaesthetic and stuff. And I hope when we get him back, he
hasn't lost his bounce.


**3 Dec 1997
05:30 - "BEEP BEEP BEEP". Alarm goes ballistic. Uncuddle from Cath, fall out of bed. "Brrr". It's 
cold and very dark. Somewhere a cat's collar bell tinkles as another flea bites the dust. Fumble about
for some shades....Ah, there in the fire. Hmm, still just as dark and cold. OK, try to figure out where
light switch is...Gotcha. Ouch! Big pillow crashes off my head and Cath informs me to either kill the 
photons or I will receive an email from her solicitor RSN. She loves me.

OK, find some form of working atire. "Brain; Come on!" but it ain't having it. Mine relies on caffiene
and won't even think about changing it's conciousness level upwards until at least half a pint as been 
taken care of. Ah, got a dressing gown - that'll do! I work best in dressing gowns - much better than jeans 
and T shirt, no? Anyway, fall down to kitchen. Switch light on. Fluff "meows" loudly at me - I know, 
turn it off else you'll leave right? "Nope. Feed me."

Bathroom. Brrr. Freezing. Should leave heating on overnight. Back to kitchen. Kettle on. Coffee. Ahhhh.
Up the tower then. Thermometer reads 57F. Heating's on now, but it takes a damn long time for the hot 
water to crawl up to this radiator. Hit the big red button on the keyboard. PowerMacs have no sense of 
occasion do they? "BONG" go the speakers set at 100 watts from last night. Better find some darker shades 
methinks. SyQuest with the "everything" backup disk in it squeeks into life. Do they all squeek like this,
sounds like head against aluminium to me. Is it natural? Works fine but sound very scary first thing
in the morning. 

El cheapo PC monitor on my left springs into life instantly. Dead expensive Sony monitor on my right 
takes 3 days to even think about warming up. Makes sense. Music...need music. Ah, Decade will do nicely. 
Tip - bugger mixed mode CD's. Burn the audio tracks onto another, it makes sense. OK, now we're getting 
there. 

Now into the old 1,2,3 routine.
1. Get mail. Go for the CrapWeServe icon. Nisus writer launches. Hmmm. Obviously brain is waking up
but hand-eye coordination not quite there yet. Although the 1,2,3 is very automatic so maybe
I'm giving my brain too much credit at the moment. Try again. 

2. Surf. Go for FreePPP control panel. Mac asks me if I want to alter the disk cache, VM or Ram disk.
Well it was close! Try again.

3. More coffee/Work.
The last thing I remember about last night was giving the Sony the single finger whilst shouting
ecstatically "Ha, up your bum mutha!". Why was this? I have no idea, but it was good.
Ah, right, yes, I had the native Anvil running fine. Yesterday morning I had written a small
project to test all the really fiddly instructions that I knew weren't working right, for example
the btst dx,dx generator. That one is tricky. Having satisfied myself that LXT was now basically working
I then rebuilt the whole of the project and then enabled major subsystems and they all worked. First the
CD controller - worked straight of the bat. OK, open a file, edit it, save it, change it to unix, cut,paste
etc. All fine. Create a new project. Fine. Stone me! This is easy. OK, this'll kill it. Enable the 
speech. Bruce says "Good Evening". Flabbergasted would be the word. Hence the single finger and triumphant
phraseology.

And so to today...Someone has turned the world white.
Fluff enters, licks a paw and asks "Ready to rock"? 
She is one wired cat.




**30 Nov 1997
I'm back in the tower after my banishment to the dungeons. It was alright too! The only downer was 
everytime I'd turn the volume up, I'd get hit by some hard object coming fom Cath's direction, although 
I never actually saw her throw anything? Then the long haul back up all those stairs and I forgot the 
speakers, and as I've been working solid for the last three days I haven't had time to get them back 
up here until now. 
Recording MOD's to CD is well worth it. We took some of the best off the Fant CD and got PlayerPro to 
output them as AIFF files to disk.Then burnt them using Toast. My BIG mistake was saving them with PP's 
surround sound option. It's great at first, but really becomes annoying after a very short while. Like 
working in a large oil drum. "C'est la vie".

On the dev front a fair amount has fallen into place. Had a preview at the demo today - it's really
quite good. It should be out round about Christmas time. The complete project will be available to
registered Fant 5 owners via email and of course it'll be placed on the Fant 5 CD. You have to see some
of this code to believe the cheekiness of it! Rob's a good coder, but he's even managed to suprise moi this 
time! I'm still trying to get a starfield in there, but as Allan has done a real 3d starfield already 
(which does look a lot better than a 2d "frigged" starfield) Rob isn't having it.

Hopefully by the time it's released we'll have an LXT fat version (it's written in 68K beleive it or not!)
although we're not sure whether Fant 5.1 will be ready at that time.

As far as LXT is concerned it has gone very well since my last diary entry. I've solved most of the architectural
problems - the only "fly in the ointment" is that for callbacks the author may need to write some 
native code. Speed wise it's going OK. Anvil has a little speed test it runs on boot up - the lower 
the result, the faster the machine. 
In Anvil 1 the speed rating isn't displayed; in the next release it is. The 68K version of 
Anvil (on my machine) returns a rating of 227 running under Apple's OS8 emulator. The Basic LXT 
version as native code returns 176 which is OK. Turns out what really slows the native LXT code down 
is all the flags it has to set/clear for moves. So I'm defining an LXT extension file which defines 
instructions such as qmove, which is the same as a 68K move but does not set any flags (if 68K it just 
does a normal move). Using this in the speed test code returns 119 which is much better.

Have made a change to Fantasm's memory scheme. In version 5.1 the maximum amount of memory Fantasm
will leave free for Anvil is about 200K, compared to the 10% of available memory Fantasm 5.0 leaves
free whilst assembling. LXT needs a lot of memory (12 Megs to build Anvil for example) compared to 
the normal assembler which thinks 4 megs is a whole universe. So this new scheme prevents things 
getting silly when LXTing or otherwise working on huge files (a typical LXT file of 2000 lines 
works out at between 12 and 14 thousands lines of code Fantasm has to process).

The idea behind LXT was to provide as stable as possible conversion with minimal source code changes.
It seems to work too - whole wodges of Anvil are now running without a hitch - not bad for three or four
weeks work. I expect to get the whole lot running sometime this week which would be nice. My concern is to
get the LXT side working properly, not Anvil. Doing a conversion and writing the converter
at the same time is not fun. If there are stability problems with Anvil I'll probably go back to the original
code and start the conversion again - mebbs a weeks work for Anvil and another week for all the tools.
One of the questions I've asked myself is why did I pick a huge project such as Anvil to write LXT
with - why not pick a much smaller project - say a linker? The answer is simply that it's easy to see
results in Anvil. With hindsight it would have been better to write a test project for LXT, but hey,
it's done now and getting Anvil FAT gives me more confidence than a test project would. Plus Anvil,
being a "host" environment for all the tools poses unique architectural problems that would not
be evident in a simple self contained test app.

Patch is getting a little worried. He knows someing BIG is going to happen. He's right as well;
Thursday morning, 0900, it's "snip snip" time for him. At least he'll be able to go out then, although
whether he'll really feel like it on Thursday night remains to be seen :-)

**23 Nov 1997

***Very Important Note
In LXT, a definite NO NO is passing the address of a 68K routine to another 
routine which will branch to it. Reason: The PPC linker will not recognise the instruction it is 
trying to patch (which is invariably a 68K LEA instruction which translates to a "move" from the 
toc). End Very Important Note.***

It's easily overcome, for example one can pass a selector to the routine which will perform a computed
branch.

LinkPPC 4.90 has been modified to pick up specifically on this error.

The other problem I face is how to deal with jump and branch tables? Currently I do not have
a definitive size for translated instructions and so can give no specific multipliers - have to fix 
that soon.

So, with that sorted out, and another complete rebuild for some dodgy parameter passing, I can 
now get the log window up which is a good milestone. There are bugs, and at this time I'm
not sure whether they are to do with the code generation or the conversion. Either way, at least I'm
making good progress.

Now it's time to go visit the Dragon Farm and bring t'mother-in-law up for a few days.
When I get back, I want Anvil idling within two days - if this is achievable I'll be a 
very happy little chappy!


**20 Nov 1997
Music of the day is...Looks like Hobbits and Spaceships again..hmm.

What was happening? Ah, right building the documentation in the help menu would stop with an illegal
instruction..hmmm. Must be time to code up link and unlk. That was easy. Now there are major chunks of
code being translated roughly correctly, and I have about 16 callbacks to change to upp's. Today is
set to be a most boring day. Went through all the move's and adds/subs making sure that where the dest addressing
mode is An, we don't set any flags which could be embarrassing!
Meanwhile, Fluffy has a friend! About a week ago we rescued a little kitten we called Patch. Of
course, Fluff being, well, rather a rather alooft andsomewhat expert coder would have nothing to do
with this "thing". For a start, it has no ginger fur, which does not bode well!

Anyway, this morning, I found Fluffy sitting Patch down in front of Elsie (Our venerable LCII),
loading up Chipmunk BASIC and going through simple addition. Wonders will never cease!

Anyway, found a bug in movem.x (sp)+,reg list. The values should be popped off the stack in reverse
order! Oh well, it isn't much of a modification to make. Also, interestingly, and I didn't know this,
if you pop a word off the stack in movem, it's sign extended to 32 bits. Learn something new everyday.

We've had a disaster - Rob dropped the PB280 and did in the screen and hard drive. The screen is not
cheap. Oh dear. Rob is very attached to that little box. When asked whether he sleeps with it, he 
didn't even flinch and just answered "yes".

Damn! My parameters for blockmove are wrong - I thought it was count,src,dest and it's really 
src,dest,count. GRRRR. Now I have over two hundred calls to change and the whole project will need
rebuilding - sob. Complacency.

Well, because the last time it was completely rebuilt was over two weeks ago, nearly every
file has lexical errors - can't find this identifier (cause of the case sensitivity etc), and this OS
call needs it's parameter registers swapping about a bit etc. This could take a long time... Still, at
least I now know that every object file has been built by the same revison level of code generator.
And it's getting frighteningly big as well!

**19 Nov 1997
Music for tonight - Bjorn Lynne/Fleshbrain's Hobbits and SpaceShips is still in the drive. Oh well,
that'll do...
Now where were we....
Ah right, when trying to do a sub.w	dn,dn something is modifying r25 which is the 68K a5! Eeek.
OK, that was the sub code generator moving the 16 bit result into the wrong operand - r$ instead
of s$ (r$ had a5 in it from a previous instruction). D'oh!
Running an interpreted assembler on top of a real assembler isn't fast is it! Still soon have 
the whole of Fantasm nativised which should speed it up a bit...

Right, so we get as far as showing the toolbar window - execute ShowWindow...and... Hmm. No window.
Pooh. My fault, I had set the width to zero.
So, good, toolbar window on screen. Next check the CD icons draw - and they do! Major win. Lots
of code being converted there!
Next up it's the old stressometer - pooh, it uses st and sf which I haven't coded yet. Grr. Why not?
I was supposed to have coded them all... Oh well, it's no major stress. We
have a register dedicated to zero for clr (could use clrlwi etc as well) and sf but not one dedicated 
to not true. At the end I'll check if we can grab another register specifically for true.
Done. Man that toolbar appears quick!
Ok, next up it's lets see if Anvil finds it's prefs. Yup, going better than I thought!

Must be time to change the CD - The Void.
HA, just as I do that it's "Headphones off, find the nasty bug time". During Link, I'd get
search.s.o wants to link to fname but it's not defined, followed by a "Bad instruction" error,
which I've never seen from the PPC linker before! Turns out that I was lea'ing to a data definition.
In 68k one just goes 'extern identifier" but in PPC it must be extern_data. Grr - waste of an 
hour that was! OK, wrap the extern in an conditonal for now - I'll mod fant to accept extern_data
as being extern later. And there was me thinking the linker must have a bug when dealing with
big fragments (this frag is 390k) - good old linkppc.

Right, 'phones back on and back to Macsbug...
Ah, time to code up dbra...easy to get this one wrong. The loop is only terminated if,
after decrementing the lower 16 bits of the register, the lower 16 bits are -1 (all set).
We can either go for true emulation which is decrement and test the lower 16 bits only, which needs
a good 5 instructions, or we can dec all 32 bits which is three instructions. I'll put both in
and comment out what's needed. I've never relied on the upper 16 bits of a count register.
BUT that wont work because there may be garbage in the upper 16 bits of the count register - ho hum.

So, a few hours later and I'm still beavering away. The way I'm working is I figure if I watch Anvils
boot process until all the code generators do not produce illegal instructions, then that should be
just about it. That's the theory anyway. At that time all 68K instructions should be converted to
PowerPC code perfectly amd Amvil will run fine. Yeah, right.

I've just been doing some calculations - I figure that for every 68K source line, Fantasm has to work
it's way through anywhere between 50 and 400 lines (nop does not count here) of macro code to figure out how to produce the
PPC code. This means that in an average source file of 2500 lines, it has to chunter through 500,000
lines of code - TWICE! That's a million lines of code it has to run through, just for one file!
Scary!

OK, few hours later yet again (long day huh!). I'm now into the Anvil's tool loader having fixed a 
few typos in the code generators. At this stage I'm not optimizing the PPC code - just happy to get it
working. The message leds seem to be working along with the status bar in general. I'm about 14 hours in
and if I can get the log window converted today I'll be a happy little chappy indeed. I'm sure I've 
introduced some bugs converting from straight 68K to LXT format, but hopefully they'll be trivial and
obvious. I switched back to the 68K project early yesterday to confirm it does indeed work after the basic
conversion and it did, but I did not thrash it. What is really impressing me is I haven't rebooted my 
machine in 14 hours of constant building, editing and debugging (I'm writing this in Anvil as it's building,
which just amazes me). "And there's the next error...."
Anyway, I have in mind a few extensions we can add on to LXT such as pushq which will save a register "quickly"
if it can rather than pushing it onto the stack (gotta watch for rts's and branches etc though :-))
and move without affecting the condition flags cause it is a bind in PPC having to test the result of every 
move. Maybe something like "qmove" which on 68k is just a move but in PPC runs quicker cause we don't
need to generate any possible testing/sizing code(a cmph would be nice, and where's the freaking lba instruction??? 
A lot of moves use the dot form of PPC instruction, but some of the more complex 68k addressing modes 
require specific testing. Besides I don't like using dotted forms unless I really have to.

Problem is now, I cant load any tools until I've converted the CCP (as soon as a tool is loaded, Anvil
says "Hello? Who the hell are you"?) so I'll have to bypass the load process for now. It'll either 
work or it wont when I reenable it (dead cert it won't :-))

Hey, I gotta show you this one from the linker:

" ***ERROR*** New_te.s.o wants to link with 
update_project
Unfortunately, the offset is too
far for a conditional branch,
which is limited to +/-32k bytes."

Is that polite or what? And it got the conditional bit right - bonus.
Well, that was easy to fix, just added the two binary files next to each other in the project's
binary files area and it linked up just dandy.

OK, I can freeze Fantasm - this macro does it..
beq:	macro	*Necessary because a beq.l will come out as a beql most likely...
	beq	\1
	endm
Spot the deliberate mistake - doh!
Replace with:
beq:	macro	*Necessary because a beq.l will come out as a beql most likely...
	macs_last
	beq	\1
	macs_first
	endm
And she's fine again. Of course Fant should've stopped with a macro nest limit reached, but didn't...
Of course this is Fantasm 5.1 which has had many mods so far, so I'll look into that later. 

Ah, now I know it wants a universal procedure pointer for that callback.
Problem is, I just dont do UPP's on a Wednesday. Any other day of the week is fine, but Wednesdays,
no. Oh well, so I didn't get the log window up today. Tomorrow is another day

Sleep tight, and watch the bugs don't bite.



**18 Nov 1997
00:30

Music for tonight - Bjorn Lynne/Fleshbrain's Hobbits and SpaceShips.

I'm following Anvil as it executes looking for bad code gen. Just come to an
illegal instruction - hmm. Ah, it's the first movem we've ever encountered. Not been 
looking forward to movem at all. The addressing mode decode logic returns 666 as the 
addressing mode, which seems fairly appropriate, no?

I've put a limit on movem in that one can only use the rn/rn/rn syntax; rn-rn is out.

So here goes...
Well that was a doddle - here is one half of it (the other is the (sp)+,rn/rn/rn bit
**rn/rn/rn etc,-(sp)
	ifc	"-(sp)","\2"
**Loop round param1 which is like d0/a3/d2 etc
param_len:	len	\1	*Get length of string so we know when we get to the end
					*else mid$ will moan a lot.
char_pos:	set	0	*our index into the string
		repeat
[r$]:		mid$	\1,char_pos,1	*a or d hopefully
[n$]:		mid$	\1,char_pos+1,1	*0-7 hopefully
**Code the 68K register to PPC reg in t$
			code_reg	[r$][n$]	*returns PPC reg in t$ if valid 68K reg, else fail.
**take account of size which is either l or w - if not "l" default to word which will handle byte
**Sized pushes  and pops properly. We DO DEFINITLEY NOT want bytes on teh stack even though we 
**do do it..
			ifc	"\0","l"
				stwu	[t$],-4(sp)
			else
				sthu	[t$],-2(sp)
			endif
char_pos:	set	char_pos+2	*done 68K reg
			ifeq	param_len-char_pos	*Check for end of parameter
				macs_first
				break		*All done
			endif
**next char must be a "/"
[r$]:		mid$	\1,char_pos,1
			ifnc	"/","[r$]"
				fail	"/ expected in movem"
			endif
char_pos:	set	char_pos+1	*Skip past / character
		until_eq	4ever	*Always loop - we get out via a break	
	endif of movem x/x/x,-(sp). *We never get here

That was much easier than I expected it to be - all in 20 minutes including coffee.
Must be getting the hang of writing these macros now. No doubt there's a bug in the 
above code somewhere, but that'll show fairly rapidly once run.

Spoke to Rob tonight and we decided this (LXT) had to be finished by the middle of 
next week to get on with the preprocessor. Oh boy. Well, it's all down hill from 
here - the biggy was the "move" translator, Ick.
Wouldn't be so bad but we have to go to Wales on Sunday to pick up my mother in-law
whose coming up for a few days in sunny (read "The wind is howling") Grantham. This means 
I have to move out of the tower (as mother in-law needs somewhere to sleep) to down stairs, 
which I don't mind. Big fishtank there which always makes coding easy.

Now, back into the code and lets see how far we get now...

Ha - famous last words about movem being easy! I knew it'd throw a bug somewhere 
and it did. I even had to take me headphones off that's how bad it was. Turns out
that if you called a macro from a repeat loop that calls another macro that does
a break, and then the one called from the repeat loop did a break also, I'd
get a "macro not defined error" on the repeat or until directive on pass 2! Pass1 was
fine. Turns out that on pass 2 because of a bit of twisty branching I had inadvertantly
incremented the if depth index (which is the same as the break depth index) twice
instead of once at ENDM time. Fixed now and Anvil LXT's again. Looks like the movem
translator is outputting OK code too. What a bonus.

Wish I could nest repeats. Indeed the code needed to break required we save the repeat
state (for this depth) before calling a macro, so implementing nested repeats wouldn't 
be too much work now as we have the state data. Wonder if I need to increase max macro 
nesting depth up a bit. Currently it's some twenty ish, but it's just an equate in a 
header... How about 1024, or 2048? Each depth requires about 12 bytes currently...hmm.

Right, that's cost me two hours so better get on with it - next is moveq.

The 68K move instruction does a lot. Move.l #x,d0 works out as:
	movei	rx,data which is two instructions.
	cmpwi	rx,0
Because moveq is limited to +/-128 ish we can use a simple li followed by a cmp thus saving
an instruction....

Done. Ploughed through a load of code, all translating correctly. Got a few "you need to
swap these parameters around" errors and an unrecognised addressing mode from sub.l x(an),an
which necessitated a rebuild of five files but apart from that I'm pretty sure I'll have
the status bar on-screen early tomorrow which means a shed load of 68K has been translated
correctly.
Hard to believe that about three and half years ago Fant was written in hex machine code 
cause we had no assembler. Now it's cross translating and making itself better once again.
Now that's magic.

Zzzzz.