Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1929 > unrolled thread

PLASMA has fibers

Back to article view | Back to comp.sys.apple2.programmer

Contents

  PLASMA has fibers David Schmenk <dschmenk@gmail.com> - 2015-10-26 19:21 -0700
    Re: PLASMA has fibers David Schmenk <dschmenk@gmail.com> - 2015-10-27 06:33 -0700
    Re: PLASMA has fibers D Finnigan <dog_cow@macgui.com> - 2015-10-27 15:22 +0000
    Re: PLASMA has fibers David Schmidt <schmidtd@my-deja.com> - 2015-10-27 11:33 -0400
    Re: PLASMA has fibers John Brooks <jbrooks@blueshiftinc.com> - 2015-10-27 12:56 -0700
    Re: PLASMA has fibers David Schmenk <dschmenk@gmail.com> - 2015-10-27 18:34 -0700

#1929 — PLASMA has fibers

No, PLASMA doesn't need a lint brush. But, it does get a simple form of multi-threading knows as fibers. This term was actually not known to me when I started, but there is a nice description here:
https://en.wikipedia.org/wiki/Fiber_(computer_science)

Basically, fibers are something in between co-routines and pre-emptive multithreading. They are cooperatively scheduled threads of execution that don't have the race conditions of pre-emptive threads so are conceptually easier to understand. They are a little more sophisticated than a simple co-routine, allowing multiple threads to be round-robbin scheduled; they can be halted, resumed, started and stopped.

You can find the implementation here:
https://github.com/dschmenk/PLASMA/blob/master/src/libsrc/fiber.pla

I chose fibers over pre-emptive threads due to their interdependence from the VM. By swapping about 36 bytes of zero page values and however much of the 6502 stack is used, it is easy to bounce between threads of execution without the VM being aware. I did implement pre-emptive threads in my Java VM, VM02, but it requires a hook into the opcode fetch routine. Since I had spent so much time reducing the cycle count of the PLASMA inner opcode fetch routine, I didn't want to add back another 50% of the cycles. There also needed to be hooks for the scheduler and other dependencies that I didn't feel were in the spirit of PLASMA. So, we get fibers.

You may notice that higher level thread synchronization mechanisms aren't included. They can easily be added atop the fbrHalt and fbrResume functions. Semaphores, mutexes, queues, whatever you like. Because scheduling is only done during the call to fbrYield, synchronization is drama free.

However, fibers don't come for free. You need to anticipate the maximum number of fibers you will have running at once. Space is allocated for the VM state, 6502 stack, and local frame data. In the current implementation, 256 is shared between the 36 byes of VM state and the 6502 stack, and 256 for fame data. This means you have to be a little careful about call depth and the total amount of local variables. The main fiber, the one that runs initially and allocates the fiber pool, gets to use the frame data from the PLASMA runtime, i.e. everything except code and heap. Also, you can't HALT the main fiber (to avoid deadlock).

You may wonder why I wrote this library now - let's just say I received my shipment notice for a certain Canadian networking product destined for my Apple II.

Dave...

[toc] | [next] | [standalone]

#1931

On Monday, 26 October 2015 19:21:34 UTC-7, David Schmenk  wrote:
> I chose fibers over pre-emptive threads due to their interdependence from the VM. 
> 

Note that should have read:
I chose fibers over pre-emptive threads due to their independence from the VM.

Don't post after a long day of traveling by plane.

[toc] | [prev] | [next] | [standalone]

#1933

David Schmenk wrote:
>
> You can find the implementation here:
> https://github.com/dschmenk/PLASMA/blob/master/src/libsrc/fiber.pla
>
> Dave...
>

Where's the rest of the code? ;-)
That's pretty lightweight!

[toc] | [prev] | [next] | [standalone]

#1934

On 10/26/2015 10:21 PM, David Schmenk wrote:
> No, PLASMA doesn't need a lint brush. But, it does get a simple form of multi-threading knows as fibers.

It's a dessert topping!  It's an operating system!  It's the Super 
PLASMA-O-Matic!

[toc] | [prev] | [next] | [standalone]

#1936

On Monday, October 26, 2015 at 7:21:34 PM UTC-7, David Schmenk wrote:
> No, PLASMA doesn't need a lint brush. But, it does get a simple form of multi-threading knows as fibers. This term was actually not known to me when I started, but there is a nice description here:
> https://en.wikipedia.org/wiki/Fiber_(computer_science)
> 
> Basically, fibers are something in between co-routines and pre-emptive multithreading. They are cooperatively scheduled threads of execution that don't have the race conditions of pre-emptive threads so are conceptually easier to understand. They are a little more sophisticated than a simple co-routine, allowing multiple threads to be round-robbin scheduled; they can be halted, resumed, started and stopped.
> 
> You can find the implementation here:
> https://github.com/dschmenk/PLASMA/blob/master/src/libsrc/fiber.pla
> 
> I chose fibers over pre-emptive threads due to their interdependence from the VM. By swapping about 36 bytes of zero page values and however much of the 6502 stack is used, it is easy to bounce between threads of execution without the VM being aware. I did implement pre-emptive threads in my Java VM, VM02, but it requires a hook into the opcode fetch routine. Since I had spent so much time reducing the cycle count of the PLASMA inner opcode fetch routine, I didn't want to add back another 50% of the cycles. There also needed to be hooks for the scheduler and other dependencies that I didn't feel were in the spirit of PLASMA. So, we get fibers.
> 
> You may notice that higher level thread synchronization mechanisms aren't included. They can easily be added atop the fbrHalt and fbrResume functions. Semaphores, mutexes, queues, whatever you like. Because scheduling is only done during the call to fbrYield, synchronization is drama free.
> 
> However, fibers don't come for free. You need to anticipate the maximum number of fibers you will have running at once. Space is allocated for the VM state, 6502 stack, and local frame data. In the current implementation, 256 is shared between the 36 byes of VM state and the 6502 stack, and 256 for fame data. This means you have to be a little careful about call depth and the total amount of local variables. The main fiber, the one that runs initially and allocates the fiber pool, gets to use the frame data from the PLASMA runtime, i.e. everything except code and heap. Also, you can't HALT the main fiber (to avoid deadlock).
> 
> You may wonder why I wrote this library now - let's just say I received my shipment notice for a certain Canadian networking product destined for my Apple II.
> 
> Dave...

This compiler discussion may be relevant to your interests:

RPN/TAC/SSA on 8-bit

https://groups.google.com/forum/#!topic/comp.compilers/fCeYHRTnLvU

-JB

[toc] | [prev] | [next] | [standalone]

#1938

If you want to play with fibers without installing the build system, I created an example for the PLASMA SANDBOX. Download the disk image here:

https://github.com/dschmenk/PLASMA/blob/master/SANDBOX.PO

Read in EX.16.PLA and execute. It is a stripped version of one in libsrc so it could fit in the limited SANDBOX memory (the SANDBOX can't load modules, so all the code has to be resident). Don't expect to play a lot, but at least you can. Notice how I loaded the machine language routines as data arrays that get called. No limits in PLASMA ;-)

Dave...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web