jdj@munsell.UUCP (Joel Jennings) (08/19/88)
Hello to everyone from a new reader.
I am looking for a way to cause my program to take an exception periodically
so that it can write out intermediate results of a long calculation* (see
below). Essentially, I would like something similar to the Unix
'signal(SIGALRM,save_rtn)' function, so that every 10 minutes or so my
program can checkpoint where it is in the calculation in case the system
crashes. Upon rebooting, I can reaload the checkpoint info and continue
from there with no more than 10 minutes or so lost.
1) I have references in one of my manuals to a "SigExcept" function,
which looks to be exactly what I need. Unfortunately, there is
no definition of the function, its arguments, return codes, etc
in that manual, nor is there one in my ROM kernel manuals.
Furthermore, there is no entry in any of my libraries or include
files for this function. If this is what I need to use, can anyone
tell me where to find the subroutine description and directions
on how to use it?
2) That same manual in #1 refers to entries in the task structure named
"ExceptCode, ExceptData, and <signals-we-take-exceptions-for>. I
have tried putting the address of my routine there and stuffing the
signal mask of the (to be delivered) timer message into the signal
area, but this doesn't seem to force a subroutine call when the
message is delivered. I can block for the message, but the routine
is never called. Do I need any more steps to set this up? (This
is a hack and I would rather use a system supplied routine.)
3) Worst comes to worst, I have been considering running a separate
timing task which has received a message from the calculation task
containing (ready for this?) the address of the calculation data.
After receiving the data address, the calculation task can loop on
a 10 minute wait writing out the *other* tasks data. Since the Amiga
is a true timesharing machine, the calculation task will be running
while the timing task waits. This is a very bad solution. Can anyone
suggest a better idea?
----------------------------------------------------------------------------
*: Explanation of long calculation follows - hit 'N' if you don't care,
I don't use my Amiga much of the time (like, when I'm asleep or at work),
and so I thought I'd put it to work discovering the secrets of the universe
while I'm not there. Specifically, I wanted to find the next minimum golomb
ruler (I think that would be 14 marks, but I don't have my notes with me
right now). A golumb ruler is a ruler with N marks on it (each mark an exact
number of inches from the first mark, which is at 0 inches) such that the
distance between any two marks is not duplicated between any other two marks.
For example, a golumb ruler with two marks has marks at 0 and 1. It can
measure one distance: 1.
A golumb ruler with 3 marks has marks at 0, 1, 3. It can measure 3
distances: 1, 2 (the difference between 1 and 3), and 3.
A golumb ruler with 4 marks has marks at 0, 1, 3, 7. It can measure 6
distances: 1, 2, 3, 4 [7 - 3], 6, and 7.
A minimum golomb ruler with N marks is the shortest such ruler. As shown
in the 3rd example, not every distance need be available, as long as there
is not two ways to make any of the distances.
Time calculations indicate that to find all minimal rulers of N marks
takes 10 times the amount of time to find all rulers of
N-1 marks. In order to push back the envelope of current knowledge about
golomb rulers to beyond 14 would take 412 straight days of computing time.
The AC *LINE CURRENT* in my apartment won't stay up that long without
interruption, much less an Amiga with a (gasp!) hard disk. Any attempt to
put systime/checkpoints in the code would only make the calculation run much
longer.
(Anyone out there know where I can get access to 10 Amigas for 1.5 years
to find all rulers of length 15? :-)
--
Joel Jennings | Wampeters, foma, and granfaloons.
| dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/19/88)
:Hello to everyone from a new reader. : :I am looking for a way to cause my program to take an exception periodically :so that it can write out intermediate results of a long calculation* (see :below). Essentially, I would like something similar to the Unix ... : 3) Worst comes to worst, I have been considering running a separate : timing task which has received a message from the calculation task : containing (ready for this?) the address of the calculation data. The latter, using a separate process, is exactly how you want to do it. Unfortunetly, AmigaDOS handlers are not setup properly to handle multiple requests from the *SAME* process at the same time, so you can't really trust a DOS library call from an exception handler. Also, exceptions are a bitch. In anycase, to be able to make DOS calls you need a process, so use CreateProc() to startup a watchdog process and the timer.device to make it wait in intervals of (whatever)... then use a simple locking mechanism between the two processes so the data isn't in the middle of being updated while the watchdog proc is writing it to disk. CreateProc() takes a segment rather than a simple pointer. This can be easily faked. Even better though, compile the watchdog process separately from the master process so you can simply LoadSeg() it (and get the segment needed for CreateProc())... again, a simple signalling mechanism can be used to sync up the two processes. Faking a segment is easy. Essentially, a segment is a BPTR to a segment, so to fake one we just apply reverse engineering: StartPC = (segment << 2) + 4 segment = (StartPC - 4) >> 2, where StartPC MUST be on a longword boundry. The first four bytes of the segment (the four bytes below the startpc) should be 0. Apart from that, you only have to worry about sharing non-runtime library routines. I.E. you can't use STDIO or malloc() in both processes when they use the same LINK library (if you make the second a separate executable this isn't a problem). However, all the run-time libraries like intuition, exec, and dos are by virtue sharable. If the second process is another executable, I usually do not use the standard main() entry point since the arguments will be garbage, but use _main() instead. -Matt
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/20/88)
In article <1754@munsell.UUCP> (Joel Jennings) writes:
->I am looking for a way to cause my program to take an exception periodically
->so that it can write out intermediate results of a long calculation* (see
->below). Essentially, I would like something similar to the Unix
->'signal(SIGALRM,save_rtn)' function, so that every 10 minutes or so my
->program can checkpoint where it is in the calculation in case the system
->crashes. Upon rebooting, I can reaload the checkpoint info and continue
->from there with no more than 10 minutes or so lost.
The easier way to do this is with a Signal since it has little overhead
and you can access it easily, plus you don't run into some of the "where
were you" problems of exceptions. Essentially, let your calculation loop
check for a signal every time it goes through the loop. If it see's a
^C it should exit, if it sees a ^D is save it's data, if it sees a ^E
maybe it should pause, etc. Look at the documentation on SetSignal() in
the RKM's or with your C compiler. The timing task could be as simple as
an execute script like this :
.LOOP:
WAIT 600
BREAK <your_cli_process> D
SKIP LOOP
-> I don't use my Amiga much of the time (like, when I'm asleep or at work),
->and so I thought I'd put it to work discovering the secrets of the universe
->while I'm not there. Specifically, I wanted to find the next minimum golomb
->ruler (I think that would be 14 marks, but I don't have my notes with me
->right now). A golumb ruler is a ruler with N marks on it (each mark an exact
->number of inches from the first mark, which is at 0 inches) such that the
->distance between any two marks is not duplicated between any other two marks.
See Dave Garber's thesis on synthesis of natural textures using stochastic
(sp?) models. (University of Southern California, Image Processing Institute)
We calculated golumb rulers up to 24 or 26 using a DEC-20 and a really
tight assembly language algorithim. (It would make a good benchmark I think)
We started with an HP-2100a and were displaying the rulers on the lights
as we calculated them. When we got one we would print it out on the
line printer.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.morgan@brambo.UUCP (Morgan W. Jones) (08/21/88)
In article <1754@munsell.UUCP> jdj@munsell.UUCP (Joel Jennings) writes: >I am looking for a way to cause my program to take an exception periodically >so that it can write out intermediate results of a long calculation* (see I'm rather new to programming the Amiga, but have been looking at the interrupt system. One approach that seems reasonable would be to send a message to the timer.device asking it to send you a message in ten minutes (600 secs). Arrange that the reply port that it sends to generates a software interrupt of priority higher than your program (so that it preempts it), and this swi can delete the message, ask that another message be sent in ten minutes, and write out your intermediate data. Of course, you'd have to make sure that a swi can do things like delete messages, send messages, open files, etc. How's that sound? "Anyone? ... Anyone? ..." >Joel Jennings | Wampeters, foma, and granfaloons. -- Morgan Jones morgan@brambo.UUCP ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan Starting at HCR on monday.
rminnich@super.ORG (Ronald G Minnich) (08/22/88)
In article <413@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes: >One approach that seems reasonable would be to send a message to the >timer.device asking it to send you a message in ten minutes (600 secs). Hmm, we have a very nice OS here with a shared address space and named blocks of memory and lightweight tasks and .... we are still thinking in terms of Unix. How about (let's be gross now) run your compute process. Have it write the adress of the data to a file called "data". Then run another process that counts down ten minutes, opens the file to get the address, looks at the data, and prints out information about it. Alright, less gross: Your program spawns another program with the arguments that tell it where to look and how often and what to print. That second program opens a window to talk to you. Or, maybe: Spawn a lightweight process (task is such a better word, but Mach kinda changed the meaning). Since it shares your context it *knows* where to look and how often to print. I am lying maybe since i have not done much with tasks. Can someone flesh this one out? Or, ... , well there are a million ways to do this. Let your compute task do computing, not waste time talking to you. Let some other task talk to you. Then you are using some of the Amiga's many neat ideas. On unix you HAVE to have the signal cause sharing data in memory is so damn hard. On amiga sharing (even unintentional) is the easiest thing. Many processes can easily share an array. So why not do it, and save yourself the trouble of having signal handlers and such? I'll tell you, its a nice world there in your Amiga. I like it, myself. ron
morgan@brambo.UUCP (Morgan W. Jones) (08/25/88)
In article <632@super.ORG> rminnich@metropolis.UUCP (Ronald G Minnich) writes: >In article <413@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes: >>One approach that seems reasonable would be to send a message to the >>timer.device asking it to send you a message in ten minutes (600 secs). > Hmm, we have a very nice OS here with a shared address space and >named blocks of memory and lightweight tasks and .... > we are still thinking in terms of Unix. > >How about (let's be gross now) >run your compute process. Have it write the adress of the >data to a file called "data". Then run another process >that counts down ten minutes, opens the file to get the >address, looks at the data, and prints out information about it. >Alright, less gross: >Your program spawns another program with the arguments that >tell it where to look and how often and what to print. That >second program opens a window to talk to you. >Or, maybe: >Spawn a lightweight process (task is such a better word, >but Mach kinda changed the meaning). Since it shares your >context it *knows* where to look and how often to print. Somebody forgot their Operating Systems course, eh? The problem with all of these approaches, of course, is that you've got two processes reading the same data at the same time, or, more specifically, one reading the data while the other is still writing. Naturally, you could use semaphores or some other sort of locks to make sure that this doesn't happen, but that would be a rather silly solution since the processes would never execute concurrently. Any solution that requires two processes is a kludge at best because of the locking/concurrency problem, unless you could guarantee that the data can be divided into chunks that are mutually exclusive so that you could guarantee valid data (actually I guess that you only need to guarantee that the transactions are serializable). Plus, if you use software interrupts your code has a better chance to work under the 1.4 vm (yes, folks, it's that time [to think about the next os]). >ron -- Morgan Jones morgan@hcr.UUCP Human Computing Resources, Toronto, Canada "BMATH - 8 months and counting ..."
rminnich@super.ORG (Ronald G Minnich) (08/26/88)
In article <414@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes: >Somebody forgot their Operating Systems course, eh? >The problem with all of these approaches, of course, is that you've >got two processes reading the same data at the same time, or, more >specifically, one reading the data while the other is still writing. Seems like you might need to actually use this sort of system for a while before you understand it. I can't see why this is so hard for people to get. No, this is NOT A PROBLEM. You have a single writer, single reader. The variable relating to DONENESS will INCREASE SLOWLY AS THE COMPUTATION PROCEEDS. YOU CAN LOOK AT IT AT ANY TIME! PEOPLE DO THIS SORT OF THING ALL THE TIME!!! AMAZING, HUH? The writer is the compute process. the reader is the 'front panel'. Think a little bit before you comment. Or get a little experience with this sort of thing before you comment. Or don't comment. Seems that your level of knowledge does not extend much PAST an operating systems course! Or, try again, NO, YOU DON'T NEED SEMAPHORES FOR THIS PROBLEM!!!! Get it? ron
rminnich@super.ORG (Ronald G Minnich) (08/26/88)
>In article <632@super.ORG> rminnich@metropolis.UUCP (Ronald G Minnich) writes: >>How about (let's be gross now) ^^^^^^^^^^^^^^^^^^ And I Meant Gross- Get It? You know, one gets the feeling that one's messages are not being read well. What would Miss Manners think? Look, those of you that haven't, take a look at any available amiga device driver. What you will begin to see is that the amiga rom kernel is built around the idea of your basic message-passing model. But what is passed in the messages? data structures with pointers in them! An idea central to the Amiga is that an address in any tasks address space is not a virtual address but a physical memory address. That means that you can hand a pointer off to another task and it will be valid in THAT tasks's address space. There is a nice term for this- which i have just forgotten, damn it- but the Sprite machine being built at Berkeley uses this idea. It is nice. The point is, yes on Unix to get state information out of a process you really need to use signal(). On the amiga, there are better ways to do it, that involve standard mechanisms (e.g. PutMsg or something else), that result in a much nicer design. And the basic heart of the nicer design is the fact that you can share memory easily. You don't need to do mmap() or some other ugly thing. And yes, of course, if you have more than one variable you start to get into the need for semaphores. Guess what. The amiga has very nice Semaphore calls that work! So USE THEM. Big Deal. My main point is that we should not take a problem-solving methodology that applies to Unix and drop it right onto the Amiga. There are in many cases ways to do things on the Amiga that are BETTER than their counterparts on Unix. USE THEM. Two-message-long-flame-off. ron
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/28/88)
:available amiga device driver. What you will begin to see :is that the amiga rom kernel is built around the idea of your :basic message-passing model. But what is passed in the messages? :data structures with pointers in them! An idea central to the Amiga :is that an address in any tasks address space is not a virtual :address but a physical memory address. That means that you can hand :a pointer off to another task and it will be valid in THAT tasks's address :space. There is a nice term for this- which i have just forgotten, :damn it- but the Sprite machine being built at Berkeley uses this idea. :It is nice. Yes, this *IS* a nice idea. For instance, with a 68020 one has a 4 gig address space. After all, even for virtual machines (for example, UNIX) the swap space is usually no where near that size. There are SOME machines out there with >4gig virtual memory but frankly these can be ignored for our purposes. A memory-managed linear address space of 4 gig for an entire machine is a nice concept that works well in most of today's computers. It simplifies design of the OS, sharing memory... everything. Any ever try to count the number of calls to the Virtual->Physical address conversion subroutine there are in UNIX? And for tomorrow? Tomorrow's microprocessors will have more than 32 bits addressing so we still have no problem... a 16gig or 32gig address space instead of 4, etc... For the Amiga and todays computers there are two disadvantages to such a scheme. For a virtual process in the UNIX scheme, data can be placed starting at low (<64K) addresses and thus the word absolute addressing mode can be used. Also, fork()ing would be more difficult (but fork()ing is a UNIX concept and frankly I've never been held up by the Amiga's inability to fork()). Most people use the small memory model anyway which means the word addressing mode isn't much of an advantage. Gosh, I just shot down the two disadvantages! -Matt
fnf@fishpond.UUCP (Fred Fish) (08/28/88)
In article <8808272322.AA03740@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >: [somebody besides Matt writes] >: An idea central to the Amiga >:is that an address in any tasks address space is not a virtual >:address but a physical memory address. That means that you can hand >:a pointer off to another task and it will be valid in THAT tasks's address >:space. > Yes, this *IS* a nice idea. Personally I think this is the single biggest problem with the Amiga. For a process running in a multitasking environment, it is akin to living in a society where it is perfectly acceptable for strangers to walk up to you at any time and stick their fingers in your mouth to examine your teeth. There is absolutely no concept of enforced privacy between processes. This is why you have so many mysterious cases of "when I run program XXX with program YYY, just after running program ZZZ with hardware AAA installed, the machine gurus... sometimes". The flakiness is not due to incompetent programmers. Everybody's programs have bugs in them, many of which will happily trash memory that doesn't belong the them. However, on the Amiga, these problems will often go unnoticed or unresolved for months or years, while on most Unix systems they will cause a core dump the first time they occur, and get promptly fixed. I think the Amiga is one of the most interesting computers ever made. But it sorely needs memory management hardware and an operating system that exploits it fully, for virtual memory and interprocess protection. -Fred -- # Fred Fish, 1346 West 10th Place, Tempe, AZ 85281, USA # noao!nud!fishpond!fnf (602) 921-1113
morgan@brambo.UUCP (Morgan W. Jones) (08/28/88)
In article <657@super.ORG> rminnich@metropolis.UUCP (Ronald G Minnich) writes: >Seems like you might need to actually use this sort of system >for a while before you understand it. I can't see why this is >so hard for people to get. >No, this is NOT A PROBLEM. You have a single writer, single reader. >The variable relating to DONENESS will INCREASE SLOWLY AS THE >COMPUTATION PROCEEDS. YOU CAN LOOK AT IT AT ANY TIME! >PEOPLE DO THIS SORT OF THING ALL THE TIME!!! AMAZING, HUH? >ron Geeze, take a downer, Ron, it really isn't taking a fit over. And why don't you try reading the original message instead of people's reply to it. The person doesn't want to know how far along the computation is, he wants to save a checkpoint. Since this would be changing at the same time as it was being saved, YOU DO NEED CRITICAL SECTION PROTECTION. BTW, reading the "variable relating to DONENESS", as you put it, can only be read without CS protection if it is something that can be read in one machine instruction. If the value was a float you'd have to make sure that it wasn't updated while you were reading it. -- Morgan Jones morgan@hcr.UUCP Human Computing Resources, Toronto, Canada "BMATH - 8 months and counting ..."
rminnich@super.ORG (Ronald G Minnich) (08/29/88)
In article <125@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes: >In article <8808272322.AA03740@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>: An idea central to the Amiga >>:is that an address in any tasks address space is not a virtual >>:address but a physical memory address. That means that you can hand >>:a pointer off to another task and it will be valid in THAT tasks's address >>:space. >> Yes, this *IS* a nice idea. >Personally I think this is the single biggest problem with the Amiga. For Fred, i think if you think about it you are confusing the virtual address model with memory protection. I was wondering when i wrote that if this would come up. The Sprite system has protection, but it also has the 'big linear space' model. That is, on Sprite, all addresses in every tasks space are also valid in every other task's space. That means that passing memory handles around is no big problem. mmap() is easy, consisting only of the need to give a task access to a page, not also munge page table entries for that task. To put it another way, on Unix every processe's address 0 is at a different physical place. On Sprite and Amiga, they are all at the same physical place. On Sprite and Unix, there is protection. Amiga has done all the work to get a Sprite-like memory management done. All they need do to finish the job is put on an MMU, and then they have protection. But amiga went the right direction. Contrast this to the unprotected 8086 systems wherein Unix ports maintained the virtual address mapping via the cs, ds, es, and ss registers. On the 8086 Unix ports, every processes' address 0 was again at a different physical place, and there was no protection. So, to sum up, Large linear address space DOES NOT imply no protection. But, amiga has half the job to a good system- they have the large linear space, they have done all the right things to support it, and the move to protection should be easy. Clear as mud, right? well if i am still confusing things write to me and i will try to be coherent. ron
rminnich@super.ORG (Ronald G Minnich) (08/29/88)
In article <416@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes: >Geeze, take a downer, Ron, it really isn't taking a fit over. Downer taken and i apologize. But try to cut the stuff about 'somebody hasn't taken the OS course'. It's rude.Or at least learn to use a :-) Anyway, my letter was basically inexcusable. My excuse is, i was on one of these starvation things you have to do for a blood test. So i tried to eat my terminal for lunch. it tasted great. :-) ron
brianm@sco.COM (Brian Moffet) (08/30/88)
In article <125@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes:
%
%I think the Amiga is one of the most interesting computers ever made.
%But it sorely needs memory management hardware and an operating system
%that exploits it fully, for virtual memory and interprocess protection.
%
%-Fred
yeah!!!!! me unix caveman wants vertual memry. me unix cavemane
wants protecshun for me memory.
:-) :-)
seriously. I do.
--
'Evil Geniuses for a Better Tommorrow!'
My opinions do not in any way reflect those of my employer or my fish.
Brian Moffet brianm@sco.com {ucscc,uunet,decvax!microsof}!sco!brianm
-or- (home machine, an amiga) {ucscc,uunet,decvax!microsof}!sco!orac!brianeachus@mitre-bedford.ARPA (Robert Eachus) (09/01/88)
In article <125@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes: >In article <8808272322.AA03740@cory.Berkeley.EDU> (Matt Dillon) writes: >>: [somebody besides Matt writes] >>: An idea central to the Amiga >>:is that an address in any tasks address space is not a virtual >>:address but a physical memory address. That means that you can hand >>:a pointer off to another task and it will be valid in THAT tasks's address >>:space. > >> Yes, this *IS* a nice idea. > >Personally I think this is the single biggest problem with the Amiga. For >a process running in a multitasking environment, it is akin to living in >a society where it is perfectly acceptable for strangers to walk up to you >at any time and stick their fingers in your mouth to examine your teeth. >There is absolutely no concept of enforced privacy between processes. Fred (and many other people, but not Matt :-) are confusing virtual address spaces (not virtual memory) with memory management. AmigaDOS 2.0 (or some such) will probably provide memory management (assuming that you have a 68020 + 688851 or a 68030 or ...) such that all memory not declared MEMF_PUBLIC cannot be read or written by other tasks, etc. This is a not a difficult job. AmigaDOS 2.0 might also provide virtual memory, such that not all valid memory addresses are mapped to hardware memory. (Again not too difficult. Memory requested as CHIP memory, of course cannot be made virtual, and some DMA disk controllers would need to be made smarter, but overall not too bad.) HOWEVER, to add virtual address spaces to KickStart/AmigaDOS would be a messier project than replacing MS-DOS with OS/2! (And it would sell about as well because it would be at least as fat and slow.) This is not a blanket condemnation of virtual address space systems. Many such OS's (but not all) on mainframes work well and don't impose major burdens on users. (For example, many versions of Unix on VAXes.) Some, such as Multics, even provide low cost interprocess memory sharing. But such systems don't belong on desktops. In single-user multitasking systems, unlimited address space (as opposed to a finite but large address space) is not worth the pain and agony. To sum up: Adding memory management to AmigaDOS will be a win (and MEMF_PUBLIC is just one feature present NOw to make the eventual move less painful), but it will require a hardware MMU. Adding virtual memory also requires an MMU, and could be done at the same time as the above, but I'm not sure how important it will be. (I'm typing this on an Amiga 2000 with 5 Meg of RAM and a 40 Meg Hard Disk. If I had VM, I'd probably use a (880K) floppy as the backing store. With 5 Meg or 20 Meg removables, I'd find it much more interesting.) Adding virtual address spaces to AmigaDOS would be a big mistake under any circumstances. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
jdj@munsell.UUCP (Joel Jennings) (09/01/88)
[Offering to the great line eating god - may it serve you well...]
"I am looking for a way to cause my program to take an exception so that
it can write out the intermediate results of a long calculation..."
Thanks to everyone who mailed/posted answers to my inquiry about checkpointing
a processing task. The current scorecard reads as follows:
1) I can poll for some external signal (CheckAbort() seemes to be best)
and write out results when the signal arrives. Generate the signal
with another CLI spawned task.
[I knew this. This method is not what I want to do, since my "loop"
executes a quingigillion* times for each problem.]
2) Determine algorithmically (as in "count the number of iterations")
the appropriate time in the loop to put checkpoint code.
[Again, unsuitable unless absolutely necessary. See answer to #1.]
3) I cannot use software or hardware interrupts, since I won't be able
to do anything useful during an interrupt.
[I agree - whoever wrote this section of the OS must have failed
or forgotten their intro to OS course.]
4) I can use an external process to checkpoint the calculation process
by having the calculation process send the checkpoint process the
address of the calculation data. Generating an external process,
however, is cumbersome.
[A tolerable solution, but messy! Having shared data is very poor
style, and leads to bugs. May be necessary in this case, though.]
[This particular problem does not need synchronization between the
two tasks. In the general case, semaphores (or something) would
be needed, and solution #1 would probably be faster.]
[Actually, I would have generated the checkpoint process from the
CLI and have the two processes communicate via a public message
port. This seems a lot cleaner than trying to generate one
process from within another. Or am I missing something?]
5) I can setup an exception handler for the timer message: when the
message is delivered, my process will be interrupted and forced
to call the specofied routine.
[Just what I was looking for (my thanks go to Bill Kinnersly!).
Howcome this isn't mentioned in the documentation?]
*Quingigillion: The number of miles from the electric monk to Salt
Lake City, Utah.
--
Joel Jennings | Wampeters, foma, and granfaloons.
| jesup@cbmvax.UUCP (Randell Jesup) (09/02/88)
In article <39432@linus.UUCP> eachus@mitre-bedford.arpa (Robert I. Eachus) writes: > Fred (and many other people, but not Matt :-) are confusing >virtual address spaces (not virtual memory) with memory management. >AmigaDOS 2.0 (or some such) will probably provide memory management >(assuming that you have a 68020 + 688851 or a 68030 or ...) such that >all memory not declared MEMF_PUBLIC cannot be read or written by other >tasks, etc. This is a not a difficult job. Not difficult?? Not difficult, he says. Maybe HE'D like to make this work with all those programs that misuse/don't use MEMF_PUBLIC? Also, even non-MEMF_PUBLIC memory may well still have to be readable, at least for old programs. Not to say it can't be done, but just that it's still a sizable can of worms. > Robert I. Eachus > >with STANDARD_DISCLAIMER; >use STANDARD_DISCLAIMER; >function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is... So when are you porting Ada to the Amiga? :-) -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
bmacintyre@watsol.waterloo.edu (Blair MacIntyre) (09/03/88)
In article <4639@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <39432@linus.UUCP> eachus@mitre-bedford.arpa (Robert I. Eachus) writes: >> [ about memory protection ... ] > > Not difficult?? Not difficult, he says. Maybe HE'D like to >make this work with all those programs that misuse/don't use MEMF_PUBLIC? >Also, even non-MEMF_PUBLIC memory may well still have to be readable, at >least for old programs. Not to say it can't be done, but just that it's >still a sizable can of worms. I agree it's a hell-of-a job, but why not treat it the same way as the problem of programs not allocating CHIP memory correctly ( you remember, back in the old days when 512K was alot :-) of memory ). Wouldn't it be possible to have a program that worked the same way ATOM worked with the conversion to fast memory? And if the programs still don't work, tough!!!! If the companies that wrote them aren't far-sighted enough ( actually, if they are just not-near-sighted :-) they should be looking out for something like that ... Of course, it's the customer that suffers, but if someone buys one of these new machines ( or the new version of AmigaDOS or whatever it takes ) they will have to be aware of the fact that some of their older programs might not work. I mean, hell, I still have a 1000 and I'm all for you guys going full ahead and making these new machines as good as possible. I won't be buying another machine until it has memory protection anyway ... I'd really rather it be a 68020/68030 Amiga with lots of amazing (not necessarily compatible) graphics capabilities ... >-- >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = Mr. Blair MacIntyre (bmacintyre@watsol.waterloo.edu) = = < this space closed for repairs ... > = = Opinions? What are they? Are they expensive? Where can I get one? =
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/03/88)
In article <39432@linus.UUCP> eachus@mitre-bedford.arpa (Robert I. Eachus) writes: > AmigaDOS 2.0 might also >provide virtual memory, such that not all valid memory addresses are >mapped to hardware memory. (Again not too difficult. Memory >requested as CHIP memory, of course cannot be made virtual, and some >DMA disk controllers would need to be made smarter, but overall not >too bad.) This would have some serious ramifications to device drivers. Any interrupt-driven driver, for example, would have to be treated specially so that all of its code, data, stack, and I/O buffers would always be resident. An inherent characteristic of Exec's I/O system is that I/O is message based, and there is no distinction whether a message will be handled/replied to by another process, an interrupt, or some combination. There is actually very little that distinguishes device driver code from "user" code, and under the current system, any program may suddenly decide to make itself a "device driver" by creating a device node and starting to handle I/O reqests. If its operation requires real-time response to hardware events, it must never be out of memory. Also, there are Exec functions like AddIntServer() which cause some code and data of the calling program to be referenced/executed at interrupt time. Somehow, the O.S. would have to be told that these data areas must never be paged. Most of the above problems are just special cases of a more general statement: Amiga Exec is a REAL TIME operating system. I think it would actually be easier to add real-time capability to Unix than it would be to add virtual memory to Exec/AmigaDOS in a way consistent with their design philosophy. One way to reduce the problem would be to add YAAF (Yet Another AllocMem Flag): MEMF_PHYS(?) which would return memory that would never be paged. Then, another flag in object hunks would be needed, and an option to fixhunk, etc.... > HOWEVER, to add virtual address spaces to KickStart/AmigaDOS >would be a messier project than replacing MS-DOS with OS/2! (And it >would sell about as well because it would be at least as fat and >slow.) I don't see any reason why that should be so. Virtual-to-physical address translation doesn't necessarily take any more time than access protection and it doesn't increase memory usage (except perhaps for the code to implement it). If by "fat" you mean "encouraging development of memory-hungry software" that has nothing to do with address translation. > In single-user multitasking systems, unlimited address space >(as opposed to a finite but large address space) is not worth the pain >and agony. There's no such thing as unlimited address space. Since (as far as I can follow your message) we are talking about virtual address space, not virtual memory, the only difference would be that two processes could have their memory at the same address. This does not change the size of the address space, it only changes which parts of it are available. Virtual address translation could add several important benefits to the Amiga, including shared/reusable code (without having to use special compilers and programming methods). > To sum up: > Adding virtual address spaces to AmigaDOS would be a big mistake >under any circumstances. I disagree. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
limonce@pilot.njin.net (Tom Limoncelli) (09/04/88)
Boy, I really hate to say this. I am an amiga.fan more than anyone
else I know but recently I read "Inside OS/2". It gives a real good
view of the philosopy of OS/2 and it is a programmers-only book.
The way they designed the memory allocation system is (arrgh! am I
actually posting this?) really quite nice.
The only change that would be needed to amiga-ize OS/2's MMU structure
would be to replace the word "segment" with the phrase "hunk of
memory allocated with AllocMem". Then, MEMF_CHIP would be memory that
can't be swapped out and would have the same physical address as it's
vurtual address.
The OS could detect an older machine (without an MMU) and
automatically do the same memory allocation functions just without
memory protection.
The conversion from old-programs to new-programs wouldn't be too bad.
Old programs could be 100% unprotected and possibly they could be
given privs to read any memory location. This is a big hole in the
system but providing upward compatability... well, hopefully someone
would come up with a better method to do that. :-)
If it were optional to allow old programs to modify other's memory
programmers would have a easier time of converting old code.
--
Tom Limoncelli -- Drew University, Box 1060, Madison, NJ 07940
TLimonce@Drew.Bitnet -- limonce@pilot.njin.net -- VoiceMail (201)408-5389
Drew College of Liberal Arts: male/female ratio: 2:3 student/pc ratio: 1:1
"The opinions expressed are mine... just mine."