Well, my very first "discussion" page - what am I to talk about (believe me I did not plan this!).

Here we go.....

Well, first, I really, personally, would like to thank all those of you that have coughed up the 45 notes for PowerFantasm. We knew the world needed a PowerPC hand rolling assembler - the response has been terrific. If only there were more hours in the day - we could get more done!
We always strive to complete orders as quickly as possible, but as I'm sure you'll appreciate, we have a fine balancing act to juggle, what with development, support and order processing.

Ever since we started, people have said to us "I couldn't find your home page", and we always replied "We haven't the resources". Well now we have, and you can expect it to be good.

It allows us to offer a more open public face. We have nothing to hide - if you want proof of this, check out the old Eddie diaries! (and there is lots more where they came from - let me know if you find them helpful).
Everybody likes to talk to like minded people. Whilst we can't make The Programmers Dream as real time as we'd like it, we will publish anything (subject to legal points of law, and our executive editorial rights) you send in - thus you could say we are as real time as a newspaper, which is better than what we had before! We hope you find these pages helpful.

In my ramblings I'll try to cover as wide an area as possible - not just specific Lightsoft products, but obviously you can expect me to be a little biased :-)

Now, please bear in mind, that these are MY personal thoughts, theories and articles - they are NOT Lightsoft's, so if I upset someone - send the mail to me, not Lightsoft Support.

Ok, so what do I intend to have in these pages? Well, I thought we'd have a puzzle for starters. Why? Well, we're not perfect, and don't know the answer to everything. So, the puzzles will be set to hilight a particular programming area - for example sorting, graphics, sound or whatever. Of course nearly all my stuff is speed based - thus in the first puzzle you will find little "no no's" - that is you can't do it the obvious way, because it's too slow.

I admit, the first one is a b*tch, but probably not to a maths grad?
Even if you have no interest in the current puzzle it may well be worth noting it, and any possible answers, simply because programmers can't have big enough "little black books"!

Every week or so, I'll be adding bits to these pages. I always keep a programming diary, which can get fairly detailed, and I'll be pulling bits out of there. Now naturally, since all our stuff is written in assembler, these will ultimately have a 68k or PowerPC bottom line - BUT it's not the language that counts, but the actual "why's and hows" - so they may be of interest even if you program in C, BASIC or PASCAL. I very often program in other languages - BASIC is great for proving algorithms before writing properly!

Of course I'll be showing you Fantasm tricks and work arounds. Fantasm is not perfect - we still have a long way to go. Sometimes we need to do things that, on the face of it, you can't do. For example:
Q: Know how to force data in PowerPC code? No?
A: Change to 68k (PROC_68k directive), then define your data, then go back to PowerPC (PROC_PPC).

The problem I have here is not enough time to write everything I know in one go! (NOTE: Rob will be doing advanced Fantasm stuff in his own pages (as well as advanced general programming techniques) - next month it's macro and directive usage as only he knows how!). Hence about once a week (probably on Sunday afternoon) I'll sit down, and scribble something up for this page, then upload it. I just hope my spelling checker (brain) is working OK, as I can't see Eddie getting one for a while :-)

Well, recently we've had to define R&D more explicitly - everybody used to just muck in on whatever was important - which was great. However, now we maintain Fantasm, PowerFantasm, Eddie and work on Fanta_C, we have had to delegate "bosses". Thus I get to boss everybody about for Fantasm stuff, and Rob gets to play boss on Fanta_C (he's gonna hate me for this, but it's his baby :-)).
It makes sense, because Fanta_C needs LIDE and a back end, and the actual C compiler is just a small part of the overall system.

My ongoing immediate task :-) is the new PM (Project Manager) for LIDE. This is going into Eddie, as it naturally has all the IO we could ever ask for. Eddie can be remote controlled by another app - so a linker could say "I need a window, and I need one like yesterday" - LIDE passes this to Eddie, which does it and returns a reference to the caller - simple. If you are using Eddie at this moment, you may be suprised to learn that it currently does understand a whole range of commands. Oriiginally we used Apple Events - but after months of painstaking work, found out that they were never going to be fast enough. So we came up with another system, that is about a factor of 1000 faster than Apple Events, and still allows LIDE to run as originally designed (and should be OK for Copland as well). Whilst I cannot tell you how we did this (we wrote our own routines), it illustrates a Mac programming point pretty nicely - call it Stu's Golden Mac Rule #1 - "The Mac is just a computer - same as any other (nearly), and just because Inside Mac (IM) says you should do it this way, if it's too slow, do it another!".

