jimomura@lsuc.on.ca (Jim Omura) (11/07/90)
I've received a number of responses regarding my questions and I think I've replied to most of them. This will summarize the information I have received. Regarding AES and VDI calls from a .TTP program: It seems this is possible. Some of you have done it. I'll read my reference material again with this in mind and I think eventually I may try it out on one of the programs I'm working on. Regarding A-Line Calls: The problem is solved! But before I get to the solution, I'll mention some other things that have arisen. 1. Sozobon C and bugs. This wasn't the problem, but it seems that early versions of Sozobon C had problems with some bitwise code on the assembler level. I have not current evidence if my version has such problems. I should state that I'm using a slightly modified version of Sozobon 1.2. The modifications were made to the TOP optimizer by Ian Lepore on BIX. The information I have is that TOP is NOT reliable and should NOT BE USED AT ALL unless you know how to correct it. Ian's version has been submitted to the Sozobon authors and the last I heard, no decision had been made about his corrections. I trust Ian's judgement on this matter and I'm using his corrected version of the TOP optimizer. Although I've found a couple of other bugs since then (one HCC level bug and one Dlib level bug and maybe one or two others), it's been quite usable. 2. I have received a header #include file from J. Henders. When I double checked my version of DLIBS, my documentation doesn't indicate support for the A-Line functions listed in the header file. Either they simply didn't document it or you've got a later version of DLIBS. Be that as it may, looking at the header was helpful, but I decided not to use it. The problem is one of standardization. I'm basing my variables on the information in "Atari ST Internals." Despite the bugs in the book, they claim to be using "official" Atari Corp. variable names. I think there might be some value in developing code using these names as much as possible, so I've decided to keep them. Otherwise, looking at the variable names for inherent value, it's sort of a toss up. Both sets of variable names have some good points and some bad points. 3. THE SOLUTIONS to my A-Line routine problems: The problem seems to have been caused by my using d3, d4 and a3 registers without storing and restoring contents. I'll start at the beginning. The Sozobon documentation regarding register usage says only this: P. 5 "Any of the basic data types may be declared as register variables. Pointers occupy the A registers, all other types are placed in D registers. Five data registers and three address registers are available for use by register variables." P. 6 "The components of the Sozobon compiler were developed by replacing pieces of the Alcyon compiler one by one." " ... The output of the compiler is suitable for input to other compatible assemblers such as Alcyon's assembler or the MadMac assembler." The Sozobon Assembler likewise produces object files that will link under Alcyon and Sozobon's linker will accept Alcyon object files and libraries. As such, Sozobon can be assumed to be using Alcyon register usage practices. That's nice, but I don't have Alcyon documentation, so I had no idea what those standard practices are. :-) P. 7 "The compiler uses the 'normal' 68000 C calling conventions. Register A6 is used as a frame pointer, and function return values are placed in D0. Registers D3-D7 and A3-A5 are used to hold register variables." I'll assume that this is somehow "normal." I haven't really looked closely at a lot of C compilers, but it still left out a lot. At this point I did my usual trick of partially compiling a "model" program to see how variables were being passed and started in writing my functions. And they worked. At least they worked as far as I tested them. I assumed MISTAKENLY that the compiler was storing 'register' variables *before* making the function call and restoring after the return. This is my own convention when I write pure assembly language. As has been pointed out to me long ago, this is not necessarily the way a compiler will do it. So the first possible solution was simply to stack and unstack the registers I used inside the functions I've written. Hugh Redelmeier provided what is probably a better solution. It's the solution I'm using for now. The problem is that it is based on an assumption. But it's a fairly safe assumption. Apparently it is common to use A0, D0 and D1 as scratchpad registers. Looking at the documentation again, it seemed likely that Sozobon assumes A0 to A2 and D0 to D2 all as scratchpad registers. Proper usage of a scratchpad register assumes that these registers can be corrupted in any called function, so a called function should not have to stack them and unstack them. Hugh provided a version of the function that worked. In fact, I decided to *slowly* mutate my function closer to his version so I could try a few things along the way and see the results. I've learned quite a bit. .text .globl _fgrnd _fgrnd: ; fgrnd(spntr,colour) ; LINE_A spntr ; int colour ; Line-A binding function for Sozobon C ; By Jim Omura ; ;var 4 8 _spntr ;var 2 12 _colour ; link a6,#-0 ; movea.l 8(a6),a0 ; A0 = spntr lea 24(a0),a0 ; A0 points at Plane 1 move.w 12(a6),d1 ; D1 = Colour Reg. moveq #3,d2 ; D2 = Loop Counter ; DISTLP: ; Start Loop "Distribute Bits" ; lsr.b #1,d1 ; Shift bytewide right ; NOTE: Last Bit shifted out sets CCR Carry and eXtend Flags ; bcs ODD ; Branch Carry Set ; move.w #0,(a0)+ ; Bit Plane = 0 & Incr. A3 ; bra NEXT ;ODD: move.w #1,(a0)+ ; Bit Plane = 1 & Incr. A3 ; *** Hugh's version: clr.w (a0) lsr.w #1,d1 roxl.w (a0)+ ; Store remainder in Bit Plane & incr. ; NEXT: dbra d2,DISTLP ; End of Loop ; unlk a6 rts .data The above version has been tested and works. I've changed all the functions I've written to conform to the assumptions that the lower number registers are scratchpad and can be used in this way. Unless I find out otherwise, this will be the style I'll be using in the future. One difference from Hugh's version was my NOT using D0. Since D0 is used for return values, I tend to leave it till I need it. This can be helpful when writing long, complex functions. That is to say, sometimes it affects optimizing if you plan your register usage backwards. In this case it's fairly clear that it won't matter, but I've had it strongly ingrained, so I've not used D0. No real reason not to. :-) -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura
davidli@coral.labmed.umn.edu (11/14/90)
In article <1990Nov14.161216.7677@daffy.cs.wisc.edu>, gcarter@globey.cs.wisc.edu (Gregory Carter) writes: > ... I and a few > of my friends are pondering just what good a blitter chip actually is on > the ST, and if it offers any advantages over the software blitters. I can't answer your question directly, but I can point you to the last two issues of STart magazine (October, which has 'September' on the cover, and November 1990). Both have had programming articles related to the blitter chip and demo some of the supposed advantages of the chip. -- David Paschall-Zimbel davidli@simvax.labmed.umn.edu
gcarter@globey.cs.wisc.edu (Gregory Carter) (11/15/90)
Hello! I am getting a MEGA 4...whenever the DAM THING GETS HERE, and I and a few of my friends are pondering just what good a blitter chip actually is on the ST, and if it offers any advantages over the software blitters. Some of the technical stuff I have seen suggests that the blitter is mainly meant to off load cpu time so the 68000 can be doing other things instead of doing blit's. Thats the only advantages I can see over the software blitters, anyone get this impression from line-A SALAD stuff??? --Gregory
sstreep@next.com (Sam Streeper) (11/17/90)
>> ... I and a few >> of my friends are pondering just what good a blitter chip actually is on >> the ST, and if it offers any advantages over the software blitters. > >I can't answer your question directly, but I can point you to the last two >issues of STart magazine (October, which has 'September' on the cover, and >November 1990). Both have had programming articles related to the blitter chip >and demo some of the supposed advantages of the chip. >David Paschall-Zimbel davidli@simvax.labmed.umn.edu I can add a little to this (since I wrote those articles... 8^)) The blitter chip offers a noticable speedup on most graphics operations like text output. The software blitters offer a huge speedup of many operations, but the last time I tried them (admittedly about a year ago) they still had enough little incompatibilities that I would not use them full time. They really made some things (like emacs) super fast and nice to use, though. Curiously, the one operation that the software blitters didn't speed up (in the last versions I saw) was the true blit, the vro_copyfm() function. For things like this, the blitter chip offers better performance than you can get from pure assembly language, something like a sixfold performance increase. For the best of both worlds, you use both software and hardware blitters, and your system absolutely screams. (I'd assume that the latest software blitters fix the little nits that used to bug me) On a side note, I ported BoinkOut, the blitter game in November STart, to the NeXT cube, and it runs about the same speed on a 25MHz 68030 as it runs on a Mega ST with a blitter chip. The comparison is not totally fair, because my cube is running a lot of other tasks (all graphics are done by a separate window server process, so there's a _lot_ of inter- process communication) and the NeXT runs a 256Kbyte screen and uses floating point instead of integers... Technology buys you a lot, but it doesn't always buy you speed. cheers, -sam (sam_s@NeXT.com)