[CSDb] - User Forums - Some sort of multithreading.

Welcome to our latest new user Coinoperator ! (Registered 2024-06-17)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Some sort of multithreading.

2008-04-08 22:51

gregg
Account closed

Registered: Apr 2005
Posts: 56

Some sort of multithreading.

About a week ago the topic multithreading came up on #c-64. So today I gave it a try. However, there's something wrong with my code and I can't really figure out what it is.

A short description: I have a fixed number of threads running and a CIA IRQ deals with context switching in a round-robin fashion. Every IRQ I save all current state data (SP, status register, PC, A, X, Y) in a structure and fetch the state data for the next thread.

In this example the first thread increments the screen background color (fast), while the second thread changes the border background color (slow). However the wait in the second thread runs too fast every other time, and I have no idea why. It's probably something wrong with the context switch stuff, maybe some of you could take a look at it?

Sources are for ACME.

!to "threading.prg",cbm
!cpu 6510
;!source "mylib.a"
!macro basic_header .a, .b, .c, .d {
        *= $0801
        !byte <.eol,>.eol,0,0,$9e
        !text .a, .b, .c, .d
.eol:   !byte 0,0,0
}

num_threads = 2
thread_num = $fd		; current thread number

;--------------------------------------------------------------------------
+basic_header "2", "0", "6", "1"

*= $080d

init:	sei
		; set up context switch IRQ
		lda #$35
		sta $01

		lda #<context_switch
		ldx #>context_switch
		sta $fffe
		stx $ffff
		
		lda #0
		sta thread_num

		cli
		jmp thread1

;--------------------------------------------------------------------------
context_switch:
		pha
		txa
		pha
		tya
		pha
		lda $dc0d

		; save current thread
		lda thread_num
		; *8
		asl
		asl
		asl
		tay
		; save A,X,Y
		pla
		sta thread_data+6,y
		pla
		sta thread_data+5,y
		pla
		sta thread_data+4,y
		; save PSW
		pla
		sta thread_data+1,y
		; save PC
		pla
		sta thread_data+2,y
		pla
		sta thread_data+3,y
		; save SP
		tsx
		txa
		sta thread_data,y

		; next thread, wraparound
		ldy thread_num
		iny
		cpy #num_threads
		bne +
		ldy #0
+		sty thread_num

		; *8
		tya
		asl
		asl
		asl
		tay

		; restore thread data
		; stack pointer first
		lda thread_data,y
		tax
		txs
		; push PC, PSW for RTI
		lda thread_data+3,y
		pha
		lda thread_data+2,y
		pha
		lda thread_data+1,y
		pha
		; push registers
		lda thread_data+6,y
		pha
		lda thread_data+5,y
		pha
		lda thread_data+4,y
		pha

		pla
		tay
		pla
		tax
		pla
		rti
	
;--------------------------------------------------------------------------
thread1:
		inc $d021
		ldy #$02
		jsr wait2
		jmp thread1


thread2:
		inc $d020
		ldy #$80
		jsr wait2
		jmp thread2
		
wait2:
-		ldx #0
		dex
		bne *-1
		dey
		bne -
		rts

;--------------------------------------------------------------------------
thread_data:
	!fill 8, 0
	!byte $ff-$40, $22, <thread2, >thread2, 0,0,0,0

... 211 posts hidden. Click here to view all posts....

2008-04-13 14:22

Oswald

Registered: Apr 2002
Posts: 5032

Gregg&Krill,

IMHO you are forcing strict operating system terms into a context where there is literally no operating system.

threads lives inside processes, and processes lives inside operating systems. the term process/task&thread is meaningless without the context of an operating system. tasks own resources (memory, drivers, windows, etc) provided by the OS, and threads are forks of the given task, with their own resources: stack, register state, etc.

when it comes to the c64 how would you define a bare bone irq as a thread of a process ? how are the resources allocated who provides them? where is the scheduler? somewhere the line has to be drawn, and I'd put it much farer. Handling terms so loosely I could say that subroutines are threads aswell. they preempt the main program with the jsr, save the context to the stack, and the scheduler rts decides to go back... the terms thread/processes were invented with a reason, that being they are different and complex entities inside an OS, not to be mixed up or seriously compared with a barebone enviroment's irq handler or subroutine. Even in an OS context interrupt is a valid term and clearly distuingishable from threads/tasks. so why should we mix up our non OS irqs with threads is over me, if not for the brag effect: "look I'm multithreading".

