spe@cad.cs.cmu.edu.UUCP (03/02/87)
Keywords:
[eat this, line-eater: <<<ICBM<<====<<]
I don't want to start any great arguments here, but:
I've been thinking of dumping my big blue and getting an Amiga.
Basically, my reasons are that there's really no interesting hacking
that I can do on my IBM, and all I use it for is dialing up. I have
heard conflicting reports on the Amiga's hackibility, does anyone have
comments, either good or bad? Is it nice to hack on, and if so, why?
Is it really nasty to hack on, and if so why?
Thanks muchly!
--
----------------------------------------------------------------------
I have no opinions. Therefore my employer is mine.
----------------------------------------------------------------------
Sean Philip Engelson +---------------+
Carnegie-Mellon University | POST NO BILLS |
Computer Science Department +---------------+
----------------------------------------------------------------------
ARPA: spe@cad.cs.cmu.edu
UUCP: {harvard | seismo | ucbvax}!cad.cs.cmu.edu!spe
----------------------------------------------------------------------dillon@CORY.BERKELEY.EDU.UUCP (03/04/87)
Hacker's Heaven, assuming you buy the manual set. -Matt
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/07/87)
[ Ok, smarty pants, what's the capital of Mesopotamia? ] I tried mailing this, but more often than not, anything I try to mail off this site fails miserably. My apologies to the net.police. -----------------Original un-sent message follows--------------- In article <1055@cad.cs.cmu.edu> you write: > >[eat this, line-eater: <<<ICBM<<====<<] > >I don't want to start any great arguments here, but: > Which is why I'm mailing you.... >I've been thinking of dumping my big blue and getting an Amiga. Good for you. >Basically, my reasons are that there's really no interesting hacking >that I can do on my IBM, and all I use it for is dialing up. I have >heard conflicting reports on the Amiga's hackibility, does anyone have >comments, either good or bad? Is it nice to hack on, and if so, why? >Is it really nasty to hack on, and if so why? > Yes, it is a Real Hacker's machine. Allow me to attempt to qualify this statement. There are three little custom chips inside with several dozen registers that can be fiddled with. There is a co-processor that can be programmed to reload any of the custom chip registers on a video frame-by- frame or line-by-line basis. However, direct hardware tromping is not a nice thing to do under the Amiga's multitasking OS. The OS has been written to help arbitrate the resources to competing tasks. The OS design is very clean, efficient, and easy to use (for me). Note that, in speaking of the OS, I am seperating the Exec from the DOS. The Exec is the underlying and true core of the Amiga OS, and it's wonderful. The DOS was written in England by MetaComCo, and sucks rocks. But you can usually code around the DOS, and there is fame and fortune to be made in this area. Note that there is a VERY STEEP learning curve on the Amiga, and it will take you about four months of hacking before you begin to see the global picture. It will also change your way of thinking about the way computers should be designed and programmed. The system will also make you a better programmer, by forcing you to write paranoid code that checks to make sure that you really did get the resource you asked for, and that you free all the resources you allocated (no resource tracking in the Amiga). I think the rewards far outweigh the drawbacks, and am pleased that Yet Another Hacker is turning to the Amiga for its hackability. I think it's the most hackable machine to come out since the old S-100 systems of the late 70's, and has the same kind of wonderful feel to it. This is all my subjective reaction. I strongly suggest you play with an Amiga for a while before buying one. And you'll also have to get used to seeing Guru Meditation Numbers when developing code. Also, get the MANX compiler. Lattice is cheaper, and that's because it's crud. MANX also comes with an assembler, Lattice doesn't. Oh well, hope this helps. >Thanks muchly! > You're very welcome. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."
mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) (03/08/87)
In article <2719@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >The Exec is the underlying and true core of the Amiga >OS, and it's wonderful. The DOS was written in England by MetaComCo, and >sucks rocks. But you can usually code around the DOS, and there is fame and >fortune to be made in this area. Carefull, there - the stuff written in England is what provides all the nice message passing, library primitives, resource allocation and etc. that people like so much. I think that the real crud is in the attempt to mate a BCPL system with a C system. >Also, get the >MANX compiler. Lattice is cheaper, and that's because it's crud. MANX also >comes with an assembler, Lattice doesn't. Hmm - gee, that sounds like a subjective statement. I'll just point out that for porting code from Unix, Lattice is the better compiler to have (last time I looked, MANX wouldn't even pass as a v7 C compiler, much less anything modern). And that Lattice _does_ come with an assembler. From that, you should be able to decide how much trust to put in Mr. Schwab's compiler judgement. "If your compiler doesn't support structure assignment, get a better compiler." - from comp.lang.c <mike But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BITNET
manx@well.UUCP (Jim Goodnow II) (03/08/87)
Newsgroups: comp.sys.amiga Subject: Re: Amiga good for hacking?? Summary: Judge Not, Lest Ye Be Judged Expires: References: <2719@well.UUCP> <2705@jade.BERKELEY.EDU> Sender: Reply-To: manx@well.UUCP (Jim Goodnow II) Followup-To: Distribution: world Organization: Whole Earth 'Lectronic Link, Sausalito, CA Keywords: In article <2705@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) writes: >In article <2719@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>The Exec is the underlying and true core of the Amiga >>OS, and it's wonderful. The DOS was written in England by MetaComCo, and >>sucks rocks. ... > >Carefull, there - the stuff written in England is what provides all >the nice message passing, library primitives, resource allocation and >etc. that people like so much. ... > ... NO! NO! NO! The EXEC does the nice stuff. AmigaDOS _only_ handles the file system and the concept of processes. Let's give credit where credit is due. >>Also, get the >>MANX compiler. Lattice is cheaper, and that's because it's crud. MANX also >>comes with an assembler, Lattice doesn't. > >Hmm - gee, that sounds like a subjective statement. I'll just point >out that for porting code from Unix, Lattice is the better compiler to >have (last time I looked, MANX wouldn't even pass as a v7 C compiler, >much less anything modern). And that Lattice _does_ come with an >assembler. From that, you should be able to decide how much trust to >put in Mr. Schwab's compiler judgement. > > "If your compiler doesn't support structure assignment, get a > better compiler." - from comp.lang.c The Manx compilers have supported structure assignment since the very first compilers for the 8080 and the 6502 were shipped in 1982. When _was_ the last time you looked? Leo may be a bit zealous in his judgement, but on the other hand, he does spend a _lot_ of time programming the Amiga and has access to both compilers. Jim Goodnow II "I guess I need a trailer now ... "
miner@ulowell.cs.ulowell.edu (Richard Miner) (03/08/87)
In article <2705@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes: >Carefull, there - the stuff written in England is what provides all >the nice message passing, library primitives, resource allocation etc. Sorry Mike but the Amiga's EXECutive, designed and developed by Carl Sassenrath at Amiga in CA, provides the elegant multi-tasking message passing capabilities in the systems kern[ea]l. It also provides the library and device facilities, does resource allocation and manages all of the system lists. Carl S. also wrote the design specification for an OS to layer on top of EXEC. His OS would have: done resource tracking, better file management, resembled more traditional OS's, and interfaced a lot nicer with EXEC and the rest of the Amiga environment. Unfortunately, lack of resources at Amiga and hassles with a contracted company resulted in a last minute dependency on the BCPL based TRIPOS port by Metacomco. :-( -- Rich Miner ULowell-Cntr for Productivity !ulowell!miner 617-452-5000x2693
hsgj@batcomputer.tn.cornell.edu (Dan Green) (03/09/87)
NOTE: This note is *not* meant to start compiler arguments. Lattice is always flamed for producing large code. For instance, a file compiled with Manx might be 10Kbytes, whereas the executable from Lattice might be 25K. Those of us who have Lattice can get around this shortcoming by simply not including the Lattice lc.lib "library", and linking with AStartup.obj instead of Lstartup.obj. What you lose is stdio. In Intuition or Graphics/Sound oriented applications this is no loss at all. If you need to read files, you can use AmigaDos directly instead of fopen(), etc. Losing the string routines (strcpy,strlen, etc) is a shame, but these are easy to write. What I did was spend an hour writing those stdio routines that I needed, and just linked that file along with my application. The real bugger is mult and divides. Lattice *stupidly* handles these by function calls, (eg CXM33) which are in lc.lib. The amiga.lib has IMulU() and IDivU() to multiply and divide 16-bit USHORTS, but this means you have to explicity convert. For example: x = a * b; ==> x = IMulU( (USHORT)a, (USHORT)b ); BENEFITS: Doing this extra work results in much smaller code. A heavily Intuitioned application of mine went from 26K to 14K when these techniques were applied. If you think about it, aside from the string ops not much of the stdio lib is frequently used, so there is not really that much work to do (Again remember that all the file i/o stuff is replicated in AmigaDOS calls, such as Open, Seek, etc). MAJOR DRAWBACKS: Bye, bye portability and maintainence!! It is very difficult to keep translating the stupid mults/divs, and if AmigaDOS is ever replaced, your application is dead, whereas if you relied on stdio all you'd have to do is recompile. *** FLAME ***: Why does so much of lc.lib get included, even if it is not used? If this was fixed (by BLINK (the official linker, these days) or Lattice) all would be well. CONCLUSION: If you are stuck with Lattice (it is, after all, blessed by CBM) then if you take some time you can shrink code size down a lot for applications that are very Amiga specific by getting rid of lc.lib. -- Dan Green -- ARPA: hsgj%vax2.ccs.cornell.edu@cu-arpa.cs.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (03/09/87)
In article <2705@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) writes: >In article <2719@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>The Exec is the underlying and true core of the Amiga >>OS, and it's wonderful. The DOS was written in England by MetaComCo, and >>sucks rocks. But you can usually code around the DOS, and there is fame and >>fortune to be made in this area. > >Carefull, there - the stuff written in England is what provides all >the nice message passing, library primitives, resource allocation and >etc. that people like so much. I think that the real crud is in the >attempt to mate a BCPL system with a C system. > Not correct (at least I'm 99.9999% sure it's not correct). AmigaDOS was written in BCPL and crufted on top of the Exec. The DOS is an (improperly implemented) library under the Exec. Exec provides the message passing, resource allocation, library manipulation, etc. Exec was handcrafted in assembly by Carl Sassenrath (sp?). DOS, on the other hand, simply provides the filesystem, file maintenance, and a higher-level device interface consistent with the filesystem. Whenever DOS requires a non-DOS resource (like memory, access to a device, etc), it calls the Exec. The real problem with DOS may indeed be the poor BCPL/C interface (Did you know BCPL stacks grow upwards in memory? Did you know that BCPL uses D0 as an address register? Yuk.), but I prefer to believe that it was either a sleazy BCPL compiler, or the MetaComCo programmers were suffering from braindeath :-). >>Also, get the >>MANX compiler. Lattice is cheaper, and that's because it's crud. MANX also >>comes with an assembler, Lattice doesn't. > >Hmm - gee, that sounds like a subjective statement. Yup. You got it. I've used both Lattice and MANX. I like MANX, and would never go back to Lattice. So shoot me then :-). >I'll just point >out that for porting code from Unix, Lattice is the better compiler to >have (last time I looked, MANX wouldn't even pass as a v7 C compiler, >much less anything modern). And that Lattice _does_ come with an >assembler. It does? Is this a new addition to their standard package? Or do they bundle MetaComCo's assembler with it? > "If your compiler doesn't support structure assignment, get a > better compiler." - from comp.lang.c > MANX does support structure assignment (at least I think it does). In past code I've written, I've been able to say: struct foo s1, s2; s1 = s2; The only difference is that Lattice lets you say: struct foo s1, s2, s3, s4, s5; s1 = s2 = s3 = s4 = s5; Mike is quite correct; my statement concerning Lattice is quite subjective. I haven't used Lattice of late, but speaking personally, I like my compilers to be "single" pass (i.e. I don't have to invoke two seperate commands), to compile to assembly, and have a reasonably UNIX-like command structure. Like I said, I haven't used Lattice of late, so they may have addressed all these issues. If anyone wants to start a compiler war, my mailbox is wide open. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."
mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) (03/09/87)
In article <2729@well.UUCP> manx@well.UUCP (Jim Goodnow II) writes: >>In article <2719@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>>The Exec is the underlying and true core of the Amiga >>>OS, and it's wonderful. The DOS was written in England by MetaComCo, and >>>sucks rocks. ... >> >>Carefull, there - the stuff written in England is what provides all >>the nice message passing, library primitives, resource allocation and >>etc. that people like so much. ... > >NO! NO! NO! The EXEC does the nice stuff. AmigaDOS _only_ handles the file >system and the concept of processes. Let's give credit where credit is due. I've very carefully avoided digging into the guts of AmigaDOS (I spend far to much time in the guts of larger, uglier OS's as it is...). I asked C/A for a description of how AmigaDOS, the EXEC & TRIPOS fit together. The answer that came back was "TRIPOS and AmigaDOS are one and the same (essentially)." Someone from C/A care to correct that? If the EXEC is C/A work, it means they re-created the TRIPOS kernel (after all, the file system expects a specific kind of support; if a re-written EXEC doesn't provide it, then the file system must have been re-written), or are responsible for lots more than just the EXEC. >>Hmm - gee, that sounds like a subjective statement. I'll just point >>out that for porting code from Unix, Lattice is the better compiler to >>have (last time I looked, MANX wouldn't even pass as a v7 C compiler, >>much less anything modern). And that Lattice _does_ come with an >>assembler. From that, you should be able to decide how much trust to >>put in Mr. Schwab's compiler judgement. >> >The Manx compilers have supported structure assignment since the very >first compilers for the 8080 and the 6502 were shipped in 1982. When _was_ >the last time you looked? A couple of months ago. My understanding was that 3.20 didn't have such features, but that 3.40 would (does?). First check was before I had a compiler; I asked at the Commodore show in February of '86, and was told "no." So I "got a better compiler." >Leo may be a bit zealous in his judgement, but on the other hand, he does >spend a _lot_ of time programming the Amiga and has access to both compilers. True, I don't have access to both compilers. I have to base my opinions on what I hear from salespeople and people who use the compiler. From that, it appears that MANX is a slightly better compiler. As usual in such cases, whoever got the most recent release out tends to be slightly ahead, but the MANX releases occur more frequently. Certainly not enough better to justify buying a second C compiler for a hobby. Also not enough to justify slinging mud around on the net (I'll give Leo credit: that was meant to be a personal letter; he should have edited it before posting it to the net). Final comment: for porting code, which compiler will depend on what you're porting from. MANX apparently uses BSD-like libraries; Lattice is working on becoming ANSI standard, which means SysV-like libraries. Many of the problems over and above those are due to bogosity in the Unix code (try porting the v7 pack to _anything_; that was the first thing I tried feeding to a MANX compiler....). If the 32-bit int mode is now fully supported in MANX, then you won't need to fix a lot of them. <mike -- But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BITNET
mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) (03/09/87)
In article <2736@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>Carefull, there - the stuff written in England is what provides all >>the nice message passing, library primitives, resource allocation and >>etc. that people like so much. I think that the real crud is in the >>attempt to mate a BCPL system with a C system. >> > Not correct (at least I'm 99.9999% sure it's not correct). AmigaDOS >was written in BCPL and crufted on top of the Exec. You're right. See my previous posting "Subject: AmigaDOS & Tripos (was: etc.)" for details. >The real problem with DOS may indeed >be the poor BCPL/C interface (Did you know BCPL stacks grow upwards in >memory? Did you know that BCPL uses D0 as an address register? Yuk.), but >I prefer to believe that it was either a sleazy BCPL compiler, or the >MetaComCo programmers were suffering from braindeath :-). I've not played with a 68K BCPL compiler. The 370 compiler was incredible. PL/O was a little better. VS/FORTRAN was better. Nothing else could touch it. (Example: it compiled a switch into either a then/else chain, a binary search, or a hash table, depending on how large the switch was.) The compiler was structured sorta-kinda like PCC, so it wouldn't surprise me if the same compiler was used on the 68K. BTW, did you know that lots of Unix 68K C compilers use D0 to hold addresses? > It does? Is this a new addition to their standard package? Or do >they bundle MetaComCo's assembler with it? > Mike is quite correct; my statement concerning Lattice is quite >subjective. I haven't used Lattice of late, but speaking personally, I like >my compilers to be "single" pass (i.e. I don't have to invoke two seperate >commands), to compile to assembly, and have a reasonably UNIX-like command >structure. Like I said, I haven't used Lattice of late, so they may have >addressed all these issues. His first question is about an assembler. Yes, Lattice 3.10 comes with an assembler, in all it's packages. It's not the MetaComCo assembler; it's one of theirs. They also have a driver with Unix-like command structure (which I threw out in favor of cc, of course), make, editors, etc, most of which I could care less about. They also give you the metascope debugger (heaven, if only it spoke C instead of assembler!), and omd, which gives me back the assembler in a .o file, with the C statements that generated that code. The resulting system (with a couple of meg of memory) makes for a _nice_ development environment. I prefer it to a Sun. <mike -- But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BITNET
daveh@cbmvax.UUCP (03/09/87)
in article <2705@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) says: > > In article <2719@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>The Exec is the underlying and true core of the Amiga >>OS, and it's wonderful. The DOS was written in England by MetaComCo, and >>sucks rocks. But you can usually code around the DOS, and there is fame and >>fortune to be made in this area. > > Carefull, there - the stuff written in England is what provides all > the nice message passing, library primitives, resource allocation and > etc. that people like so much. I think that the real crud is in the > attempt to mate a BCPL system with a C system. No, no, no, no. The message passing, task swapping, devices, libraries, lists, memory allocation, etc. are all part of the Exec subsystem. Its true that AmigaDOS builds on top of these constructs (like Exec Tasks being a subset of DOS Processes) and provides easier access to them (like directly managing a console.device versus opening the DOS device "CON:"), but all of these low level items are part of Exec, and I think that most of these, at least in 1.2, are written in assembler, not C and certainly not BCPL. > <mike -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __ ____ ____ _____ _____ _____ Dave Haynie /// / _ | / __ \ / _ \ / _ \ / _ \ Commodore Technology /// / / | | /_/ | | | | | | | | | | | | | | |\ /// / /__| | ____/ | | | | | | | | | | | | | |\\/// / ____ | / ____/ | | | | | | | | | | | | \\// / / | | | |____ | |_| | | |_| | | |_| | {ihnp4,etc.}!cbmvax!daveh \/ /_/ |_| \______| \_____/ \_____/ \_____/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
spencer@mica.BERKELEY.EDU (Randy Spencer) (03/10/87)
In article <1519@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: >in article <2705@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) says: >> >> Carefull, there - the stuff written in England is what provides all >> the nice message passing, library primitives, resource allocation and >> etc. that people like so much. I think that the real crud is in the >> attempt to mate a BCPL system with a C system. > >No, no, no, no. The message passing, task swapping, devices, libraries, >lists, memory allocation, etc. are all part of the Exec subsystem. Its true >that AmigaDOS builds on top of these constructs (like Exec Tasks being a >subset of DOS Processes) and provides easier access to them (like directly >managing a console.device versus opening the DOS device "CON:"), but all of >these low level items are part of Exec, and I think that most of these, at >least in 1.2, are written in assembler, not C and certainly not BCPL. > >> <mike > __ ____ ____ _____ _____ _____ >Dave Haynie /// / _ | / __ \ / _ \ / _ \ / _ \ >Commodore Technology /// / / | | /_/ | | | | | | | | | | | | | | ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | | | | | | | | Cute result of cutting .signature file. So if what RJ says (thru Mitsu, though I have heard it myself) is true then somewhere out there is a really great operating system for the Amiga just waiting to be born. It would give us a real hackers computer. No longer would it take hackers extrodinaire to figure out the workings between the C stuff and the BCPL stuff (like Jim Goodnow and his fexec()). There would be resource tracking and all the fancy stuff that Mitsu mentioned. It would be such a dream to program that people everywhere would sell their anything box and race out to buy the Amiga 1000 because on top of all the great stuff that made it into the box on release (blitter and such custom chips, high res NTSC analog RGB video, multitasking with variable resolution screens, devices for everything, and message passing between them all, autoconfig expansion, etc. etc. etc. ad-infinitum), a real CS buff's dream in a box, there would also be that wonderful operating system sitting on top of the bug-less Exec, making everything run smoothly. That would be 100%. Every thing done right! It would really be the computer to beat! Only that ain't happened yet. We have AmigaDOS, it's OK, but the potential is so much more. All that wonderful planning, it almost boggles the mind how all the parts of the Amiga work together, but in the first magazines that I read about the Amiga (what was that? ten years ago?) all they talked about was the operating system, "tripos, not Unix!" And that is all that I have heard since. I fear that the perspective buyer gets that as his first impression also. "Weird operating system". So, I for one am interested in seeing where that "other" operating system could have taken us. Maybe, if there was enough interest, there would be some money set asside to finish the work on it. Heck, isn't the Amiga really taking off? This might be the perfect gift for it. Maybe they are just going to take tripos and change it function call by function call into the REAL "Amiga Dos". What do people think would be involved? Who would we need to get involved to increase our chances of making it a reality? What would be the consequences? Destroying the entire current software base? Starting everybody again as if it were a new machine? Maybe if the original Amiga Dos was supposed to do resource tracking it had support for an MMU, like the one that Amiga will have with its 68020 card. Can't do an MMU with the 68000 (unless you get rid of those nasty A2000 burned in ROMs.) So, do we want to see the Amiga that was to be on the 68020 card, or shall we just put Unix on it? Unix, line oriented, background commands with the & operator. No Intuition windows, no Amiga software at all, just Unix on that 68020 card. Am I dreaming? (as John Adams says in "1776") "...does anybody see... what I see?" {"John your a bore, we've heard it before, so for God's sake, John, sit down!"} -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) (03/10/87)
in article <370@batcomputer.tn.cornell.edu>, hsgj@batcomputer.tn.cornell.edu (Dan Green) says: > Summary: Getting LATTICE exe's smaller > > NOTE: This note is *not* meant to start compiler arguments. > > Lattice is always flamed for producing large code. For instance, a > file compiled with Manx might be 10Kbytes, whereas the executable > from Lattice might be 25K. Those of us who have Lattice can get > around this shortcoming by simply not including the Lattice lc.lib > "library", and linking with AStartup.obj instead of Lstartup.obj. > ... > string routines (strcpy,strlen, etc) is a shame, but these are > easy to write. What I did was spend an hour writing those stdio > The real bugger is mult and divides. Lattice *stupidly* handles > these by function calls, (eg CXM33) which are in lc.lib. The amiga.lib ... > -- Dan Green Dan - You can leave "lc.lib" on the END of your library list and pick up the math package (CXM33) and even pickup the string routines. alink from astartup.obj+foo.o to foo lib amiga.lib+lc.lib The math module isn't that big... ============================================================================== Phillip Lindsay - Commodore Business Machines - Amiga Technical Support UUCP: {ihnp4|seismo|caip}!cbmvax!phillip - Phone: (215) 431-9180 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making. /* eof */
carolyn@cbmvax.UUCP (03/11/87)
In article <370@batcomputer.tn.cornell.edu> hsgj@batcomputer.UUCP (Dan Green) writes: >NOTE: This note is *not* meant to start compiler arguments. > >Lattice is always flamed for producing large code. For instance, a >file compiled with Manx might be 10Kbytes, whereas the executable >from Lattice might be 25K. Those of us who have Lattice can get >around this shortcoming by simply not including the Lattice lc.lib >"library", and linking with AStartup.obj instead of Lstartup.obj. > >What you lose is stdio... mult and divides... string functions Not so. 1. stdio Astartup.obj sets up the AmigaDOS filehandles stdin, stdout, stderr. These can be referenced as external LONGs in your code, or you can use them automatically with the some abbreviated stdio functions which are built in to Amiga.lib. Amiga.lib contains a printf() which works fine with %lx, %ld, and %s. It's a bit weird with %c (I think you must use %lc) and it does not handle floating point. Amiga.lib also contains a getchar(). I get along fine with these two stdio functions. Astartup (unlike Lstartup) does not open an stdio window when a program is started from WorkBench. I wrote a modified Astartup called TWstartup which does open an Amiga stdio window on WorkBench, using a console spec defined in the application. This startup is also handy for non-stdio applications while debugging things like WB argument handling and reading of ToolTypes, etc. There is a new 1.2 version a Astartup which handles quoted command line args in a manner more consistent with the parsing done by the BCPL CLI commands. My current TWstartup is built upon this version. Both Astartup and TWstartup (.asm and .obj) are on the release version of the 1.2 Readme disk in the "1.2 Native Developer Update". The update is a four disk set available directly from CBM. - 1.2 Includes, Amiga.lib, fd's - 1.2 Stripped Includes - 1.2 Autodocs (demo Infominder format) - 1.1 Readme disk (demo InfoMinder, demo InfoMinder format Readmes, ARC'd text Readmes and Autodocs, 1.2 function offset tables, 1.2 Astartup and TWstartup) To order, send check for $20 made out to Commodore Business Machines to: Kim Montgomery Software Tech Support CBM 1200 Wilson Drive West Chester, PA. 19380 Be sure to specify what you are ordering, and include your name/address. 2. mult and divide The Lattice compiler does require LC.lib to do non-power-of-two division and multiplication. But you can link with LIBRARY Amiga.lib, LC.lib and get those routines from LC.lib without taking too big a hit in code size. 3. string functions Same goes for string functions. Link with LC.lib second if you want to use Lattice's string functions. Check out the Addison-Wesley Rom Kernel Exec manual for a description of the C support functions in Amiga.lib. I only use printf() and getchar() but there are others. And remember that to use Astartup or TWstartup, you must use the -v flag on LC2 to disable Lattice's insertion of stack-checking code. (That code requires _base and _xcovf in Lstartup) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
grr@cbmvax.UUCP (03/11/87)
In article <2725@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) writes: > >I've very carefully avoided digging into the guts of AmigaDOS (I spend >far to much time in the guts of larger, uglier OS's as it is...). I >asked C/A for a description of how AmigaDOS, the EXEC & TRIPOS fit >together. The answer that came back was "TRIPOS and AmigaDOS are one >and the same (essentially)." Someone from C/A care to correct that? You have: Exec (muli-tasking kernel) Intuition (windowing) Graphics Libraries (sound, math, etc also) AmigaDOS (perhaps organized as a library) Commands/Utilities Only the last two are TRIPOS/Metacomco/BCPL related. I not sure there is a good name for the aggregate - AmgiaDOS is usually used as an all-inclusive name, but obviously this creates some confusion from time to time. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jesup@steinmetz.UUCP (03/12/87)
In article <370@batcomputer.tn.cornell.edu> hsgj@batcomputer.UUCP (Dan Green) writes: >Lattice is always flamed for producing large code. For instance, a >file compiled with Manx might be 10Kbytes, whereas the executable >from Lattice might be 25K. Those of us who have Lattice can get >around this shortcoming by simply not including the Lattice lc.lib >"library", and linking with AStartup.obj instead of Lstartup.obj. With the new -b option (based-relative) code, and the -r option (pc-relative jsr's), Lattice code is the same size or smaller, except for libraries. The libraries in 3.10 (You DO have it, don't you?) are much more granular than 3.03. The other problem is that the default lattice startup code includes sdtio, even if you yourself don't. It can be recompiled with the -dTINY option to remove such things. >Losing the >string routines (strcpy,strlen, etc) is a shame, but these are >easy to write. You don't have to lose them! Just put amiga.lib BEFORE lc.lib, and anything it can't find in amiga.lib will be pulled from lc.lib. This also fixes the CXM33, etc thing. WARNING: Amiga.lib has a subset of stdio that assumes stdin and stdout are variables with the AmigaDos filehandles in them. It's printf also wants 'l's before a long value (unlike lattice). This includes characters (%lc). >The real bugger is mult and divides. Lattice *stupidly* handles >these by function calls, (eg CXM33) which are in lc.lib. The amiga.lib >has IMulU() and IDivU() to multiply and divide 16-bit USHORTS, but >this means you have to explicity convert. For example: >x = a * b; ==> x = IMulU( (USHORT)a, (USHORT)b ); See above. >*** FLAME ***: Why does so much of lc.lib get included, even if it >is not used? If this was fixed (by BLINK (the official linker, these >days) or Lattice) all would be well. As said above, get 3.10, use -b and -r (and of course -v), and use smallcode and smalldata in blink. My application went from 47K to 34K just by recompiling with 3.10 (and I already didn't use anything from lc.lib but the string functions and the multiplies). >-- Dan Green Randell Jesup jesup@steinmetz.uucp (rochester!steinmetz!jesup) jesup@ge-crd.arpa
wagner@gpu.utcs.toronto.edu (03/12/87)
One of the really nice things about USENET is that, in a discussion such as this one, you get people like the software authors themselves contributing. One of the not-so-nice things about USENET is that, sometimes, the software authors make contributions without pointing out their biases. Jim Goodnow can be expected to have a bias in favour of the MANX compiler. He wrote it. Michael