From: Gábor Lénárt (lgb_at_lgb.hu)
Date: 2005-04-21 15:46:06
hello! On Thu, Apr 21, 2005 at 03:18:24PM +0200, Baltissen, GJPAA (Ruud) wrote: > Hallo Gabor, Errr, what is your forename? Ruud or Baltissen? Sorry but it always a problem for me, because in Hungarian I would write my name as "Lénárt Gábor", however eg English uses the opposite order "Gábor Lénárt", but scheme like "Lénárt, Gábor" is also used eg in English which is exactly the same order as the Hungarian and we even don't need comma here :-) > > I was writing about a theoretical system not a C64 ;-) > > I know, I only used it as an example to emphasize the need of saving the > contents of various registers. And the I/O port is a good example IMHO. > Saving the contents of the SID or VIC in a multi-tasking enviroment is less > obvious. Yep. For a hardware like Commodore 64 it would be simply to complicated to share eg SID between multiple processes (like allocate one channel for a process ;-), but we can also declare, that using eg SID can be done only by one process at a time. Eg if we virtualize SID access via a file, like /dev/sid ;-) than opening it by a process make /dev/sid unopenable ("file is busy" or something) by other processes. In this way, there is no direct hw access for processes just for the kernel! Communication can be done with standard file interface - no direct hw access -. This was the UNIX way: virtualize everyting as "file" at least from the view point of user programs. In this way the communication only means file operations. Sure, for slow systems it can be dangerous since the overhead of this 'virtualization' (I mean, file operation should be done it should be processed by the kernel etc, while - let's say - for real it would be only some LDA/STA pair to set some registers in SID). So care must be taken! > > I mean if a memory area is write protected, .... > > Ah, good idea! > > > > Even the read can be denied by simply eg read always > > zero if page is not readable by a process. > > Even better! And zero is the code code for BRK which means that even an > illegal jump is intercepted. I really learned some nice things today :) Nice, however we can't do nice tricks can be done eg with an i386 CPU: on page fault, OS would emit segmenation fault signal to the process. Without installed signal handler it simply kill the process. However if process have installed handler, it can get detailed information about the fault and it can even react to it. It is because the 6502 has not support to abort the processing of a single opcode ... Btw what about 65816? - Gábor Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.