Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user lotus_skylight ! (Registered 2024-09-25) 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 22:02
Martin Piper

Registered: Nov 2007
Posts: 699
Quote: http://en.wikipedia.org/wiki/Process_%28computing%29

In computing, a process is an instance of a computer program that is being sequentially executed[1] by a computer system that has the ability to run several computer programs concurrently.

as gregg's code can not run several processes (and threads inside them) it does not do multithreading.

furthermore:

In the computing world, processes are formally defined by the operating system(s)(OS) running them and so may differ in detail from one OS to another.

I can see no formal definition of a process in gregg's code.


Again you have it the wrong way around.

Multi-threading = Gregg's code because it does not support multiple processes that can have threads threads. No hierarchy.

Multi-tasking = Multiple processes that can support multiple threads. A hierarchy.


Because there is no "formal definition of a process in Gregg's code" that means it is doing multi-threading because it has one process with multiple threads inside that one process.


Again this is from your own post:
"Multi-threading is running multiple lightweight threads of execution in a single program."
2008-04-16 22:08
Martin Piper

Registered: Nov 2007
Posts: 699
Even the link you cite proves you are wrong.

"A process may split itself into multiple 'daughter' ... threads"


It cannot be any simpler. Threads live inside processes. This is multi-tasking.


Processes can be multi-tasked.
http://en.wikipedia.org/wiki/Computer_multitasking
"multitasking is a method by which multiple ... processes ... share common processing resources such as a CPU."

This is multi-tasking.

Therefore in multi-tasking you have multiple processes which can each have multiple threads running inside each process.

It looks like this:
"OS" -> Processs -> Threads
2008-04-16 22:19
Martin Piper

Registered: Nov 2007
Posts: 699
Gregg's code is not a collection of processes, this is because processes are generally defined as independant programs that are in their own address space and interact only through OS calls. This means Gregg's code is not multi-tasking.

Gregg's code is a collection of threads (two threads to be exact) where the code is in the same address space. Because Gregg's code only has a one dimensional list of threads this means it is multi-threading.

If Gregg's code had a two dimensional array of threads, where each process could have its own block of threads, this would be multi-tasking.

This disproves what you have been posting. Especially since your own links disprove what you have been posting.
2008-04-16 22:37
Martin Piper

Registered: Nov 2007
Posts: 699
This quote from you explains exactly why you get it completely wrong:
"gregg havent implemented processes, thus he cant have threads either."

This is because the quote you cited from one link disproves your statement:
"Multithreading is running multiple lightweight threads of execution in a single process / task / program."

Note it says "single process/task/program". This means it is not mandatory to have support for multiple processes to be able to have support for threads. Threads can happily exist in one program or bit of code. This means no hierarchy. Gregg's code is one program. This is called multi-threading.
2008-04-16 23:02
Oswald

Registered: Apr 2002
Posts: 5076
"Multi-threading = Gregg's code because it does not support multiple processes that can have threads threads. No hierarchy."

no hierarchy = multitasking without multithreading
hierarchy = multitasking with multithreading

there's NO multithreading WITHOUT multitasking.

threads are defined as something thats inside processes, and there are no processes without multitasking:

In computing, a process is an instance of a computer program that is being sequentially executed[1] by a computer system that has the ability to run several computer programs concurrently.

"Multi-tasking = Multiple processes that can support multiple threads. A hierarchy."

nope. multitasking may be or may not be multithreading. multitasking doesnt support multithreading by definition. see Amiga OS for example. it is a preemptive multitasking OS without threads.

"that means it is doing multi-threading because it has one process with multiple threads inside that one process."

process cannot be defined as a process in a non multitasking but multithreading system. see above. processes are part of multitasking systems.


"Again this is from your own post:
"Multi-threading is running multiple lightweight threads of execution in a single program.""

...which program runs in a multitasking enviroment. as threads are inside processes and processes are inside multitasking OS-es. see the definitions I have quoted.

"Therefore in multi-tasking you have multiple processes which can each have multiple threads running inside each
process."

WRONG. see Amiga OS and similar again. first there was multitasking without threads. and only later were threads invented.

"It looks like this:
"OS" -> Processs -> Threads"

AmigaOS == multitasking: OS -> Process. end of story.

"Gregg's code is not a collection of processes, this is because processes are generally defined as independant programs that are in their own address space and interact only through OS calls. This means Gregg's code is not multi-tasking."

then its neither multitasking nor multithreading. I can live with that.

"Gregg's code is not a collection of processes"

fine. that means it cant have threads either. as threads are inside processes. no process - no threads.

"Gregg's code is a collection of threads (two threads to be exact) where the code is in the same address space."

cant be threads either. threads have their own stack. gregg's threads are sharing the same stack.

"If Gregg's code had a two dimensional array of threads, where each process could have its own block of threads, this would be multi-tasking"

Amiga OS.

