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

Welcome to our latest new user eightbitswide ! (Registered 2024-12-24)

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 22:08

Martin Piper

Registered: Nov 2007
Posts: 722

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.

2008-04-17 22:39

Oswald

Registered: Apr 2002
Posts: 5094

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.

2008-04-17 22:46

Oswald

Registered: Apr 2002
Posts: 5094

"if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads."

gregg's example uses the c64 as an embedded system without an os per se. so based on groepaz' words:

->you are wrong-> you know you are wrong -> you are trolling. live with it :)

2008-04-17 23:48

Oswald

Registered: Apr 2002
Posts: 5094

Quote: 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

"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."

the terms/concepts process/thread originate from multitasking OSes. Multitasking OSes invented them. Thread as a concept has evolved and born from the concept of the process. Threads furthermore are the result also of the modern cpu design as they can use their pipeline and other parallel parts more efficient running threads. when one thread has a cache miss, then the other one gets scheduled for example. then there is SMT simultaneuos multi threading which means truly parallel execution of threads.

threads in todays world are anything but changing return values in a stack manually.

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

is that an argument?

"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"

"if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads"

seems you're gonna be bitchslapped.

2008-04-18 00:10

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

"if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads"

seems you're gonna be bitchslapped.

you are still thinking that because the sky is blue, everysthing blue must be sky.

just because there are no threads or processes in your execution environment it doesn't mean threads can not exist within said environment.

anyway, feel free to go on drawing your false conclusions. i'll try my best not to post anymore in this thread, its futile anyways and everything has been said twice anyway.

2008-04-18 00:14

Martin Piper

Registered: Nov 2007
Posts: 722

Oswald you wrote: "gregg's example uses the c64 as an embedded system without an os per se."

You are wrong on at least two counts here.

Firstly:
Gregg's example code (post 6) uses an OS, the ones defined in memory locations $a000-$bfff and $e000-$ffff, then demonstrates multi-threaded operation by using an interrupt to alter the flow of the mainline operating context at regular intervals.

Unless you can prove that Gregg's code (post 6) doesn't use BASIC and doesn't use locations $0314 and $0315. Unfortunately for you you cannot prove that because as you might know the contents of $0314/$0315 get used by $ff58 JMP ($0314). $ff58 of course just happens to be in the C64's KERNAL, which is one part of the C64's OS.

Secondly, Groepaz's comment you quoted does not support your case, in actual fact it tells you why you are wrong. This is because it says:
"if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads."

The C64 is not an embedded system without an OS, the C64 is a personal computer with two ROMs that comprise its OS. I know you seem to love Wikipedia so I'll cite the link for you. http://en.wikipedia.org/wiki/Embedded_system
Note the bit on that page that has "personal computer" linked? Good, I'm glad. Now you will admit you are wrong.

Also note the use of the word "if" used by Groepaz. It isn't saying "the C64 is an embedded system", it is saying "if your execution environment is an embedded system without an OS per se" and that is a very obvious difference.

Thirdly, Gregg's example code can be thought of as part of an OS that specifically deals with lightweight mutli-tasking, even if the code is tiny it can still be thought of as part of an OS, so that means you are wrong Oswald.

Fourthly, Groepaz goes on to say:
"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."

As Groepaz says, you are confused Oswald because you are making faulty assumptions and reaching incorrect conclusions.

2008-04-18 04:00

Oswald

Registered: Apr 2002
Posts: 5094

10 PRINT "BY DEFINITION THREADS ARE PARTS OF PROCESSES AND PROCESSES ARE PARTS OF MULTITASKINS OSES";
20 GOTO 10

"anyway, feel free to go on drawing your false conclusions. i'll try my best not to post anymore in this thread, its futile anyways and everything has been said twice anyway."

2008-04-18 04:17

The Shadow

Registered: Oct 2007
Posts: 304

All this arguing and it is still not clear who is correct. How can one conclude anything when both arguing parties are "right"? Can't! Is there someone else, who can clarify this subject for sure?

2008-04-18 05:49

A Life in Hell
Account closed

Registered: May 2002
Posts: 204

Quote: All this arguing and it is still not clear who is correct. How can one conclude anything when both arguing parties are "right"? Can't! Is there someone else, who can clarify this subject for sure?

I can clarify. You are all idiots.

2008-04-18 07:04

trident

Registered: May 2002
Posts: 91

Having read the last few days of posts, the problem isn't that anyone is completely incorrect here - Oswald is correct in many ways - the problem is that these concepts are inherently difficult.

The important thing to realize is that there is nothing magical about these concepts: an operating system is not a magical entity, it is just another program. A process is just a convenient definition that does not necessarily have anything to do with operating systems, but that also has changed its meaning over the years. Wikipedia is not the authoritative source. Multithreading is nothing to brag about, it is just another programming tool.

There is only one really good way to grasp these things: read a couple of good books on the subject of programming and operating systems (Knuth, Tanenbaum, Silberschatz/Galvin are good names to know), read a couple of good books on concurrent programming languages, write a couple of operating systems, write a couple of multithreading libraries, write a couple of compilers, learn how different CPU architectures work by doing low-level programming on them, step-by-step debug multithreaded code in a debugger, design a CPU architecture and think about interrupt handling and stacks, and constantly challenge your own presumptions. After doing this a few times one usually finds out that these concepts are not as easy and clear as one initially thought :)

Previous - 1 | ... | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 - Next

Refresh

Subscribe 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

Jammer
SLC
aeeben
Lead/House Designs
Guests online: 95

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (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 X-Mas Demo 2024  (9.5)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)

Top Groups

1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)

Top Graphicians

1 Mirage  (9.8)
2 Archmage  (9.7)
3 Pal  (9.6)
4 Carrion  (9.6)
5 Sulevi  (9.6)

Page generated in: 0.093 sec.