mykes@3comvax.UUCP (Mike Schwartz) (02/01/86)
*** REPLACE THIS LINE WITH YOUR MESSAGE *** I appologize for the intrusion, but I thought some of you Mac folks might be able to help us Amiga folks by posting a review of the ztec MANX 'C' compiler for the Mc. All of us Amiga developers have been suffering with Lattice 'C' and could use an alternative. If anyone knows about any other Mac products that will be ported to the Amiga and that will take advantages of its enhanced graphics and sound capabilities. Also, has anyone out there heard of a company named MicroForge or used any of their products? If you have, a review would likewise be much appreciated. Sorry again to intrude on your desktop publishing (or whatever it is that you do with your macs). Best regards, mike schwartz
jane@wucs.UUCP (Jane Mack) (02/11/86)
I've been using the Aztec system for about a year and I'm pretty happy with it, except of course that it compiles a whole lot slower than the c compiler on our vax. Our source code is over 700 kB spread over 77 modules (some of them quite small) and our executable code is 220 kB. We've only had a few minor problems. (1) The most troublesome problem is the code generated when you have a handle to a record, and you assign the result of some function to one of the fields in that record. The compiler caches the address of the record structure in a register, calls the function, and then calculates the address of the particluar field of the record that is to receive the result. It calculates this result address using the address that it cached before the function call. Well, as you can guess, if the function allocates a lot of memory, then memory will be compacted to make room and the record structure will be moved. Hence, the cached address is garbage. We think this is a bug. To get around it, either use a temporary variable to receive the result of the function, or lock the handle before calling the function. (2) Make doesn't work when you have as many modules as we do. (3) To link with the c and math libraries when your executable code is big you have to include them both at the beginning and the end of the ln command. Overall I think the Aztec system is pretty good. good luck. jane mack
gwe@cbdkc1.UUCP ( George Erhart x4021 CB 3D288 RNB ) (02/13/86)
In article <1430@wucs.UUCP> jane@wucs.UUCP (Jane Mack) writes: >(1) The most troublesome problem is the code generated when you have a handle ^^^^^^ >to a record, and you assign the result of some function to one of the fields >in that record. The compiler caches the address of the record structure >in a register, calls the function, and then calculates the address of the >particluar field of the record that is to receive the result. It calculates >this result address using the address that it cached before the function call. >Well, as you can guess, if the function allocates a lot of memory, then >memory will be compacted to make room and the record structure will be >moved. Hence, the cached address is garbage. The keyword here is *handle*. Inside Mac makes a big deal about explaining the difference between handles and simple pointers. They state very clearly that if you are going to reference an item pointed to with handles, AND you are going to do anything that allocates memory ... lock the handle before using it or the memory manager may rearrange things on you. To be on the safe side ... lock all handles before using and unlock them when you are done. The purpose of having handles was to allow a form of garbage collection that is langauge independent. While it does mean that the programmer must aware of the process, it does provide for running larger programs and larger data structures. -- George Erhart at AT&T Bell Laboratories Columbus, Ohio 614-860-4021 {ihnp4,cbosgd}!cbdkc1!gwe
lsr@apple.UUCP (Larry Rosenstein) (02/21/86)
In article <1305@cbdkc1.UUCP> gwe@dkc1.UUCP ( George Erhart x4021 CB 3D288 RNB ) writes: >The keyword here is *handle*. Inside Mac makes a big deal about explaining >the difference between handles and simple pointers. They state very clearly >that if you are going to reference an item pointed to with handles, AND >you are going to do anything that allocates memory ... lock the handle >before using it or the memory manager may rearrange things on you. To be >on the safe side ... lock all handles before using and unlock them when >you are done. The Software Supplement also contains a list of the ROM calls that allocate or move objects on the heap. For example, you don't have to worry about a call to SetRect but you have to worry about DrawString (calls the Font Manager, which may swap in the font). -- Larry Rosenstein Apple Computer UUCP: {voder, nsc, ios, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET