braner@batcomputer.tn.cornell.edu (braner) (12/21/87)
[]
I have just sent away for the Laser C upgrade, and will post when I get it.
But don't worry, Greg. 5 seconds for compile+link of a SMALL program is
certainly feasible WITHOUT tokenizing the source code. The current Megamax
compiler (not linker) reads a text file off the RAMdisk and compiles it
in about 2 seconds _once_the_compiler_is_launched_. The recent Megamax
flyer says something about their new (graphical) shell keeping multiple
programs (e.g., editor, compiler and linker) RESIDENT in RAM (not filed
in a RAMdisk), presumably saving a couple of seconds on the launching of each.
- Moshe Braner
PS: For those of you that had problems uudecoding IDLE:
Remove the 'z' at the end of each line.
(Sorry for that. Source was sent to Turner)
PPS (literally): speaking about tokenizing, couldn't the Postscript page-
description language, which is known for its slowness, be substantially
speeded up through tokenizing? That would also save on the communication
time (length of text sent to the printer) and disk space (if saved as
Postscript). Printing an (Atari ST mono screen) bitmap on an Apple
Laserwriter (via 9600-baud serial line) takes a couple of minutes, and the
recent Cricket Draw for the Mac saves a typical graph on the disk as a
50-100K file!
PPPS: When, oh when, will we have compiler support for writing GEM metafiles,
and a GEM-->Postscript translator? (Anybody looking for a project? :-)wolenty@inuxj.UUCP (R Wolenty) (02/24/88)
Well, I got my new Laser C update yesterday! Unfortunately the Utilities disk was unreadable - sending it back for replacement. While program space may be free of 32K segmentation limits, it appears this limit still exists for initialized data. I have a program that initializes several large arrays - I used to get a segmentation error message of some type. Now I get an exception message that says CCOM.TTP is out of memory. A quick check of free RAM shows more than 512K avaiable. Seems like an odd error message. Can anyone from Megamax comment?? Ron Wolenty ATT Consumer Products Indianapolis, IN inuxj!wolenty
rob@hhb.UUCP (Robert R Stegmann) (02/25/88)
[This space intentionally not blank.]
Some info:
Yesterday (2/23) I found in my mailbox the long-awaited upgrade to
Megamax's compiler, Laser C. The package contained three SS disks
and a small sheaf of excerpts from the not-yet-ready manual. An
accompanying letter explained that due to problems with their printing
service, Megamax won't be able to ship the manual until 2/29 but it
will be released "as soon as is humanly possible."
A question:
Does anyone know if Data Pacific's Translator One allows one to run
copy-protected Mac software "out of the box?" Specifically, I'm
wondering if 'Sargon III' and/or Mindscape's 'Uninvited' work.
A short product review:
If you are tied to a monochrome system don't bother buying MichTron's
'Cards' software package. The user interface is woefully primitive.
They don't even use grays to distinguish between black and red cards,
which makes playing solitaire an exercise in frustration.
I've seen better PD card games (albeit for the Mac).
rob
Robert Stegmann
{allegra,ihnp4,decvax}!philabs!hhb!rob
Disclaimer, Datclaimer, D'udderclaimer.benoni@ssc-vax.UUCP (Charles L Ditzel) (02/25/88)
In article <321@inuxj.UUCP>, wolenty@inuxj.UUCP (R Wolenty) writes: > Well, I got my new Laser C update yesterday! Unfortunately the > Utilities disk was unreadable - sending it back for replacement. me too. Seems like they got a bad batch of disks let out...i sent mine back and they will be sending me back a new utilities disk. The environment is great! I like the environment, seems better than MWC. Tho' I will reserve judgement until i get my docs and utilities. Laser has a nice make, shell, and windowing environment. ----------
ST901922@BROWNVM.BITNET ("Edward S. Miller") (02/25/88)
LASER C HAS ARRIVED! I unexpectedly received a package from Megamax yesterday (2/23) containing three disks comprising the upgrade of Megamax C, some interim docs (look like xerox of manual, and provide a glimpse of what looks like a GREAT manual!!!), and a note of apology from the company. They say the full docs will arrive soon after 2/29/88. I guess this info will be of more use to those who might be contemplating buying Laser C, because I assume that if I got the software, so did the rest of the Megamax owners who will read this! Anyway, the package looks real nice. The editor and shell are now combined, and the shell has been GREATLY enhanced. It contains UNIX-style environment-string management (maybe something like MWC, from what I have gathered by reading this newsgroup's postings), a sort of mini-dos shell (very well done), a dynamic disk cache that, from my already heavy usage, ahs proven to be an amazing piece of work!. It also manages a set of user-selectable tools, which are kept RAM-resident. That's right! When you load the shell, you can tell it to load the compiler, linker, make-interpreter, and any other utilities you want. Then compilations are almost INSTANTANEOUS. You don't even have the overhead of loading from a ram disk! The disk cache routines seem to be so efficient that you seriously do not need a ram disk at all. I used to have a 512k ram disk for Megamax development at all times. No more! The editor has been enhanced; the scrolling is faster than anything I have ever seen for the ST, even faster than most Mac editors and wp's I have seen. (The only problem is that they wrote their own windowing routines and occasionally there are very minor glitches with them.) The shell will also trap 68000 exceptions and provide you with a symbolic traceback if you asked for a symbol table at link time. The program nm.ttp has been added to the package to read a symbol table. The ONLY thing missing is a source-level debugger. I have never used MWC, but I bet csd with Megamax C would be quite a combo. Seriouly, folks, the hello, world program compiles IN LESS THAN FIVE SECONDS with no ram disk or other tricks. Sorry if I have rambled on but I am absolutely in love with this product! I KNEW that $200 was worth it! DISCLAIMER: this is my first posting, so the disclaimer expressed herein is nonbinding.
michel@megamax.UUCP (Michel Rynderman) (02/26/88)
There is NO limit to the size of ANYTHING in the new Laser C. However, the problem you experienced is due to an inefficiency in the C compiler. For each piece of data in an initialized structure or array a 32 byte node is created. (This is REALLY DUMB!) This leads to a pig out on available RAM. The compiler is then terminated by the shell because it ran out of memory. I will fix the compiler and anyone who needs a copy just give me a call. Michel @ megamax -- The views expressed herein and thereabout are necessarily and unconditionally the intentions to sprout forth a vast array of knowledge and understanding of quantum mechanics and the relationship of meta physical thought and eggs.
wolf@csclea.ncsu.edu (Thomas Wolf) (02/26/88)
In article <8802250639.AA17856@ucbvax.Berkeley.EDU> ST901922@BROWNVM.BITNET ("Edward S. Miller") writes: > >LASER C HAS ARRIVED! > ...a nice introduction to Laser C... > >Anyway, the package looks real nice. The editor and shell are now >combined, and the shell has been GREATLY enhanced. It contains... ... more description... Thanks for this nice review. I have only TWO questions before I hurry out the door and get this package: 1) Since the editor is now part of the shell, does that mean I wouldn't be able to use another editor? (I've been spoiled by Tempus, I guess :-) 2) Does Laser C handle arrays bigger than 32k? I would really appreciate info on these two points, either by e-mail or by posting the answers. Tom Wolf ARPA (I think): tw@cscosl.ncsu.edu or wolf@csclea.ncsu.edu
grieggs@devvax.JPL.NASA.GOV (John T. Grieggs) (02/26/88)
In article <1704@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >In article <321@inuxj.UUCP>, wolenty@inuxj.UUCP (R Wolenty) writes: >> Well, I got my new Laser C update yesterday! Unfortunately the >> Utilities disk was unreadable - sending it back for replacement. >me too. Seems like they got a bad batch of disks let out...i sent >mine back and they will be sending me back a new utilities disk. Yeah, right. Um, at the potential expense of becoming a pest, I wish to state that I sincerely hope that Megamax did not label a set of disks and send them out containing nothing useful. Such an action would be quite unworthy of any professional software company. I also wish to mention that I intend to upgrade my Megamax as soon as some reliable upgrade to Laser is available. I will most likely not use it much, since I have MWC, but will certainly attempt compiles of the stuff I port upon it. Schlafe... -- John T. Grieggs (Telos @ Jet Propulsion Laboratory) 4800 Oak Grove Drive, Pasadena, Ca. 91109 M/S 301-260A (818) 354-0465 Uucp: {cit-vax,elroy,chas2}!jpl-devvax!grieggs Arpa: ...jpl-devvax!grieggs@cit-vax.ARPA
wolf@csclea.ncsu.edu (Thomas Wolf) (02/27/88)
In article <1282@megamax.UUCP> michel@megamax.UUCP (Michel Rynderman) writes: >There is NO limit to the size of ANYTHING in the new Laser C. However, >the problem you experienced is due to an inefficiency in the C compiler. >For each piece of data in an initialized structure or array a 32 byte >node is created. (This is REALLY DUMB!) This leads to a pig out on available >RAM. The compiler is then terminated by the shell because it ran out of memory. > >I will fix the compiler and anyone who needs a copy just give me a call. > >Michel @ megamax Will the version which is about to appear in stores (or has it already?) have this "bug"? I'm just curious since I'm about to make the purchase (as soon as our local dealer has it). Tom Wolf ARPA (I think): tw@cscosl.ncsu.edu or wolf@csclea.ncsu.edu
michel@megamax.UUCP (Michel Rynderman) (02/29/88)
Laser C that will show up in the stores will not have this bug. Also this bug will only show up when you have around 15,000 initialized "things" That is a lot of typing and will probably only affect a minute number of people. (That number is also per file. not the overall number per program) 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.
braner@batcomputer.tn.cornell.edu (braner) (02/29/88)
[]
I finally sat down and tried out the new Laser C (Megamax 2.0). First I
installed it on the hard disk. One main file refused to copy at first,
I had to try several times. Bad diskette? The graphical shell will take
getting used to but seems rather nice: much better than the desktop, and
includes some commmand-line features. A main point of frustration for
me is that command lines must be terminated by ENTER, not RETURN. I guess
that's for safety, since one can enter a command line from an editor window.
But in the "STDIO" window pressing RETURN is just second nature to me.
On the other hand, one can go back (even scroll the window back!) to a former
command, put the cursor at the end of the line, and press ENTER. One can
even select (by dragging the mouse) a block of lines, press return, and
(ta-da!) it is like a shell script (alas without conditionals, etc).
The shell includes installation of system tools as resident in RAM, and a
disk cache with write-through optional separately for each tool. The
compiler and linker work very fast if they are in RAM and their output
is NOT write-through. That's how the 4-second turn-around time is achieved.
(That's right: if you edit a small program in an editor window, and press
Control-R, you get the output of the program in about 4 seconds!)
One can opt for saving of the source before compilation, just in case.
When one quits from the shell all non-deleted not-written-through
output is flushed to disk. But first the "cache management" dialog
is activated, where one can decide delete some files (e.g., *.o) from
the cache so they will NOT be written to disk.
A bit of snooping with the supplied disassembler shows:
- block initialized data: no more element-by element copying
when one codes "static int a[] = {1,2,3,4,5,6,7,8};".
- FP ops (as in "double a,b,c; a=b+c;") are done like this:
move b-->fpreg0 (two move.l's)
pea c
pea fpreg0
jsr doubleadd <--- no more dispatcher nonsense
(push opcode, call central...)
The very fast turnaround time means simple benchmarks are very easy to do.
Here are some DOUBLE FP times, in MICROSECONDS (millionths of a second):
dabs 60 <--- they don't call it fabs :-(
add/sub 160
mul 250
div 320
sqrt 1800
exp 2300
log 2800
(These times include a complete C statement including assignment of the
results, e.g., "double a,b,c; a=b+c;".) I believe these are pretty good
results for SW FP on an 8MHz 68000. I havn't tried the Savage benchmark
right now but when Megamax sent me a prerelease of the new FP package it
was faster---and more accurate---than Absoft FORTRAN, which fits with
the above results.
Other things I noticed in my first session with Laser C:
- The supplied "cat" utility displays text with the newlines
missing, i.e., as one long line. This is true even for
text files created with their editor!
- My utility "MORE.TTP" does not work right when invoked from
inside the shell (using "tos more filename"). It reports
a "TOS error", meaning the file was not found. I suspect
the shell passes command-line args to the program in a
nonstandard way: MORE.TTP was written in AL and examines
the basepage directly. Other .TTP programs I tried (e.g.,
my version of microEMACS) read the args fine. Any ideas?
- Text in the shell's windows is drawn and scrolled VERY fast,
especially given that these are standard GEM windows (at
least they appear to be, with scroll bars, resizeable, etc).
- When I run microEMACS from inside the shell, it reads long text
files much more slowly than it does when invoked from the
desktop. E.g., a 25K C source file takes about 3 seconds
outside, 6 seconds inside the Laser C shell. The only
reason I can think of is that the cache is not very fast
and gets in the way. (Those times are from the hard disk.)
#include <std.disclaimer>
- Moshe Braner
PS: trying to run UNITERM from INSIDE the Laser C shell resulted in
a crash that was too much even for that shell's exception-trapping
facilities!wolf@csclea.ncsu.edu (Thomas Wolf) (02/29/88)
In article <1287@megamax.UUCP> michel@megamax.UUCP (Michel Rynderman) writes: >Laser C that will show up in the stores will not have this bug. Also this bug ...[some deleted stuff]... Could you let us know when Laser-C is expected to show up in stores? Any info on this would be greatly appreciated. Tom Wolf ARPA (I think): tw@cscosl.ncsu.edu or wolf@csclea.ncsu.edu
braner@batcomputer.tn.cornell.edu (braner) (03/01/88)
[] So other people also have problems with the Laser C upgrade disks? I must add to my story that the almost-unreadable disk I got was apparently used before: some scratches on the shutter. My theory is that (since they asked us to send in the original disks) they reused the old disks. I don't think that's very bad (remember: we only paid $20 for the upgrade, including the (still to arrive) new manual) but I wish they (1) used _my_ old disks (they were not scratched...) and (2) did a better verify on the copies... - Moshe Braner Addendum to my preview of Laser C: The editor (and the whole shell) are very distinctly Mac-ish, for better or worse. E.g., when choosing system tools to install in RAM upon launch I feel like I'm in the Mac's Font/DA Mover, what with two lists of items and an [>>add>>] button, etc. Also, the file selector boxes that pop up when you click on "compile" or "run other programs" in the "execute" menu are NOT the (ugh, tfoo!) standard GEM version but a much nicer original version. Better than the Mac's, too.
michel@megamax.UUCP (Michel Rynderman) (03/01/88)
> <comments about nothing useful on utilities disk for Laser C > >Schlafe... >-- >John T. Grieggs (Telos @ Jet Propulsion Laboratory) There were a number of "bad" utility disks that were sent out as upgrades to Laser C. They were duplicated incorrectly somehow. They contained utilities cp,ls,rm,mv,rmdir,Resource Construction Program, egrep and a couple others. I would say that these are quite useful. 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.
michel@megamax.UUCP (Michel Rynderman) (03/02/88)
>Could you let us know when Laser-C is expected to show up in stores? Any info >on this would be greatly appreciated. Since we received the manuals from the printer on 2/29 we should ship new orders by the beginning of next week (3/7) This includes orders from dealers and the like. 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.
klute%trillian.irb@unido.uucp (Rainer Klute) (07/28/88)
Finally! Laser C is now also available in Germany. Tuesday last week I received an order form saying I could get Laser C as an update to Megamax C V1.1 for DM 80.00 (approx. $43, sigh). I ordered it immediately. Yesterday it came from Application Systems Heidelberg, Megamax' german distributor, on two double-sided disk (well, they used single sided ones formatted as double-sided). I installed it on my harddisk and haven't had any problems yet. The manual seems to be complete and makes a very good impression. Rainer Klute +---------------------------+------------------------------------------+ | Rainer Klute | UUCP: klute@unido.uucp | | University of Dortmund | (...uunet!mcvax!unido!klute) | | Dept. of CS | BITNET: klute@unido.bitnet | | P.O. Box 500500 | | | D-4600 Dortmund 50 | | +---------------------------+------------------------------------------+ | Federal Republic of Germany | +----------------------------------------------------------------------+
klute%trillian.irb@unido.uucp (Rainer Klute) (08/02/88)
After a few days of working with my new Laser C I stumbled over
some errors. Here they are:
1. LASER C doesn't work if GDOS is resident. The shell starts up
correctly but crashes as soon as a program is loaded.
2. In OSBIND.H a typedef is made for the 'disk transfer address'
used by functions Fsfirst() and Fsnext():
typedef struct {
char dta_reserved[21]; /* reserved */
char dta_attr; /* attribute */
unsigned int dta_time; /* time */
unsigned int dta_date; /* date */
long dta_len; /* length */
char dta_name[14]; /* name */
} dta;
On the other hand Fgetdta() is defined as
#define Fgetdta() (dta *)gemdos(0x2f)
which causes some error messages when Fgetdta() is used. To
overcome this the quoted typedef should be changed to
typedef struct _dta { ... } dta;
3. Conversion from double to float does not work for numbers
greater than 6.805647338418769898282789654E38.
4. The Resource Construction Program sometimes crashes in the
"Save" function. Redress: use the "Save as" function.
That's it so far. Any comments (Megamax)?
I am willing to compile a list of errors in Laser C. So if you
found out any more errors please report them to me by mail. I
will summarize to the net.
Rainer Klute
+---------------------------+------------------------------------------+
| Rainer Klute | UUCP: klute@unido.uucp |
| University of Dortmund | (...uunet!mcvax!unido!klute) |
| Dept. of CS | BITNET: klute@unido.bitnet |
| P.O. Box 500500 | |
| D-4600 Dortmund 50 | |
+---------------------------+------------------------------------------+
| Federal Republic of Germany |
+----------------------------------------------------------------------+pa1132@sdcc15.UUCP (pa1132) (09/27/88)
I am just interested in Laser C. In the newest issue of STart an article on C mentions that Laser C has some window management routines. Can anybody with experience on Laser C give more info on this? Any help is appreciated.
rjung@sal6.usc.edu (Robert allen Jung) (09/27/88)
In article <569@sdcc15.UUCP> pa1132@sdcc15.UUCP () writes: >I am just interested in Laser C. In the newest issue of STart an >article on C mentions that Laser C has some window management >routines. Can anybody with experience on Laser C give more info on >this? Any help is appreciated. Laser C's window management routines are some Megamax-specific (non-GEM, non-Unix) functions that help in window manipulation, redraw, and whatnot. For instance, instead of calculating intersecting rectangles (as you must when you redraw a GEM scree that's been updated), Laser C comes with a "calculate-intersection-of-two-rectangles" route. I'd give more specific details, but I haven't written a mega-big window- based application yet. B-) --R.J. B-) P.S. Laser C i, in my opinion, _the_ best C package for the ST right now. ----------------------------------------------------------------------------- Disclaimer: These are my views, and mine alone. # ## # Mailing address: Beats me, just reply to this message # ## # (rjung@nunki.usc.edu?) ## ## ## #### ## ####
rjung@sal45.usc.edu (Robert allen Jung) (01/19/89)
In article <904@laura.UUCP> klute%trillian.irb@unido.UUCP (Rainer Klute) writes: >In article <4029@mtuxo.att.com> rcd@mtuxo.att.com (XG1V6-R.DUTT) writes: >>1) Laser C crashes when the compiler and linker are RAM-resident. > >Laser C does not like GDOS.PRG. Try without it. Just thought I'd also mention that the Laser C GEM shell works quirkly with Shadow installed (who's at fault?!?). The usual process of compile-link-run (^R) won't always work, which makes it a hassle to get some programming done while trying to call bulletin boards. B-) And does anybody know when Laser DB is shipping? --R.J. B-) ============================================================================= Disclaimer: This message was written with my authorization # ## # # ## # Mailing address: rjung@nunki.usc.edu ## ## ## (It's easier to just use the reply function, tho) #### ## ####
uace0@uhnix2.uh.edu (Michael B. Vederman) (01/19/89)
In article <2377@nunki.usc.edu> rjung@sal45.usc.edu (Robert allen Jung) writes: >In article <904@laura.UUCP> klute%trillian.irb@unido.UUCP (Rainer Klute) writes: >>In article <4029@mtuxo.att.com> rcd@mtuxo.att.com (XG1V6-R.DUTT) writes: > Just thought I'd also mention that the Laser C GEM shell works quirkly with >Shadow installed (who's at fault?!?). The usual process of compile-link-run >(^R) won't always work, which makes it a hassle to get some programming done >while trying to call bulletin boards. B-) > > And does anybody know when Laser DB is shipping? > Please don't blame SHADOW for this! LASER C doesn't work with many programs that take over some vectors while in the shell, or even before you enter the shell. LASER C does some very funny things to 'watch' vectors so it can trap out problems on crashes, etc. I can't use AMONST (memory resident debugger/monitor) with LASER C Shell. - mike -- for (;;) : Use ATARINET, send an interactive do_it(c_programmers); : message such as: : Tell UH-INFO at UHUPVM1 ATARINET HELP University Atari Computer Enthusiasts : University of Houston UACE
silvert@dalcs.UUCP (Bill Silvert) (01/29/89)
I just got my Laser C upgrade and find that even after installation
according to instructions (in folder E:\MEGAMAX) it still insists on
loading the RAM-resident routines from drive A. Anyone know how to run
Laser C without using the floppy drives?
--
Bill Silvert, Habitat Ecology Division.
Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2
UUCP: ...!{uunet,utai,watmath}!dalcs!biomel!bill
CDN: biomel@cs.dal.CDN BITNET: bs%dalcs@dalac.BITNETklute%trillian.irb@unido.uucp (Rainer Klute) (01/30/89)
In article <3155@dalcs.UUCP> silvert@dalcs.UUCP (Bill Silvert) writes: >I just got my Laser C upgrade and find that even after installation >according to instructions (in folder E:\MEGAMAX) it still insists on >loading the RAM-resident routines from drive A. Anyone know how to run >Laser C without using the floppy drives? Did you set the environment variables apropriately? There are some to control the location of the Laser C tools. The environment variables can be set by the menu item "Environment variables" within the "Options" menu. Don't forget to save your configuration to E:\MEGAMAX\LASER.CFG. Rainer Klute ---- klute@irb.informatik.uni-dortmund.de Universitaet Dortmund, IRB |)|/ klute@unido.uucp, klute@unido.bitnet Postfach 500500 |\|\ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 ---- Tel.: +49 231 7554663
pvf@bridge2.3Com.Com (Paul V. Fries) (01/31/89)
In article <3155@dalcs.UUCP> silvert@dalcs.UUCP (Bill Silvert) writes: >I just got my Laser C upgrade and find that even after installation >according to instructions (in folder E:\MEGAMAX) it still insists on >loading the RAM-resident routines from drive A. Anyone know how to run >Laser C without using the floppy drives? I have been running the Laser C system for quite a while now. It has been so long, in fact, that I am not entirely certain about this information... I think all I did was to go to the options menu tools submenu and tell it where the tools were. Anyway, all my tools are loaded from the F: drive, no problems. It might be good to delete the saved setup file (in the MEGAMAX folder) before you start setting this up so that you don't have to wait for the floppy before being able to setup the new environment. BTW It is not so easy to get all programs to be as small under Laser as they were under Megamax 1.0 and 1.1. This is partly due to the 32 bit pointers to global data, etc, but also because a most of the stdio library gets included even when you never use anything in it. Under 1.1, I was able to change init.c so as not to force inclusion of this stuff, at the expense of having to make sure I explicitly close disk output files when I use them. As this is a good practice anyway, the price seems small to me. What I did was to make the exit call in init.c actually call _exit(). I also had to rewrite the command line parser code so it didn't force the library in. Under Laser, they no longer supply init.c, only init.o. So, on Laser, I had to patch init.o (I used a disk utility program) so the name "_exit" became "__xit". This was done in the symbol table section. Then, I added my own __xit() routine (in a file called xit.c) that just called _exit. To complete the customization, I changed the CINIT environment variable to include both init.o and xit.o. Small changes made my command line parser work with the new execution structure of Laser. The result is that I can write little utility programs that are now very small again. Things like a hex file dumper, or a program that times other programs, etc no longer end up 6K big. (I just couldn't stand seeing all that disk space wasted :-) ) pvf
glk2017@uxf.cso.uiuc.edu (02/01/89)
Why the heck would you want the ram resident routines in a ram disk? Once loaded, they are RAM RESIDENT. All trials including gem programs may be run from the shell! Jeez! To judge is to feel judged! E.C.Spieu! The Escaper!
to_stdnet@stag.UUCP (02/01/89)
From: thelake!steve@stag.UUCP (Steve Yelvington) pvf@diablo.3Com.com writes... > Under Laser, they no longer supply init.c, only init.o. > ... > So, on Laser, I had to patch init.o (I used a disk utility program) > so the name "_exit" became "__xit". This is why Sozobon C is such a deal. Not because it's free but because you get the source code to the library, compiler, assembler and utilities. If something's broken, you can at least stare at broken code instead of .o files. :-) > The result is that I can write little utility programs that are now > very small again. Things like a hex file dumper, or a program that > times other programs, etc no longer end up 6K big. (I just couldn't > stand seeing all that disk space wasted :-) ) Me neither. It's amazing how many examples in C books toss in printf() to do the work of puts() or, on the ST, Cconws(). Ka-blooey! There goes the code size. Incidentally, I tinkered around with a minimum dumb terminal program under Sozobon the other night and the compiled result was 885 bytes WITHOUT hacking the startup module. That doesn't compare with assembler, of course. David Parsons' "hup" program to toggle DTR on the modem port is only 85 bytes. THAT'S a small utility. * Watch that return address! Reply to: * stag!thelake!steve@bungia.mn.org (UUCP) * crash!pnet51!steve@trout.nosc.mil (ARPA) * St. Paul Winter Carnival! Hail Boreas! Defeat Vulcanus Rex!
klute%trillian.irb@unido.uucp (Rainer Klute) (02/02/89)
In article <285@bridge2.3Com.Com> pvf@diablo.3Com.com (Paul Fries) writes: >Under Laser, they no longer supply init.c, only init.o. > >So, on Laser, I had to patch init.o (I used a disk utility program) >so the name "_exit" became "__xit". This was done in the symbol >table section. Then, I added my own __xit() routine (in a file called >xit.c) that just called _exit. To complete the customization, I changed >the CINIT environment variable to include both init.o and xit.o. That's astonishing! I *did* get init.c with my Laser C. Rainer Klute ---- klute@irb.informatik.uni-dortmund.de Universitaet Dortmund, IRB |)|/ klute@unido.uucp, klute@unido.bitnet Postfach 500500 |\|\ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 ---- Tel.: +49 231 7554663
wsr@tippy.uucp (02/05/89)
q q