[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-13 19:30

Oswald

Registered: Apr 2002
Posts: 5032

Quote: The concept of a thread is independent of the concept of a process. A process typically contains one or more threads, but a thread does not require the concept of a process.

threads are running within the process' context cooperatively. do wheels fullfill their purpose without axles ? what can threads do without the process' context?

2008-04-13 19:31

trident

Registered: May 2002
Posts: 81

Quote: an interrupt handler's state is not stored when it exits, while a thread's state IS stored when its preempted. an interrupt handler is always entered and exited on the same points while this is untrue for a thread. see any difference now ?

for the concept of a task/process look up wikipedia. its crystal clear.

There is no difference: when a thread exits, its state is removed. When an interrupt handler exists, its state is removed. When a thread is preempted, its state is storead. When an interrupt handler is preempted, its state is stored.

Threads have well defined entry points. Interrupt handlers have well defined entry points. Threads may have exit points (if they exit). Interrupt handlers may have exit points (if they exit). Not all threads exit. Not all interrupt handlers exit (e.g. first interrupt of a stable raster interrupt routine).

2008-04-13 20:42

Oswald

Registered: Apr 2002
Posts: 5032

lets define then what is a thread again:

"A thread in computer science is short for a thread of execution. Threads are a way for a program to fork (or split) itself into two or more simultaneously (or pseudo-simultaneously) running tasks. Threads and processes differ from one operating system to another but, in general, a thread is contained inside a process and different threads in the same process share some resources while different processes do not."

aha, so a thread is contained inside a process, so whats a process then? lets see:

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

A computer program itself is just a passive collection of instructions, while a process is the actual execution of those instructions. Several processes may be associated with the same program; for example, opening up several windows of the same program typically means more than one process is being executed. 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.

hope this helps you tell threads and interrupts apart, and realize that threads on a c64 system literally arent existing since no OS whatsoever exists which implements them.

2008-04-13 21:02

trident

Registered: May 2002
Posts: 81

If you are bent on running your threads inside processes, use Contiki.

2008-04-13 21:39

gregg
Account closed

Registered: Apr 2005
Posts: 56

Oswald, I'll still call them threads. :)

2008-04-13 21:46

Krill

Registered: Apr 2002
Posts: 2859

Oswald: Are you trolling?

2008-04-13 22:57

Skate

Registered: Jul 2003
Posts: 492

I think you are missing something in this discussion.

First, did you (x86 asm coders) ever code a multi-threaded application on PC in Assembler language? The answer is yes and no...

I think post#1 shows us a way of multi-threading. It's not fake, but it's useless. Because we are all doing the same shit for many years. Call it multi-threading or not, it's not important.

Multi-threading doesn't have to be related to the OS, but I believe it should be related to "higher level languages" than Assembler. If you are doing it from ASM, knowing that you're using multi-threading doesn't help you. Because you have to do all the work by yourself. You are just writing an optimized output of a compiler. That's it.

When it comes to higher level languages like C++, Java, C#, whatever... Multi-theading is becoming to get shape. For instance if a process (oops, should I call it a thread?) is killing your application, you can move it to another thread, share the output if necessery etc. Important thing is you do this with a very easy and well designed way. Your compiler does all the job (uses interrupts if required) for you. You see the power of multi-threading there.

As I told you before, we are all using multi-threading like techniques in our ASM codes for a long time. But naming the technique is not the important part. Some of you might heard of C=++ language developed by Nightlord. If multi-threading is being added to C=++ (I don't think so), then you can say you are really "using" it.

2008-04-14 05:11

Oswald

Registered: Apr 2002
Posts: 5032

Quote: Oswald: Are you trolling?

all: I'm playing fair, and use WP as basis for my arguments. if the definitions on WP are correct, then no process exists without before being formally defined within a multitasking capable OS, and threads can only exist within processes.

threads are a form uf multitasking within a task running within a multitasking enviroment, and are not to be mistaked with some primitive interrupt driven flow control mechanism running in a non OS enviroment.

thread is a high level OS term and it was invented to name the subprocesses running within processes. the idea being that tasks can be running more efficient when running them as many cooperative sub proccess also context switching is faster when they share memory and adress space, which are again OS only terms, and are meaningless without the formal definition within a given OS of what is a process, shared memory&adress space.

you are using a buzzword. similarly it was common to refer primitive wolfeinstein engines as of doom clones, but in this case it is like you're saying: "hey, dont troll man, its a crysis clone, hence, both are texture mapping". ten years ago we would have argued about wether it is interrupts or multi tasking.

2008-04-14 06:27

Stryyker

Registered: Dec 2001
Posts: 465

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.

2008-04-14 06:42

trident

Registered: May 2002
Posts: 81

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.

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

chesser/Nigaz
Didi/Laxity
HCL/Booze Design
ThunderBlade/BLiSS
jmin
Scorpion/Contex / Ar..
Stryyker/Tide
Grue/Extend
grennouille
Scrap/Genesis Project
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)

Page generated in: 0.052 sec.