mkent@violet.berkeley.edu.berkeley.edu (/violet_d/mkent) (05/29/86)
I've been doing some development on the Amiga with the Lattice C compiler (in fact I have the old version, 3.02 I believe). I'm having the general problem that any runtime error in my C programs, even something like passing a routine an int instead of a float, crashes the entire system (so I have to reboot and reload the entire system, and of course all context of the error is lost). This is usually accompanied by some kute and klever guru meditation number, about which I've been unable to find any explanation in my (also version 1) ROM kernal manual. Of course, this kind of behavior renders debugging extremely painful and slow. The amiga is my first experience with a microcomputer; I do most of my work on lisp machines and vaxen. I want to beleive there's some simple thing I'm failing to do which will enable the system to give some useful information and, most importantly, not to just roll over and drop dead when it encounters an error in user code. (I'd like not to believe I've spent $2000 on some kind of TOY!) Can someone tell me what the actual situation is about this? Thanks, Marty Kent MKent%ucbviolet@berkeley.edu
randy@cbmvax.cbm.UUCP (Randy Weiner) (05/30/86)
In article <758@jade.BERKELEY.EDU> mkent@violet.berkeley.edu.UUCP () writes: > > I've been doing some development on the Amiga with the Lattice C >compiler ...any runtime error in my C programs...crashes the >entire system. >... This is usually accompanied by some kute and klever guru >meditation number, about which I've been unable to find any explanation... The information you seek may be found in the include file, exec/alerts.h. Here is where the system DEFINEs are located for most of the possible errors. This is especially helpful in Version 3.02 since the comments should still be part of the disk file. In brief, the number to the left of the '.' represents an error number, and the number to the right is the address of the task/process that has failed. User programs are typically loaded at address $97D2 (or thereabouts). Look familiar? -- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Randy Weiner -- Commodore Business Machines <<Amiga Technical Support>> uucp: {ihnp4|seismo|caip}!cbmvax!randy arpa: cbmvax!randy@seismo (or) randy@cbmvax.UUCP@{seismo | harvard} TEL: 215-431-9180
dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (05/31/86)
Unfortunetly, since the Amiga does not have an MMU, an error in a user program is more likely to overwrite vital system storage (or other user programs). Dat's za vey it goes. The only way to improve on Developer's System Crash (DSC Syndrome, not to be confused with DHC Syndrome 'Developer's Head Crash'), is to run-time check as much as your willing to code in to attempt to catch error's before they do something destructive. -Matt "juz 'was a little thung, Ah called ClearMenuStrip with the Menu structure instead of the Window structure, and the System said bye bye"
wagner@utcs.uucp (Michael Wagner) (06/02/86)
In article <8605310909.AA00952@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: > > Unfortunetly, since the Amiga does not have an MMU, an error in >a user program is more likely to overwrite vital system storage (or other >user programs). > -Matt > Lots of people seem to think that MMUs are the only way of solving such problems. Protection against bad stores has existed in mainframe architecture much longer than virtual memory has. Memory keys, supervisory modes, 'safe area' registers (which have a proper name I can't remember right now) are all attempts to close up the worst holes. MMUs solve the problem to a much greater extent, because you can't even address the memory you shouldn't be touching. Unfortunately, the Amiga doesn't seem to implement any of these. There is a supervisory mode, but it doesn't deal with storage protection, unless you add logic off-chip to do it. Too bad AMIGA didn't. Michael Wagner (wagner@utcs)
eric@chronon.UUCP (Eric Black) (06/04/86)
In article <1265@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >Lots of people seem to think that MMUs are the only way of solving >such problems. Protection against bad stores has existed in mainframe >architecture much longer than virtual memory has. Memory keys, >supervisory modes, 'safe area' registers (which have a proper name I >can't remember right now) are all attempts to close up the worst holes. >MMUs solve the problem to a much greater extent, because you can't even >address the memory you shouldn't be touching. > >Unfortunately, the Amiga doesn't seem to implement any of these. >There is a supervisory mode, but it doesn't deal with storage protection, >unless you add logic off-chip to do it. Too bad AMIGA didn't. Explain to me how these techniques are not "Memory Management". Reminder: MMU stands for "Memory Management Unit", NOT "Memory Mapping Unit". You are confused by the fact that the current spate of single-chip solutions to some memory management problems all seem to have logical address mapping (whether virtual or not). Ignoring the advantages that address mapping will give (e.g. easier implementation of shared code!), the protection capability of an MMU does not stem primarily from allowing or not allowing addressability; rather, it is the ability to permit or deny particular types of access to specific ranges of addresses (whether those addresses get mapped before going to the RAM chips or not). Sound like what you were talking about? Do you think that mainframes which implemented memory keys and the like did it "on-chip"? -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric
hsgj@batcomputer.TN.CORNELL.EDU (Dan Green) (06/06/86)
In article <1265@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >In article <8605310909.AA00952@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: >> >> Unfortunetly, since the Amiga does not have an MMU, an error in >>a user program is more likely to overwrite vital system storage (or other >>user programs). >> -Matt >> I was really impressed with the Amiga's software protection. This evening I compiled a program, and ran it - it immediately gave a requester saying "Please finish all disk activity before I blow up your machine(sic)" and when I pressed CANCEL it put up a Guru meditation number and the Amiga rebooted. HOWEVER - After the reboot, I did a newcli and then ran my horribly buggy program from the newcli. The result - Again the error requester window popped up. BUT, I clicked on the backwindow gadget, got to my InitialCLI, and WAS ABLE TO DO ANY COMMAND FROM THE INITIAL CLI! In other words, the error had effected only the newcli process, but I could still use my machine from the original CLI. Avail, of course, reported much less free memory, but things were still running. This really impressed me that with one process completely comatose the others could still run. Of course, there is the small problem that my g-d d-mn f-c-i-g program is not running, but hey - what else is new? -- Dan Green ARPA: hsgj@vax2.ccs.cornell.edu ~~~~~~~~~ BITNET: hsgj@cornella UUCP: {decvax,ihnp4,allegra}!cornell!batcomputer!hsgj
wagner@utcs.uucp (06/06/86)
Both this and a previous article are reposts, due to some software problems. Sorry for those who see both sets before the cancel messages propegate. In article <281@chronon.chronon.UUCP> eric@chronon.UUCP (Eric Black) writes: >In article <1265@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: [ I wrote that MMUs aren't the only way to deal with memory protection. I listed other memory protection schemes that did not require memory mapping ] > >Explain to me how these techniques are not "Memory Management". Reminder: >MMU stands for "Memory Management Unit", NOT "Memory Mapping Unit". >You are confused by the fact that the current spate of single-chip >solutions to some memory management problems all seem to have logical >address mapping (whether virtual or not). Ignoring the advantages >that address mapping will give (e.g. easier implementation of shared >code!), the protection capability of an MMU does not stem primarily >from allowing or not allowing addressability; rather, it is the >ability to permit or deny particular types of access to specific ranges >of addresses (whether those addresses get mapped before going to the >RAM chips or not). > >Sound like what you were talking about? Do you think that mainframes >which implemented memory keys and the like did it "on-chip"? >-- >Eric Black "Garbage In, Gospel Out" >UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric I think we are basically agreed, but are having a wording problem. It is true that MMU stands for Memory Management Unit. In a similar vein, an air conditioner is anything that conditions the air (including, presumably, my humidifier, and the heater currently sitting disconnected in the closet), but common convention takes it to mean a cooling device. I fell into the sloppyness of refering to one of the 'current spate' of memory mapping units. My point was that, if they thought a memory mapper was too expensive, less expensive solutions (that offer less functionality) exist. I listed a few. I think Eric and I agree there. Incidentally, much of the support in mainframes for memory keys was in the CPU ('on-chip' is a litle difficult to parse in that context, since the CPU was typically a whole board of chips). Every memory fetch also sent a key to the CPU (so the data bus was wider). The CPU compared the data key with the current running key. In the case of the Amiga, one could consider the 68000 having two keys, Supervisor and Problem Program, and external logic for checking. There are, of course, many other ways of doing this too. After all this discussion, it's still sad that Amiga didn't implement any of the many possibilities. Michael (wagner@utcs)