2008-04-13 14:28

trident

Registered: May 2002
Posts: 81

The concept of a thread is completely separate from the concept of an operating system.

2008-04-13 14:39

Krill

Registered: Apr 2002
Posts: 2857

What trident said.

Oswald: It's all a matter of definition. You are entitled to have your own one, but frankly, it opposes the current academical and scientific view. And there is multithreading without an OS.

2008-04-13 14:45

JackAsser

Registered: Jun 2002
Posts: 1995

In The Wild Bunch I used preemtive multithreading for the 4x4 tunnel part. The raster IRQ can be thought as the scheduler. The IRQ did all the 4x4 FLI stuff etc. and the main program did all the movetable shit. However, when I needed to switch the complete $d8xx-area the IRQ (scheduler) preemtied the main movetable code and switched to a $d8xx-updater thread, however this thread was cooperative since the movetable thread wouldn't gain back the CPU until the $d8xx update was complete. So in my case:

IRQ: Scheduler and VIC-trixer
movetable code: preemtive thread
d8xx updater code: cooperative thread

2008-04-13 14:48

chatGPZ

Registered: Dec 2001
Posts: 11154

similar stuff is going on with the sample player in mongobong. except its different. or something =)

2008-04-13 16:38

Oswald

Registered: Apr 2002
Posts: 5032

I feel like being told that the sky is green, and thats the scientific and academic view. I have asked for opinions on pouet. lets see :)

2008-04-13 16:52

trident

Registered: May 2002
Posts: 81

Quote: I feel like being told that the sky is green, and thats the scientific and academic view. I have asked for opinions on pouet. lets see :)

I think the problem might be what you hinted at earlier in this thread: people seem to think that multi-threading is something to brag about.

I have never heard people brag about other control flow abstractions. Do people brag about their cool way of doing subroutines? Or their awesome conditional branches? No. But for some reason people seem to think that multithreading (and particularly preemptive multithreading) is something special and something to be particularly proud about.

My point with the discussion in this thread is to show that preemptive multithreading is an abstraction that is simple and easy to understand. It is lightweight and does not require an underlying operating system. There is nothing magical about multithreading. There is nothing here to brag about.

Preemptive multithreading is what we've all been doing all along - and there is nothing special about it.

2008-04-13 17:24

Oswald

Registered: Apr 2002
Posts: 5032

why should we call interrupts threads ? a thread does not have a fixed entry and exit points. a thread has its context stored and restored upon exiting and entering it. when you enter an irq you dont get back the same state of the stack & the registers, when you exited, do you ? thats already 2 things it makes apart from a thread IMHO. the sky is blue.

2008-04-13 17:35

Oswald

Registered: Apr 2002
Posts: 5032

also operating systems gave birth to the concept "threads" so its daring to say the two concept is completely separate, or that threads exists without OSes.

Wiki:

"Multithreading

As multitasking greatly improved the throughput of computers, programmers started to implement applications as sets of cooperating processes (e.g. one process gathering input data, one process processing input data, one process writing out results on disk.) This, however, required some tools to allow processes to efficiently exchange data.

Threads were born from the idea that the most efficient way for cooperating processes to exchange data would be to share their entire memory space. Thus, threads are basically processes that run in the same memory context. Threads are described as lightweight because switching between threads does not involve changing the memory context."

its not my own definition krill, its comming from wikipedia, which according to you opposes the current academic & scientific views.

2008-04-13 17:50

trident

Registered: May 2002
Posts: 81

Oswald: Look at post #1 in this thread, there you'll find multithreading without an operating system.

Every thread has a fixed entry point. Threads that run to completion have exit points. Interrupt handlers are threads that run to completion, according to the accepted definition of a thread.

We keep telling you that the sky is blue, but you keep insisting that we say that it is green. Why?