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

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

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote: Oswald: Are you trolling?

never. i am though!

2008-04-14 13:00

Oswald

Registered: Apr 2002
Posts: 5094

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

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

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

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

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

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

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

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.

2008-04-14 16:38

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

Code cannot tell if it was called because of an interrupt or because of a jsr or a jmp.

cant you check the cpu status on the stack? :)

Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 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

Scrap/Genesis Project
leonofsgr/Singular C..
Didi/Laxity
slimeysmine
Genius/Xenon
WVL/Xenon
A3/AFL
Alakran_64
Guests online: 130

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 No Listen  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (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 NTSC-Fixers

1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Page generated in: 0.139 sec.