I can't stress a little lateral thinking highly enough, specially on the Mac.
I have found people tend to get too "hung up" on IM - we too have been guilty of that. Don't get me wrong - IM is great - all Apple Docs are of the highest standard, but I get this feeling that there are Mac Apps that have been created by pasting together "Example Code". There is an inherent weakness in this approach - example code is necessarily long winded. Whilst it's fine for experimenting with, if you create a whole app with it, you will suffer from two problems - slowness and a lack of understanding on your part.

I have spent hours studying IM Interapplication Communications - the fastest method is to use the Process to Process Communications (PPC) toolbox routines directly. This will be fine (if a complete pain to get working), so long as you don't want things to happen "NOW"!
(Discussion anyone?)

LIDE Comms followed this path:
First version used PPC Toolbox routines - ok for speed, but very unreliable.
Second version used Apple Events (which sit on top of the PPC Toolbox) - reliable (ish) but too slow.
Third version used custom comms routines - very fast, and we control the bugs too :-)

The development of the LIDE comms also illustrates another point - Never, ever be afraid of scrapping it all and starting from scratch again!
We regularly do it. I firmly believe software can only take so many patches and bug fixes. If you can't get it working right after a reasonable period of time - the algorithm is wrong. What's a reasonable period of time? Well it could be few hours for a small routine, to many months for a complete program.

Scrap a complete program? Yup - The version of Eddie that was released was the fourth complete rewrite. The first version of Eddie "tried" patching te (te is the Macs in-built text editor services manager) - this was a nightmare! Half the software was out of our control, so we didn't stand a chance! For complete control over speed, memory and any other major feature of a program, the more of it that is your software, the more control over it you will have.

Ooooh, pretty controversial stuff Stu!
I do realise issues of portability can be waved in my face here, but with my Lightsoft hat on, I'm a Mac programmer, writing for the Mac - couldn't care less about portability really! (I can't believe I just wrote that :-))

The one thing I really, really, really detest, is "Mac" programs ported from the PC using VC++ portability libraries - completely pathetic that's what I call it!
(If you are reading this Keith, nothing personal meant, and also appologies to any other programmer forced to do this - I know the score :-)).
It means the difference between being able to run said app on an LC and a 630 - besides, the interface.... AND it means that on a PowerMac, you end up with the poor PPC emulating a 68k emulating an 8086 - Now I wonder...
Discussion anybody?

Now, onto a lighter theme (Umm, I'm gonna have to sleep on it - I know I should have something light here, but just what.....)

Some light, entertaining reading they said - ok...
Here's an insight into my own personal "style" and preferences for programming. Before we get into it, the paragraphs below detail MY own individual style of programming for reliability and speed.

I would NOT use some of the techniques below if working in a large group - groups need control methods and a structure, which I fully understand having worked on large aerospace software projects - OK?

Here we go then:

How to program for maximum speed and give yourself confidence!

Firstly, I need one of two things - either complete silence or loud music - anything inbetween is unacceptable. I have an old Technics cassette deck plugged into the back of one of the Macs which mixes the music beautifully with the beeps. As the session wears on, I'll forget to turn the tape over, and it'll stay that way until I'm done - if I can't hear the music, I know I'm working really well.

Secondly, I set "targets" for everything. I'll sit down at the keyboard, and will say to myself - "Right, I'm not going anywhere until this routine/black box/piece of code works correctly". This can be real bad news if things don't go well, as it means I drink a lot of coffee/coke and maybe have to stay awake for a long time - my record currently stands at about 43 hours (which was on the "bitmap through the system" in our 3d system).

Thirdly, I dry run everything - every single line of code is single stepped. Even for a real trivial routine like a C string copy - I'll single step it until the whole string is copied.
I spend as much time in Macsbug as I do in Eddie. This I find gives me confidence, in that even in very complicated programs, I know that every single subroutine does it's job (within reason).

Fourthly, in any complicated system I write a "Debug module". This is normally just one source file that can be selectively assembled with an "IFD STU_DEBUG" directive.
In here I can put all sorts of debug data, routines and timing code that I can call from various bits of the project. Again, this is a confidence thing.
The great thing about this, is that a lot of the time, the source for the debug code can be moved to a new project quite easily.

Number 5 :-) - I try to never put more than about 1000 lines of code in any one source file.

