#IBM & Apple Bed Partners
29 messages in this thread
Tim,
Ah, but just to be be obnoxious <grin>, what happens on an Amiga if that
test program…
main() {
while (1); }
..starts out as the highest priority process? Reboot time?
Anyway, it's been pointed out many times that Apple would love to switch to
a preemptive system, but back-compatability is the uhhh, higher priority
right now 🙂 In a similar manner, Commodore would probably love to add
memory protection to the Amiga, but cannot because it would break an awful
lot of current programs. Everyone gets locked in somewhere. cheers – kev
I think Commodore would rather add device independent graphics than memory
protection, but can't do it very easily for the same reasons. IMHO,
Commodore does not need memory protection because of the structure of the
operating system. The message passing by reference would have to be
changed substantially which probably negatively affect system performance.
With the new enforcer and memoration tools, software developers can test
their software at low memory conditions for run away pointers and track
them down quickly. With the release of AmigaDos 2.04, I think we are going
to see much more robust software applications released. I like to think of
AmigaDos 1.1,1.2, and 1.3 as Beta releases. AmigaDos 2.04 is orders of
magnitude more stable than previous releases.
Tim
Good point. The Amiga's multitasking is far more valuable to me than would
be memory protection: Why have dedicated circuitry check the integrity of
your programs millions of times/second when you can do that yourself in one
session of putting the program through its paces? A person bitching about
data lost due to a crash is just as bad as someone who uses a hard disk
error as an excuse for losing a week-old data file; There is no excuse for
not regulary saving your work (hotkey or automatic) or performing daily,
incremental backups. MMUs are probably great for memory remapping and
debugging/testing, but for regular use it's a crutch that will breed
careless programming.
IMHO, among the Amiga's biggest shortcomings are not the lack
memory-protection or pre-emptive virtual memory swapping, but that memory
fragmentation which we have all been living with.
Chris – agreed about fragmentation, but…
I think it's unfair to blame a user for any program's code problems.
Also, there's just been a huge discussion about memory protection on the
Internet Amiga groups, and the one person there who claimed that it would
breed careless programming, got pretty badly beat up by those who program
on such systems 🙂
If anything, it could enhance careful programming, as more errors could be
caught and fixed sooner… in addition to protecting the normal user from
bad programs.
Note that I'll be the first to say that MP isn't necessary on a machine
where you only run fully trustworthy code. best – Kev
One should be careful and frequently save data with any new program, until
one is experienced enough with it to be absolutely certain of it's
stability (or, if necessary, how to avoid its quirks). It IS ultimately up
to the user to deal with "code problems".. read any software liscense
agreement. What's more, stability is a marketable commodity as is any other
feature; Market pressure for stability tends to disappear with the presence
of a hardware crutch.
I have never given any creedence to UseNet "discussions", and on this
particular issue, I'd say the representation is rather biased.
Chris,
I disagree for a bunch of reasons, starting with the fact that I'm one of
those people who often programs on memory-protected systems… and know
many others who do.
I assure you that the market still looks for program stability with or
without such hardware protection. Bad programming is a result of a
programmer, not of the hardware he programs on.
If someone's programs are unstable, then I'm not going to buy his stuff
whether I have memory protection or not 🙂 The only difference is that
at least with MP, his carelessness couldn't screw me up too badly. kevin
Tim – agreed on DIG desirability, but…
Memory protection wouldn't mean that message passing couldn't still be by
reference. It would only require that programs explicitly declare the
desired shared memory length and intentions of usage.
best – kevin
Which none of them do, and so you have a complete compatibility problem.
So, we better not do it, eh?
Ben
Amateur Radio Callsign is A A 7 A S
Ben – yah on current incompatability with memory protection, but I was
taking exception with his idea that a changed OS would run slower or have
worse programs if MP was added 🙂
regards – kev
Don't tell me I'm gonna have to remind everyone what MEMF_PUBLIC means. I
guess I'm the only person who reads the docs.
Vic – you should see the huge arguments right now on the internet about
what MEMF_PUBLIC means 🙂 Seems that everyone reads the docs as meaning
different things. Still waiting for a CBM type to comment 🙂 best – kev
Kevin:
Doesn't MEMF_PUBLIC just mean that the system will grab fast ram first and
then grab chip memory if it has to?
Gary
– Mirror Image Prod. (416) 495-7469, via WHAP!
I try to stay out of MEMF_PUBLIC arguments, Gary <grin>… I've seen at
least a half-dozen interpretations of it so far. Some people swear it's
for protected memory, others swear the opposite, and so on. The only thing
people do agree on, is that it's been misused one way or the other 🙂
Relenting on my own promise a bit – the manual seems to indicate (to me)
that it's memory whose logical address must not change from task to task. I
suppose in other OS's that would be considered "system global memory".
Someone mentioned a bunch of other oddball MEMF_ types in 2.0, btw. best
-kev
Kevin:
All I know is that if I don't need to use CHIP ram exclusively, I use
public. It just sounds to me that specifiying CHIP or FAST allows you be
particular (and thus protective) of which memory pools you draw from. If
you don't care, you say "public" and the system hands you whatever's
available (No techy, I! (or can you tell? :)) People actually ARGUE about
this?
Gary
– Mirror Image Prod. (416) 495-7469, via WHAP!
Gary,
Wake up and read the docs!!!!! PUBLIC means you intend to SHARE the
data with someone. If you don't care….don't use ANY flags!
Gary:
If your programs don't require chip ram, they should be written to
specifically avoid using it. The Amiga is a multitasking machine that
needs chip memory for sound & video manipulation AS WELL AS MULTITASKING.
(Or at least that's what I've been told). I assume you want as many Amiga
users out there as possible to be able to use your programs… and your
programs SHOULD be able to multitask so they can be used while running
propage, right? Well, if MIOUTLINE eats up so much CHIP ram that my
prodraw or propage can't function properly because I have only 512K of chip
ram available, then I'm gonna be upset with you. The fact is, that (once
again, as I understand it) chip ram is slower than fast ram (why do ya
think they call it fast ram, anyway?) so why not tell your programs to get
memory from where it will do the most for the program and be the least
taxing on the system.
Chip memory is currently limited to 2 meg (and few Amiga users have that
much), while fast ram is much more readily available.
Now, repeat after me "FASTRAMFIRST FASTRAMFIRST FASTRAMFIRST…" <g>
– Whapping from the North Coast Michael
Gary, and anyone else who is 'listening'.
NO, NO, NO! NO!! NO!!!
I can't _believe_ the mis-information surrounding this. MEMF_PUBLIC means
that (among other things) that the memory canNOT be 'swapped-out' or
'mapped-out' or whatever. It is MEANT for those regions of memory which
will be SHARED (err, public) between/among tasks. Memory which will be
used by interrupts must also be MEMF_PUBLIC (the memory must be available
when the interrupt occurs). One would also allocate as MEMF_PUBLIC things
like 'messages' which are going to be sent to other processes/tasks.
Vic:
Re: MEMF_PUBLIC
Gee, I guess people DO argue about this! 🙂
Since you are so adamant about this, I will assume that you are correct.
MEMF_PUBLIC means public memory. Makes perfect sense… yah…
Gary
– Mirror Image Prod. (416) 495-7469, via WHAP!
Vic,
Commodore engineering has _unofficially_ declared MEMF_PUBLIC to mean
nothing. It seems that too many programs misused it, to the point that
if-and-when an implementation change would enforce the (possible) intended
meaning, too much software would break. Consequently, if-and-when the need
arises to enforce a MEMF_PUBLIC-like differentiation, a new type-bit will
be used, and the old flags will continue to function as they currently do.
The implication is that any memory that doesn't have this "to-be-defined"
bit on must be treated as VIRTUAL=REAL.
…BobR
That is incredibly dumb. I mean, it's not like the docs are unclear or
anything. Sheesh, we're back to having the 'hot spot' on the pointer off
by a coupel pixels because someone 'wouldn't change their program when 1.1
came out. <sigh>
What this means, of course, is that all MY software will need to be
modified so that _I_ can tell the system <double sigh>
Apparently either the docs _were_ unclear to some developers or some
developers never read the docs. Be that as it may, it is unfortunate but
it would also be very unfortunate for all of us if a significant amount of
software were to break. Our market is to small to be fragmented like that
(IMHO).
…BobR
BobR,
You're right (as usual). It's depressing that there are so many
amateurs (I will define amateur as someone who _refuses_ to read the
manuals) out there writing code. Programming by experimentation is
foolish; your program will break at the next release. Then, of course, you
complain to the manufacturer (C=) that _they_ broke your program (and, more
of course, you tell the ENTIRE world that it ain't your fault.
Vic:
I think that you're getting a little elitist in your old age. 😉 Seriously,
though, it's not as cut and dried as you depict. While you and I probably
read the MEMF_PUBLIC part of the manuals and immediately got the light bulb
over the head, quite a few experienced microcomputer programmers probably
didn't. It's not necessarily their fault, they just never had any big
system multitasking experience. About 10 years ago, you couldn't even
ASPIRE to system programming without understanding how the memory
management hardware worked. Now, with micros, you can spend your entire
career without knowing how any of it works, especially on the
single-tasking machines.
I submit that the real importance of MEMF_PUBLIC was not explained well
enough in the original manuals, and that while yet ANOTHER MEMF bit makes
me cringe, you ought to maybe switch to decaf. 😉
Ariel
Vic:
I think you're being a little harsh on the "amateur programmers". While
many may be guilty of not bothering to read the documentation, a bigger
problem is Commodore's documentation or lack of it.
The documentation, (RKM's etc.), lag way behind the software. Every other
system I have worked on, the documentation is provided at the same time as
the product. This is not the case with Commodore. Many people have to play
around and see what works because they have no documentation.
I wonder how many of the current crop of 2.0 programs will actually survive
the next operating system upgrade. They are being developed with virtually
no documentation.
-=Martin=-
– via Whap!
Martin,
The point is more that _commercial_ software hasn't necessarily followed
the rules, which has caused problems when upgrading the OS, and there's
really no excuse for that. Anyone who's developing commerial software for
the Amiga has the responsibility to be a registered developer with
Commodore (IMHO) and Commodore has been pretty good about making sure that
registered developers _do_ have access to the available documentation.
Vic's absolutely right, except that unfortunately his opinion is a bit more
idealistic than the market can bear.
As for "amateur" programs breaking due to changes in the OS environment,
I feel that that can't be helped – it's just a negative side effect of the
evolutionary process. Yes, I am making a distinction between "commercial"
software being "professional" and "freely-distributable" software being
"amateur". I'm not saying that this distinction means that one class of
software is inherently _better_ than the other. In fact, there's some
wonderful and well-written "fd" software and some absolutely horrible
commercial software available. However, as a consumer, I feel I have a
right to some degree of protection for my investment in commercial
software. I don't feel that I have the same rights concerning
freely-distributable software – it's much more of a gray area.
Shareware complicates this dichotomy, but just a bit. I consider
"shareware" whose terms are "if you use this program you are obligated to
pay me for it" in the "commercial" category, which also implies the same
responsibilities on the authors of such shareware. Other "shareware" whose
terms are more liberal, such as "you can use this if you want, and you can
pay me $$$ if you want to" falls more in the second category. (again,
IMHO)
I wonder how many flames this is gonna generate! <grin>
…BobR
Martin,
The documentation for 2.0 has been available for quite a while now.
Don
See my reply to Ariel. In addition, if programs are being developed
'with no documentation' the people doing so are FOOLS. The documentation
is readily available from Commodore and has been to ANY registered
developer for quite some time.
You are right that pass by reference would still be possible, but the
program passing by reference would have to copy the necessary information
to the shared memory space before passing the pointer. This would cost a
great deal in terms of performance. Before you say it, yes you could do
all of your work in this shared area and not have to copy, but isn't that
what we already have?
Tim
KEv…
Ever think of a little hack that modifies running task priorities to walk
around, like OS9 does?
it's a thought, eh? I think everything is there to do it – give you just
what you have under OS9, though less efficient since it's not in the
(highly efficient) task manager level, but instead is another program…
or… hey – we could patch the priority handling?
Hmmm. :^)
Ben
Amateur Radio Callsign is A A 7 A S