From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-04-21 09:57:19
On Wed, Apr 20, 2005 at 10:22:42PM +0200, fachat wrote:
> > Errrrrrrrrrr ... you're right, thanks ;-) But my problem is: if I have
> > a process and creating a thread, than maybe I will use the same zero page
> > locations (eg it's a cc65 compiled software using zero pages) so they
> > will disturb each other, doesn't it?
>
> If both threads are running the same code, yes. In general the zeropage
> must be considered as "static global" process variables, and are thus
> shared and accessible by all threads similar to such variables in C.
> If you want thread-local variables, they must be created "on the heap",
> i.e. local variables in C. So you cannot use zeropage adressing there,
> only indirect indexed. If cc65 handles this I don't know, Uz?
Well, this IS the problem. If I allocate zero page locations sure, I must
take care about them. But if cc65 compiled program uses some zp locations
for internal purposes we have a problem, since it is not the our decision
to use a zp location or not but the compiler's. I think this because FAQ
at cc65.org says about the problems of writing interrupt handler in C:
"As any non trivial 6502 program, the code generated by cc65 makes use of
the zero page. Zero page locations are also used for the argument stack,
and as temporary storage for most of the runtime support functions. So
when writing interrupt handlers in C, it is necessary to save the CPU
registers plus these zero page locations."
This means, we can't implement threads easily with cc65 ;-[
> IIRC I have in OS/A65 a "thread context pointer" of
> two bytes that are in the zeropage and that are swapped together with
> the thread, and not the process. I.e. when there is a context switch between
> two threads in the same process, those two bytes are swapped.
> I think I used this to implement the
> lib6502 in a threadsafe way (the lib6502 implementation handles a
> thread-specific context and uses the "thread context pointer" to address
> the data in the context.
Note that my ideas implementing threads were inspirated by clone() syscall
of Linux kernel. It was (is?) used to implement both of eg fork() and let's
say pthread_create(), just vith CLONE_VM flag, to declare that child should
share the memory context (type "man 2 clone" on a GNU/Linux system if dev
man pages are installed at least).
>
> So all threads use the same code and still the code is thread safe :-)
>
> > > The advantage of your scheme is that you could have a common mapping of
> > > the zeropage for all
> > > threads in a processes, but each thread could have its own stack
> >
> > You can do it as well, if you have another mapper just for stack (addresses
> > between $100 and $1ff). So in your project you have 4K length pages but with
>
> Well yes, but I would still have to solder that stuff together - which is
> complicated if you don't use programmable logic.
Hmm, I've thought such a design with a separated SRAM: address input lines
of SRAM is the page number to look up, and the read value from the memory
will be the mapped address. Unfortunatelly I don't know how can you MODIFY
the mapping table without mess up the whole simple design. And the timing
... :)
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.