Finally..(and a lot of people will not like this, specially project managers :-))
I steer away from private, or local variables like they were the plague!
Why? Well, quite simply (and we're going to get very "light" here), in the days of old, when memory was expensive, local variables made a great deal of sense. They existed only for a fleeting moment, then were gone, and the memory they were using was used for another variable in another routine.

Now, those of you still awake, will have realised, that private, or local variables have to be initialised everytime the routine is run - hence an unproductive delay - the code is running slower than it need to.

But my main argument against them these days is that if you use all global variables, there is a bloody good chance that these variables will always stay in the processor's data cache, and so rather than being accessed at say 70 nanoseconds, will be accessed in 5-10 nS, which, when writing a game is a much better deal!

Unless you have a great deal of control data for your program, I'd be suprised to exceed 8k of control data even on a very big program. Items that you can put into global variables are small fixed constants that are accessed frequently, along with extensions of the register set with names like long_var1, long_var2 etc and temporary string storage named temp_string_1, temp_string_2 and so on.

Now I know that it is much harder to program like this, due to the fact that you may not know if temp_string_1 is in use when you want to use it. This is where your diary/ notes come in - as long as you fully document when, why and how you are using these things, then you should be able to use them to great effect.

IF your program crashes because two parts of your program are using the same global variable at the same time, you can use Macsbug's SS (step spy) command to stop your program the moment your global variable changes, and trace down the problem fairly quickly.
Another method is to use Eddie's global find command (case sensitive - off, search for word - off) to find all occurences of the usage pronto.

It's always worth looking at even time honoured systems sometimes, just to check that they are really necessary. I always look for code that is unproductive - this is usually at the expense of memory, but if you need the speed....

I remember very well, when I was a kid, my mother would ask me to do some task, and I'd say "I can't". This would invariably invoke the retort "Stuart, there is no such word as "can't"!". And then she'd proceed to "forget about it" until I had worked it out for myself.

Sometimes this involved long walks to the library, or having to search out somebody who knew the answer, could inform me, and I could then impress her with my new found knowledge. Of course, what she was teaching was thinking for myself and using research tools to achieve the desired "I can" result.

I hated her for it, but I reckon she was right! (and still is :-))

Good News!
I read in a popular U.K. broadsheet this week (Daily Telegraph - 27th March) that scientists have discovered that alcohol may not necessarily destroy brain cells as previously thought! And not only that, but up to 3 pints a day may actually be good for you - now my fave drink is Guinness with Southern Comfort chasers - they did not say 3 pints of what.... Err, sorry, onto what I should be writing...

Here at Lightsoft Towers they make me work in the attic surrounded by ornamental frogs. Don't ask me why frogs - I don't know - I just like them (along with Guinness when I can get it which isn't very often with our workload!).
At my disposal I have three Apple machines, one of which is an Apple IIe which suprisingly enough has a far better keyboard than any Mac keyboard I've ever seen! Granted, Mac keyboards are about 10e6 times better than any cheap PC keyboard, but why should such an old machine have a better keyboard than a PowerMac?

So, I regularly use both an LCII and a PowerMac. Why do I use "Elsie"? Well, we have to test our software on as many machines and operating systems as possible. Elsie will run systems 6, 7 and 7.5, whereas the PowerMac won't look at anything less than 7.5.2., and of course with Open Transport sometimes working, and sometimes not (depending on the phase of the moon I think...) I very often use Elsie to surf with (and yes, I am using O.T. V1.1 on a PCI machine!).

Now the strange thing is, that from a "Mac Users" point of view, Elsie feels more like a Mac than the PowerMac. Far more "character".....

And, with that strange thought, I'll leave you till the next time.

-EOF- 29th March 1996.