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-17 18:51
Oswald

Registered: Apr 2002
Posts: 5031
its not my conclusion. its your sentences concatenated after each other:

"the difference can only be explained in the context of the execution environment. "execution environment" has nothing to do with OS, threads, processes - or even computers per se."


now define execution enviroment, or you still wanna play this childish game giving it different meanings each post just to contradict my reasonings? :) come on.

oh one more contradiction:

"LOL. how exactly would that code code run at all if there is no execution environment?" "execution environment" has nothing to do with OS, threads, processes - or even computers per se."

what's all this bullshit dear groepaz?
2008-04-17 19:17
chatGPZ

Registered: Dec 2001
Posts: 11152
the execution environment, as the name says, defines the environment code is executed under. it can be anything, a piece of paper, a cpu with some ram, a c64 - with or without it's OS -, or a fully fledged operating system, or even a process within said operating system. threads or processes are not needed, nor relevant, to define a execution environment. there dont have to be threads or processes for an execution environment to exist.

however, there CAN be processes and threads in a execution environment. if your execution environment is windows, THEN the execution environment (for a thread) involves a process, and the execution environment for said process involves a multitasking OS/sheduler/whateveryouwanttocallitidontcare. if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads.

and thats why you must first define what the execution environment is before you can define other things which live in said environment. depending on the environment the distinction between processes and threads can't be made, because no such hirarchic distinction exists (and infact, they are sometimes called processes, and sometimes called threads in such environments, although the same thing is described).

this is also pretty much the source of your confusion. you are drawing conclusions from definitions made in the execution environment of a multitasking operating system, and apply them to a barebones embedded system without one.

or to quote your favourite example: when the sky is blue, drawing the conclusion that everything that is blue must be somehow related to sky is... you know the word.

2008-04-17 19:42
TDJ

Registered: Dec 2001
Posts: 1879
I asked a colleague of mine, who is known as an expert in this field (multi threading, concurrency) to read this thread and give me his opinion about it. This is a guy who published articles on this subject for serious sites like serverside.com.

His conclusion is that all of you are crazy and by proxy, so am I. He even asked me if it wasn't time for us to move on to, oh, the amiga for example?

So thank you guys, thank you for making me look bad! ;)

Seriously though, insults notwithstanding, I kinda like this discussion, one of the more interesting ones here in a long time.
2008-04-17 19:45
Oswald

Registered: Apr 2002
Posts: 5031
"this is also pretty much the source of your confusion. you are drawing conclusions from definitions made in the execution environment of a multitasking operating system, and apply them to a barebones embedded system without one."

exactly. processes & threads are by definition entitys inside the exectution enviroment of a multitasking OS. Its not me who tries to apply them to a barebone system, I am saying that the concepts thread&process does make no sense without the execution environment of a multitasking OS. or more correctly: a thread does make no sence without the execution enviroment of its process.

I have already said this in post #42:

"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"
2008-04-17 19:58
Martin Piper

Registered: Nov 2007
Posts: 647
Not correct Oswald because threads can exist in processes or task or a program. (From your cite in post 144). In this case Gregg's example is a single process or a program. It does not need an OS with multiple processes to be able to implement multi-threading. All that matters here is that Gregg's code implements lightweight switching of a his program which is multi-threading, as per the definition contained in the links you provided. All the links you posted show you are wrong because your interpretation of those links is flawed because you are getting confused about what is a heavyweight process and what is a lightweight thread within a process.
2008-04-17 19:59
chatGPZ

Registered: Dec 2001
Posts: 11152
Quote:

processes & threads are by definition entitys inside the exectution enviroment of a multitasking OS.


no, not at all. the common way of explaining them involves a multitasking os, thats true. the sky is blue, but not everything blue is sky.

Quote:

threads lives inside processes, and processes lives inside operating systems. the term process/task&thread is meaningless without the context of an operating system"


and no matter how often you repeat it, it doesnt get more true.

one day you should talk to someone who has actual experience with embedded systems. don't show him this thread though, unless you like to get bitchslapped =P


2008-04-17 19:59
Frantic

Registered: Mar 2003
Posts: 1633
This topic is closed.
2008-04-17 20:01
Martin Piper

Registered: Nov 2007
Posts: 647
Quote: This topic is closed.

If only that were true, but Oswald still keeps on trolling. ;)
2008-04-17 22:01
Oswald

Registered: Apr 2002
Posts: 5031
Quote: Not correct Oswald because threads can exist in processes or task or a program. (From your cite in post 144). In this case Gregg's example is a single process or a program. It does not need an OS with multiple processes to be able to implement multi-threading. All that matters here is that Gregg's code implements lightweight switching of a his program which is multi-threading, as per the definition contained in the links you provided. All the links you posted show you are wrong because your interpretation of those links is flawed because you are getting confused about what is a heavyweight process and what is a lightweight thread within a process.


Not correct Martin because threads can only exist in processes or task or a program. (From my cite in post 144). In this case Gregg's example is not a single process or a program. It does need an OS with multiple processes to be able to implement multi-threading. All that matters here is that Gregg's code doesnt implements processes of a his program which is not multi-threading, as per the definition contained in the links I provided. All the links I posted show you are wrong because your interpretation of those links is flawed because you are getting confused about what is a heavyweight process and what is a lightweight thread within a process.
2008-04-17 22:08
Martin Piper

Registered: Nov 2007
Posts: 647
It is obvious to everyone reading this thread that you are trolling because you know you are wrong but you don't want to admit it.
Previous - 1 | ... | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 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
dyme
TheRyk/MYD!
hedning/G★P
DeMOSic/HF^MS^BCC^LSD
Wolk/Software of Swe..
crayon/Hokuto Force
Guests online: 98
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 Logo Graphicians
1 Sander  (9.9)
2 Facet  (9.5)
3 Mermaid  (9.4)
4 Pal  (9.4)
5 Shine  (9.3)

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