koreth@ssyx.ucsc.edu (Steven Grimm) (03/08/88)
I'm porting a program (BB/ST, my bulletin board system)) to Laser C
(from Megamax 1.1). All the C stuff compiles without a hitch, but the
inline assembly is a bit different. In particular, I need to know how
to reference a label defined in an inline assemble segment, from the
rest of the program. This code worked on the old compiler:
extern foo();
asm {
foo:
clr.l A7
rts
}
You could call foo() from another part of the program. That doesn't seem
to work in Laser C. My other question is probably closely related; I want
to install some trap handlers. The code
lea trap1hand(PC), A0
move.l A0, 0x90 ; or whatever address
worked in Megamax C; now it says "trap1hand undefined", even if it's defined
in the same asm{} block. I've tried taking away the "(PC)", changing it
to move.l #trap1hand, 0x90 (which would be the ideal way to do it), and a
couple other things, to no avail.
Any help would be appreciated.michel@megamax.UUCP (Michel Rynderman) (03/12/88)
There are a few ways of getting the address of a label.
1.
extern foo()
asm {
lea foo,A0
}
This does work. (I just tried it out)
asm {
label1:
nop
lea label1(PC),A0
lea label1.L,A0
}
This also works.
asm {
lea label2(PC),A0
label2:
rts
}
Michel@megamaxpaone@topaz.rutgers.edu (Phil Paone) (04/17/88)
I recently purchased Laser C version 1.01 for my ST. I love this compared to my two year old Lattice C compilier which was almost useless. Anyway, I have copied all the files into C:\MAGAMAX and altered the config file to look there, but everytime I run the program, the compilier and like gets loaded from the A: drive. Why? Thanks, Phil Paone -- Phil Paone paone@topaz.rutgers.edu ihnp4!moss!oac!ppaone "Admiral...There be whales here"
michel@megamax.UUCP (Michel Rynderman) (04/18/88)
Remember that Tool Locate... changes the environment variables. Do a Tool Locate Then look at the environment vars. Make sure they all go to C: instead of A: Then do a Save Configuration. Michel@megamax -- Anyone who would like a reply to their mail sent to me needs to give a uucp path. The mailer on our system is weird. Either that or give me a tel. number and I'll give you a call. UUCP: pollux!megamax!michel PHONE: 214-987-4931
david@bdt.UUCP (David Beckemeyer) (04/19/88)
In article <Apr.16.16.13.26.1988.11487@topaz.rutgers.edu> paone@topaz.rutgers.edu (Phil Paone) writes: > ... I have copied all the files into C:\MAGAMAX and >altered the config file to look there, but everytime I run the >program, the compilier and like gets loaded from the A: drive. Why? I have this same problem. The documentation is pretty weak in this area and they don't provide a script to automatically install it onto the hard disk. I struggled with it for a long time, editing config files, changing setup variables, etc. but I couldn't get it to just run from the HD and not try to find stuff on A:. How stupid! Why not just start looking at the drive I ran Laser.prg from for a \megamax directory instead of messing around with A:? And if you're not going to do that, at least under the section called "Installing onto a Hard Disk" which is in nice big letters in your manual, explain what to do. If the information is hiding someplace else in the manual, move it to the "Installing onto a Hard Disk" section becuase that's where somebody's going to expect it. I also found that Laser C has problems running quite a few programs when using it's STDOUT window. From what I can see, no programs compiled with MWC will work. That means a lot of programs from the net and other useful tools won't work with Laser C. First impressions remind me a lot of Haba Hippo C. Anybody remember that one? In defense of Megamax though, it's clear that they put *A LOT* of effort into Laser C. I wasn't able to get it to work yet though, which is probably a combination of lack of time on my part and lack of installation scripts on the part of Megamax. -- David Beckemeyer | "Yuh gotta treat people jes' like yuh Beckemeyer Development Tools | do mules. Don't try to drive 'em. Jes' 478 Santa Clara Ave, Oakland, CA 94610 | leave the gate open a mite an' let 'em UUCP: ...!ihnp4!hoptoad!bdt!david | bust in!"
braner@batcomputer.tn.cornell.edu (braner) (04/20/88)
[] The early version of Laser C (1.0) always spun drive A: for a second but then DID go and load everything from the hard disk (assuming you set all the paths and tool locations, under the OPTIONS menu, to drive C:, and then clicked on "SAVE CONFIGURATION".) The newer release (1.01, I got it in the mail together with the manual) seems to have fixed that bug altogether. There IS a problem with running some TOS programs from inside Laser C's STDIO window. I never figured out when it is safe to just type the program's name, and when you have to precede it with "tos" (giving it the whole screen but loosing the ability to capture the output in the STDIO window, which is back-scrollable and cut-and-pasteable). By "not safe" I mean that the output rolls off the window. There is also a problem with TTP programs. Some (e.g. my MORE utility) do not get the command-line arguments correctly. TTP programs compiled with Laser C work fine. MORE was written in AL and it looks in the base page for the unaltered command line. I havn't had the time to figure out what exactly happens when you invoke it from the STDIO window but it does not get the command line right, probably gets a garbage filename to print, and ends up with a "TOS error" message. As for speed: yesterday I timed Laser C (on a 1040 + SH204) doing a complete recompile of GNOME (190K source code in 13 files, 53K output binary). It took just over 3 minutes. Not bad at all, although Turbo C on a rather fast IBM-AT clone with a much faster HD (but no caching of any sort!) did it in 90 seconds. Execution speed? An optimized C version of the Fast Hartley Transform (see April BYTE) transformed a 512-point data set on my ST in 1.7 seconds, everything in double precision software FP. (1.2 seconds for repeated calls with the same N, keeping the work arrays in-between!). Compare that with the 27 seconds quoted in the BYTE article for the Pascal version (on a Macintosh, i.e. similar CPU power, although it might have used (in)SANE...). - Moshe Braner 69 Ringwood Rd., Freeville, NY 13068 (607) 347-4573 (Home) (607) 255-9401 (Work) <braner@tcgould.tn.cornell.edu> (ARPANET) <braner@crnlthry> or <braner@crnlcam> (BITNET) PS: GNOME 2.2 is almost ready, and it comes in a DA flavor too. Should I post it? How much memory should the DA hog? (It must allocate a large text buffer upon boot since DA's are not supposed to call Malloc() later. My current setup uses a 90K buffer (the program uses another 50K) and one can only edit about 50K of text in there due to both malloc- and data-structure overhead. The plus is that the text stays in it between separate openings of the DA.) Warnings to users of GNOME 2.1: do not press ^C to try and abort numeric-prefix-entry mode, and do not press the up or down arrows when choosing a buffer to go to if there is no other buffer. (These and other bugs are fixed in 2.2.) If you know of any other bugs in GNOME 2.1, _PLEASE_ tell me soon. Thanks.
depeche@CALVIN.CS.MCGILL.CA (S Alan EZUST) (12/11/89)
Yes, I am still suffering with Laser C... I notified the company of the many annoying bugs which are in their latest verision (2.1) but they haven't responded in any way whatsoever, so until I get myself PC-Speed so I can run Turbo C 2.0, I gotta make do with what I got... Since there is no mem.h library of routines, I use strncpy to copy the contents of one-dimensional arrays. Does anyone know if there is another function which does a really fast memory copy of Two-Dimensional arrays? At the moment all I can do is nested loops of assign statements (or maybe I could do loops of strncpys), but this is stupid. Strncpy won't allow me to copy n*n bytes starting at the location of the [0][0]th byte even though I know that is where the stuff I want to copy is. If anyone can help me here, I'd appreciate it. And if you do reply, please send me the reply in PRIVATE mail as our newsfeed is temporarily down and I can't read news easily... -- S. Alan Ezust depeche@calvin.cs.mcgill.ca McGill University Department of Computer Science - Montreal, Quebec, Canada