Xref: utzoo comp.sys.amiga:68039 comp.os.minix:12707 Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga,comp.os.minix Subject: Re: MINIX on the Amiga... Message-ID: <1990Oct5.014208.25903@zorch.SF-Bay.ORG> Date: 5 Oct 90 01:42:08 GMT References: <1990Sep24.114627.14857@watserv1.waterloo.edu> <1990Oct1.000617.3676@zorch.SF-Bay.ORG> <1838@Terra.cc.brunel.ac.uk> Organization: SF-Bay Public-Access Unix Lines: 71 eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> sreiz@cs.vu.nl (Reiz Steven) writes: >>> guineau@wjg.enet.dec.com (W. John Guineau) writes: >>>> I've been talking with Andy Tanenbaum about Minix. [...reordered a bit here to read better:] >>> - Minix can't access memory outside the 16 MB range. This is caused by >>> the way addresses are encoded in the memory manager. >> >> Whew! We already got bitten by this one with AmigaBASIC. I hope >> someone [...] leaves the full 32-bit memory addressing accessible. >> This is pretty gross for code written for the 1990's. >> >>> [...] this doesn't seem a very serious problem to me anyhow. >> >> It does to me! I'm running a vanilla Amiga 2000 with 9.5 meg of >> RAM, and I could easily put ten times as much to use on a regular >> basis. [...] >> There is little if any excuse for >> turning address longwords into records to save a byte here or >> there in a memory management scheme's overhead when memory is dirt >> cheap and widely available. [...] > As regards your other comments, they are, IMHO a bit over the top. I'm known for the _passion_ of my writing; it comes built in. That doesn't invalidate the content of the writing, just makes it a little hard to choke down. > Remember that the code from which the Amiga MINIX is derived was > originally written to run on an ST, which has a hardware design > limitation of 4Mb of memory. And will never have a hardware upgrade that removes this limit? Ha! > I think that the encoding of the vector number into the upper > nybble of the PC is actually pretty neat; admittedly not very > portable, but then we all have 20-20 hindsight, don't we? Doesn't take hindsight, just paying attention. The IBM 360 series Operating Systems have gone through the shock trauma ward every time the hardware address space has added a bit or two to real memory addressing, and that's been going on for 20 years that I know about. The problems caused by Microsoft using the high order bytes in their BASIC interpreters for cute tricks have affected the Amiga for five years, and earlier platforms even longer. Part of the result of such trash programming is that they have _never_ delivered a bug free release. There are many other examples of antique vintage to show what a horrible idea this was long before it was ever first done in MINIX. This is _not_ code design to praise as "pretty neat". There can be few clearer examples of "those who will not study history are condemned to repeat it." > And remember that memory is not necessarily as cheap elsewhere in > the world as it is in the USA ... Well, we import all of ours from outside the country, so the opportunity for it to be that cheap surely exists. Citizens who allow their politicians to install tarrifs that keep them poor or deprived of needed goods deserve their fates. That's why we have ballot boxes in Western Civilization(tm). The problems with being unable to cope with the 68020 and 68030 stack frames are comparitively forgiveable; that requires extra code to cope with changed hardware. Glad to hear that folks are factoring in the needed changes; I hope a good update, central maintenance, and change sharing mechanism is in place. Kent, the man from xanth.