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-14 12:49
Oswald

Registered: Apr 2002
Posts: 5032
Quote: When you think it through a bit more the definitions can be applied to the threading example code posted in this thread (damn, that word again) can be seen as the overall code is the process and the interrupt is switching threads. They're all pieces of code using the same overall resource but doing slightly different things. I'm sure we could look other respectable publications for definitions and get different answers. Most of Wikipedia stuff is applied to now on current architectures.

sure, but why dont you call irqs tasks, or multitasking at the first place? why multithreading? because that word is more fashionable?... and why dont we call tasks (processes) threads, or threads processes, or processes interrupts ? or why dont we call subroutines threads, or multitasking multisubroutining? all are the same, I can proove the same way trident prooved threads are interrupts.

so why do we use so many words for the essentially same thing? maybe because they are different?

2008-04-14 12:57
chatGPZ

Registered: Dec 2001
Posts: 11157
Quote: Oswald: Are you trolling?

never. i am though!
2008-04-14 13:00
Oswald

Registered: Apr 2002
Posts: 5032
Quote: Oswald: I can fully appreciate your frustration, given that you are using the Wikipedia as your reference. The problem with using the Wikipedia as a reference is that the Wikipedia is not an authoritative source. In discussions like this, we need to go to an authoritative source of information: well established text books in the field is generally considered to be the best authoritative sources of information.

Operating system concepts by Silberschatz and Galvin ("The dinosaur book") is one of the most widely used textbooks in this area. In my copy (5th edition, 1998), the authors first define the concept of a thread on page 103: "A thread, sometimes called a lightweight process (LWP), is a basic unit of CPU utilization, and consists of a program counter, a register set, and a stack space."

The authors thus define a thread to be independent of any operating system: it is just a program counter, the registers, and a part of a stack (it does not even have to be a "full" stack).

Looking at the references in the Wikipedia article on processes, the only source listed is an old, seemingly obscure (it has only one citation in the ACM DL and three in Google scholar), paper from ACM SIGOPS OSR:

Gary D. Knott. A proposal for certain process management and intercommunication primitives ACM SIGOPS Operating Systems Review. Volume 8 , Issue 4 (October 1974). pp. 7 - 44

This paper, which is the basis of the Wikipedia article, defines the concept of a process thusly:

"A processor is a device capable of executing a program. The CPU of a digital computer is our basic example of a processor.

A process is an instance of the sequential execution of a program (i.e., a list of instructions indexed by a process-specific program-counter)."

You see that, in this 1974 paper, even the concept of a process is defined without using the concept of an operating system. We must, however, take into account that this paper was written in 1974; the definition of a process has changed since then. Today, a process generally is considered to be an operating system concept. Threads are, however, still independent of the concept of an operating system.


Operating system concepts

have you read the title of your source ? OPERATING SYSTEM CONCEPTS. your source defines thrad within the OPERATING SYSTEM CONTEXT. it doesnt states after every damned definition that we're inside an OS, as thats taken as the default view. if a book is ABOUT OPERATING SYSTEM CONCEPTS, so is the concept of thread of which this book is talking about.

with me?

"A proposal for certain process management and intercommunication primitives"

process management with intercommunication primitives happens inside an OS, which provides these resources, isnt it? So the book is talking about processes WITHIN an OS. And not about processes without an OS.

You only prooved that already in 1974 there was process management and inter process communication primitives within an OS.






2008-04-14 13:21
trident

Registered: May 2002
Posts: 81
The same book also defines the concept of interrupts. Does that mean that interrupts cannot exist outside of an operating system?
2008-04-14 14:00
JackAsser

Registered: Jun 2002
Posts: 1995
Shut up you two...

Instead of splitting hairs with processes and threads, simply call them tasks.

gregg's initial post is a fine example of how to implement preemtive multiTASKing on a C64 having several tasks running simultaneous using a scheduler (timer IRQ).

Threads usually refers to a more lightweight that processes in that they're more easy to context switch. A thread NORMALLY resides in the same memory as the process which means that a context switch between two threads within the same process won't result in a (expensive) TLB update.

Differentiate threads and processes on a C64 is just mumbo jumbo imo since a C64 doesn't have an MMU and doesn't have any memory protection. On a c64 therefore a thread equals a process (as on the A500). So let's call them tasks instead ok? And with a timer we can multiTASK.

Yes ok? Stop splitting hairs now and stop refer to old shit.
2008-04-14 14:09
chatGPZ

Registered: Dec 2001
Posts: 11157
within the PSPs operating system, every "task" is called "process". and they all live in the same memory space.

/o\
2008-04-14 15:08
Oswald

Registered: Apr 2002
Posts: 5032
Quote: The same book also defines the concept of interrupts. Does that mean that interrupts cannot exist outside of an operating system?

no. it does mean that threads are NOT interrupts. check the definitions of your highly regarded book.
2008-04-14 15:10
Oswald

Registered: Apr 2002
Posts: 5032
Quote: Shut up you two...

Instead of splitting hairs with processes and threads, simply call them tasks.

gregg's initial post is a fine example of how to implement preemtive multiTASKing on a C64 having several tasks running simultaneous using a scheduler (timer IRQ).

Threads usually refers to a more lightweight that processes in that they're more easy to context switch. A thread NORMALLY resides in the same memory as the process which means that a context switch between two threads within the same process won't result in a (expensive) TLB update.

Differentiate threads and processes on a C64 is just mumbo jumbo imo since a C64 doesn't have an MMU and doesn't have any memory protection. On a c64 therefore a thread equals a process (as on the A500). So let's call them tasks instead ok? And with a timer we can multiTASK.

Yes ok? Stop splitting hairs now and stop refer to old shit.


jack, yeah, that was my first thought when I have looked at this topic. Gregg's example implements multitasking. but the controversy started when trident and others insisted that loading from the main program, and using reentrant irqs to run the fx IS multithreading. finally trident started to proove that irqs==threads.
2008-04-14 15:51
Martin Piper

Registered: Nov 2007
Posts: 648
Quote: no. it does mean that threads are NOT interrupts. check the definitions of your highly regarded book.

The difference between threads and interrupts.

In the context of this discussion the 6502 has two operating levels. One level is when it is executing an IRQ. The other not running an IRQ, we will call this the mainline.

Pre-emptive multi-threading can use interrupts to switch between thread contexts so that when the interrupt finishes the mainline resumes execution from a different point.
2008-04-14 16:34
trident

Registered: May 2002
Posts: 81
Quote: The difference between threads and interrupts.

In the context of this discussion the 6502 has two operating levels. One level is when it is executing an IRQ. The other not running an IRQ, we will call this the mainline.

Pre-emptive multi-threading can use interrupts to switch between thread contexts so that when the interrupt finishes the mainline resumes execution from a different point.


No, the 6502 does not have two operating levels. There is no difference between machine code instructions that are executed because of an interrupt (i.e., an IRQ handler) and those that are executed because of a reset (i.e., the main code). Code cannot tell if it was called because of an interrupt or because of a jsr or a jmp.
Previous - 1 | ... | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... | 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
HCL/Booze Design
ThunderBlade/BLiSS
Didi/Laxity
jmin
Scorpion/Contex / Ar..
Stryyker/Tide
Grue/Extend
grennouille
Scrap/Genesis Project
Sokratekk
Guests online: 95
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.7)
5 Edge of Disgrace  (9.7)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 No Bounds  (9.6)
9 Wonderland XIV  (9.6)
10 Aliens in Wonderland  (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 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Dawnfall V1.1  (9.5)
8 Birth of a Flower  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Nostalgia  (9.4)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Offence  (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.08 sec.