"This disproves what you have been posting. Especially since your own links disprove what you have been posting."

not at all. only shows your lack of knowledge. multithreading is not a must for multitasking. see Amiga OS.
2008-04-16 23:20
Oswald

Registered: Apr 2002
Posts: 5076
Quote: This quote from you explains exactly why you get it completely wrong:
"gregg havent implemented processes, thus he cant have threads either."

This is because the quote you cited from one link disproves your statement:
"Multithreading is running multiple lightweight threads of execution in a single process / task / program."

Note it says "single process/task/program". This means it is not mandatory to have support for multiple processes to be able to have support for threads. Threads can happily exist in one program or bit of code. This means no hierarchy. Gregg's code is one program. This is called multi-threading.


"In computing, a process is an instance of a computer program that is being sequentially executed[1] by a computer system that has the ability to run several computer programs concurrently."

no support for multiple processes = no processes. no processes = no threads.

btw,

"It looks like this:
"OS" -> Processs -> Threads"

and in your dream it looks like this: -> threads. are you really so sure that does make any sense?

you either have OS -> Process -> Threads
or OS -> process (amiga)
or OS (c64)

but this is just silly : -> threads.
2008-04-17 08:35
Skate

Registered: Jul 2003
Posts: 494
actually multi-threading can exist without multi-tasking. but there is no OS exists using multi-threading and not multi-tasking. this is why Oswald is confused. he still thinks that 9th sprite cannot be shown in a raster line ;)

gregg's code definitely is not a multi-tasking example. to have multi-tasking you need to take care of a lot more things. specially about hardware specific features. for example if two of your applications (processes) are using sprites, you need to switch all sprite specific addresses ($d000-$d02f, SCREEN_MEMORY+$3f8-SCREEN_MEMORY+$3ff etc.) automaticly each time you switch between processes. "different processes must not affect each other!!!" this is why these documents say "multi-tasking is OS based". actually you don't need an OS for multi-tasking. But when you write these kind of process switch handling routines, it means that you've deleloped a very big structure of an OS.

I hope you have a more clear view about this now.
2008-04-17 09:38
Martin Piper

Registered: Nov 2007
Posts: 699
Quote: actually multi-threading can exist without multi-tasking. but there is no OS exists using multi-threading and not multi-tasking. this is why Oswald is confused. he still thinks that 9th sprite cannot be shown in a raster line ;)

gregg's code definitely is not a multi-tasking example. to have multi-tasking you need to take care of a lot more things. specially about hardware specific features. for example if two of your applications (processes) are using sprites, you need to switch all sprite specific addresses ($d000-$d02f, SCREEN_MEMORY+$3f8-SCREEN_MEMORY+$3ff etc.) automaticly each time you switch between processes. "different processes must not affect each other!!!" this is why these documents say "multi-tasking is OS based". actually you don't need an OS for multi-tasking. But when you write these kind of process switch handling routines, it means that you've deleloped a very big structure of an OS.

I hope you have a more clear view about this now.


Yes, that is exactly the reason why Oswald is confused.
2008-04-17 09:42
Martin Piper

Registered: Nov 2007
Posts: 699
Oswald your examples of Amiga OS are wrong because each process can have threads inside it, if the code is written to support it. Another example would be my pthread library for RISC OS which allowed pre-emptive multithreading inside each task where each task has its own memory mapped space from the MMU. The point being that the support for each process in the OS is heavyweight enough to allow each process to have its own threads, either from the OS or by using its own interrupts, if needed. This heavyweight handling of each process, as the poster above says, involves switching in and out lots of context information, not just threading information but also interrupts, graphics, sound, input devices etc. This is the hierarchy which I have been writing about. The hierarchy doesn't just mean thread information, although since this topic is dealing with threading specifically then threading is a good example of part of this hierarchy, it means everything related to the computer that needs to be saved and restored with each process switch.

Oswald, in post 144 you quoted:
"Multitasking is running multiple "heavyweight" processes (tasks) by a single OS."

And:
"Multithreading is running multiple "lightweight" processes (threads of execution) in a single process / task / program. See What is the difference between a lightweight and a heavyweight process:"


Do you agree that the terms lightweight refers to multi-threading and that heavyweight refers to multi-tasking?
Previous - 1 | ... | 11 | 12 | 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
Airwolf/F4CG
Stryyker/Tide
psenough
CA$H/TRiAD
insane/Rabenauge
Guests online: 127
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 Wonderland XIV  (9.6)
8 Comaland 100%  (9.6)
9 No Bounds  (9.6)
10 Unboxed  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Morph  (9.5)
8 Dawnfall V1.1  (9.5)
9 Onscreen 5k  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Nostalgia  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.2)
Top Diskmag Editors
1 Magic  (9.8)
2 Jazzcat  (9.5)
3 hedning  (9.4)
4 Elwix  (9.1)
5 Remix  (9.1)

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