Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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-16 11:59
Oswald

Registered: Apr 2002
Posts: 5031
Quote: For example when you keep on writing about privilege levels (post 96 is a good example), when it is irrelevant to this topic.

that doesnt show how is my interpretation flawed on the sources which are telling what is multithreading.
2008-04-16 12:09
Martin Piper

Registered: Nov 2007
Posts: 647
Quote: your definition is flawed then. post #80 says the 2 modes are running or not running irq. post #85 says its about the I flag. in reality post #85 was just a reality skewer machine so you can save yourself being laughed at coz of the stupidity of pst #80.

It is not flawed. "Executing an IRQ" in the context of the 6502 means "having the interrupt disable flag set" because it is not possible for the 6502 to execute an IRQ of the same level when it is already in IRQ mode and because by definition if the interrupt disable flag is clear then another IRQ can be executed therrfore it is not running an IRQ.

Post 85 is not some "skewer machine" it is the more verbose explanation of a point that was made earlier in post 80.
2008-04-16 12:30
Oswald

Registered: Apr 2002
Posts: 5031
Quote: It is not flawed. "Executing an IRQ" in the context of the 6502 means "having the interrupt disable flag set" because it is not possible for the 6502 to execute an IRQ of the same level when it is already in IRQ mode and because by definition if the interrupt disable flag is clear then another IRQ can be executed therrfore it is not running an IRQ.

Post 85 is not some "skewer machine" it is the more verbose explanation of a point that was made earlier in post 80.


"Executing an IRQ" in the context of the 6502 means "having the interrupt disable flag set"

thank you. you have prooved yourself now as a complete idiot. until next time.
2008-04-16 12:31
Martin Piper

Registered: Nov 2007
Posts: 647
Quote: that doesnt show how is my interpretation flawed on the sources which are telling what is multithreading.

You seemed to think privilege levels were somehow relevant to this specific topic of multi-threading on the 6502 yet you failed to show why.
You also claimed with regards to multi-threading "then no process exists without before being formally defined within a multitasking capable OS, and threads can only exist within processes." and "and are not to be mistaked with some primitive interrupt driven flow control mechanism running in a non OS enviroment."


Basically you are saying "it's not multi-threading because the C64 OS doesn't have it".


In the context of the C64 your argument is completely meaningless since someone can write code that completely replaces the ROMs. So looking at Gregg's code in the first post which does interrupt controlled program flow that can be considered as a tiny "C64 OS" kernal which implements a schedular which controls the multi-threading, therefore that means he correctly used the term multi-threading.
2008-04-16 12:32
Martin Piper

Registered: Nov 2007
Posts: 647
Quote: "Executing an IRQ" in the context of the 6502 means "having the interrupt disable flag set"

thank you. you have prooved yourself now as a complete idiot. until next time.


It is a perfectly valid statement and I note your use of a personal attack shows that you are unable to refute it. You are still wrong.
2008-04-16 12:45
Oswald

Registered: Apr 2002
Posts: 5031
you know there's a point when you give up and say: yes mice have five legs, because you have defined their tail as a fifth leg. I dont want to argue about fucking stupid stuff like tails==legs , or executing irqs == i flag set.
2008-04-16 12:47
Martin Piper

Registered: Nov 2007
Posts: 647
Quote: you know there's a point when you give up and say: yes mice have five legs, because you have defined their tail as a fifth leg. I dont want to argue about fucking stupid stuff like tails==legs , or executing irqs == i flag set.


Again you demonstrate that you make irrelevant and incorrect statements instead of refuting the actual argument I have made.
2008-04-16 12:51
Oswald

Registered: Apr 2002
Posts: 5031
Quote: You seemed to think privilege levels were somehow relevant to this specific topic of multi-threading on the 6502 yet you failed to show why.
You also claimed with regards to multi-threading "then no process exists without before being formally defined within a multitasking capable OS, and threads can only exist within processes." and "and are not to be mistaked with some primitive interrupt driven flow control mechanism running in a non OS enviroment."


Basically you are saying "it's not multi-threading because the C64 OS doesn't have it".


In the context of the C64 your argument is completely meaningless since someone can write code that completely replaces the ROMs. So looking at Gregg's code in the first post which does interrupt controlled program flow that can be considered as a tiny "C64 OS" kernal which implements a schedular which controls the multi-threading, therefore that means he correctly used the term multi-threading.


if you were as wise as you think you are, you would write schedulEr and multithreading, without the "-". it shows clearly how much you have read up on this topic.

threads are lightweight subprocesses running inside of the context of a process which is running in an enviroment which can run many processes in a multitasking enviroment. as long gregg's code doesnt atleast implicitly defines processes AND threads, its at best a multitasking "enviroment".

cya.
2008-04-16 12:57
Martin Piper

Registered: Nov 2007
Posts: 647
Quote: The effect thread interrupts the main thread without any knowledge or consent of it. And that's by definition how preemption works (see WP for example).

Gregg you are correct, Oswald is wrong. It's obvious to me now that he is just trolling. You have written a scheduler that demonstrates preemptive multi-threading, as it is understood by the reliable sources that matter on this subject (i.e. not Oswald's mistaken assumptions).
OK, at the moment it has no way to change the entry point of each thread, or the priority of each thread, or when to start or stop a thread or even the number of threads running without assembling a new bit of code. But still that does not affect the fact of the matter that preemptive multi-threading is possible on the C64.
2008-04-16 13:41
chatGPZ

Registered: Dec 2001
Posts: 11150
Quote:

Gregg you are correct, Oswald is wrong. It's obvious to me now that he is just trolling.


no, i am! tststs
Previous - 1 | ... | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | ... | 23 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
t0m3000/HF^BOOM!^IBX
Neotec/Padua
Almighty God/Level 6..
crayon/Hokuto Force
Proton/Finnish Gold
Heavy Head/NetPhreak..
Mr SQL
Skyhawk/Triad
jmin
Guests online: 59
Top Demos
1 Next Level  (9.7)
2 Mojo  (9.7)
3 13:37  (9.7)
4 Coma Light 13  (9.7)
5 Edge of Disgrace  (9.7)
6 Aliens in Wonderland  (9.6)
7 Comaland 100%  (9.6)
8 Uncensored  (9.6)
9 No Bounds  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 It's More Fun to Com..  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Nostalgia  (9.4)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 SHAPE  (9.3)
Top Webmasters
1 Slaygon  (9.7)
2 Perff  (9.6)
3 Morpheus  (9.5)
4 Sabbi  (9.5)
5 CreaMD  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.051 sec.