[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 13:51

Oswald

Registered: Apr 2002
Posts: 5094

Skate,

you seem to be have only blurry ideas even about some of the most basic OS concepts. You are mixing up the concepts "adress space" and "resource management".

resources(sprites):

"A resource, or system resource, is any physical or virtual component of limited availability within a computer system."

adress space:

"In general, things in one address space are physically in a different location than things in another address space. For example, "house number 101 South" on one particular southward street is completely different from any house number (not just the 101st house) on a different southward street."

you write:

"different processes must not affect each other!!!"

well, your own example doesnt fullfills that requirement. as the process in your example can write each others memory happily, except sprite registers. but sprite registers should be handled through resource allocation / sprite drivers, and not with different adress spaces. different adress spaces are there to avoid the process messing up each others memory. as a thumb of rule no process should be able to change any low level I/O regs directly, only through OS provided routines.

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

the rest of your statements are not arguable, as you provided no proofs to support them.

2008-04-17 14:04

Martin Piper

Registered: Nov 2007
Posts: 722

Oswald, you're getting confused not Skate. This is obvious from the way you're mixing up the definitions from the links you post. Those links show you are wrong, yet you don't understand why.

So since you're getting confused we will keep this simple, answer the question:
Do you agree that the terms lightweight refers to multi-threading and that heavyweight refers to multi-tasking?

2008-04-17 14:24

Oswald

Registered: Apr 2002
Posts: 5094

Amiga OS does multitasking without multithreading. which prooves you wrong, you said there's no multitasking without mulithreading. Saying that you can add multithreading later doesnt negates the fact that without adding multithreading it does multitasking. Just like RISC OS does multitaskign without your library happily. prooving you wrong.

2008-04-17 14:33

Martin Piper

Registered: Nov 2007
Posts: 722

Quote: Amiga OS does multitasking without multithreading. which prooves you wrong, you said there's no multitasking without mulithreading. Saying that you can add multithreading later doesnt negates the fact that without adding multithreading it does multitasking. Just like RISC OS does multitaskign without your library happily. prooving you wrong.

You are wrong that is not what I have written.
What I wrote is this:
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.

The links you quote prove you are wrong, also the Amiga OS and RISC OS example prove you are wrtong. You are getting very confused.

So, answer the question put directly to you with a yes or no reply.

2008-04-17 14:34

Oswald

Registered: Apr 2002
Posts: 5094

Quote: Oswald, you're getting confused not Skate. This is obvious from the way you're mixing up the definitions from the links you post. Those links show you are wrong, yet you don't understand why.

So since you're getting confused we will keep this simple, answer the question:
Do you agree that the terms lightweight refers to multi-threading and that heavyweight refers to multi-tasking?

Martin, that depends on the context. for example in the Amiga OS "A task is roughly equivalent to an OS/2 thread." thus it is lightweight in OS/2 and heavyweight in the Amiga OS. btw you will need a voodoo doll too, then keeping saying that oswald you're confused/wrong/mixing up things might be more effective. dont forget the needles either .))

2008-04-17 14:38

Oswald

Registered: Apr 2002
Posts: 5094

Quote: You are wrong that is not what I have written.
What I wrote is this:
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.

The links you quote prove you are wrong, also the Amiga OS and RISC OS example prove you are wrtong. You are getting very confused.

So, answer the question put directly to you with a yes or no reply.

you are a liar, my dear :)

here you just say it:

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

"The links you quote prove you are wrong, also the Amiga OS and RISC OS example prove you are wrtong. You are getting very confused."

yeah? and how ? can you proove it, or you rather stick to say those magic words ? :)

I can proove you wrong:

you said:

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

Amiga OS, and RISC OS, does'nt have multithreading. Theye are fine examples that multitasking without mulithtreading exists.

2008-04-17 14:44

Martin Piper

Registered: Nov 2007
Posts: 722

You are again ignoring what I posted, you are selectively quoting parts without quoting the whole of my point:
So I will quote myself: "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."

The Amiga OS and RISC OS multi-tasking are sufficiently heavyweight to allow multi-threading to be enabled on a per task basis if needed.

As Skate points out "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."

Gregg's code is definitely closer to multi-threading and is not closer to multi-tasking.

This shows you are still confused and you are still wrong.

2008-04-17 15:00

Oswald

Registered: Apr 2002
Posts: 5094

"You are again ignoring what I posted, you are selectively quoting parts without quoting the whole of my point:"

quoting is usually works that way my friend. selectively. and only parts. can you accept that? :) or each time I want to refer to what you have said I have to copy your whole post or all of them?:) and why do you selectively quote parts of what I have posted without quoting the whole of my point? you dont play fair or what? :)

your heavyweight blabla does not interest me.

"The Amiga OS and RISC OS multi-tasking are sufficiently heavyweight to allow multi-threading to be enabled on a per task basis if needed."

still they DONT do it, prooving you wrong: multitasking doesnt means there's any sort of multithreading needs to be present as you wrote:

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

furthermore I doubt Amiga OS tasks are heavyweight enough as Amiga OS tasks are similar to OS/2 threads.

2008-04-17 15:07

Martin Piper

Registered: Nov 2007
Posts: 722

I wrote "can support multiple threads" and this is completely different to your claim that I wrote something like "multithreading needs to be present". The point is that you are getting confused between heavyweight and lightweight and what that means in the real world of operating systems.

So you are wrong.

You are also wrong because you misquote what I have been writing. What I hacve been writing is this:
"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."

This also shows why you are wrong because the definition of hierarchy is wider than just your misquote.

2008-04-17 15:15

Skate

Registered: Jul 2003
Posts: 494

@Oswald: I said "for example if two of your applications (processes) are using sprites...". do you know what "for example" means?

I didn't try to make this discussing even more confusing than it is now. I tried to help with "simple" examples. I don't know if you've noticed or not but my last comment was focused on "multi-tasking". You've said gregg's code was closer to "multi-tasking" before. I didn't say it is "a real multi-threading" example. But it is much closer than multi-threading than multi-tasking. I don't care if it can exactly be considered multi-threading because just like I've mentioned before, I believe that multi-threading is important when you are using higher level languages or an assembler with a library (just like Amiga). Actually Amiga supports multi-threading if you ask me but there is no "thread" design in its libraries. But you can easily create "processes". That means Amiga libraries supports processes by default, than everybody accepts Amiga has multi-tasking support. But Amiga libraries doesn't support threads, so everybody says Amiga is multi-tasking but not multi-threading.

In c64, we don't use libraries like Amiga. So, if you ask me, there is no multi-tasking nor multi-threading exists in c64. can it be done? yes, it can. gregg's example can be considered as a multi-threading example. But it should be converted to a library and people should be able to use it easily. That's what I'm trying to tell you.

And a final quote of yours:
"the rest of your statements are not arguable, as you provided no proofs to support them."

Proofs? :) We are c64 sceners man and this is CSDB. Where do you think you are? And sorry but I don't really have as much as free time that you have. This is my 5th post or so and I already lost a lot of time in this argument. I'm not gonna go into google, wikipedia, copy&paste and stuff. What you read is what I know. You don't have to agree but at a little respect wouldn't hurt you.

Previous - 1 | ... | 12 | 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

slimeysmine
aeeben
E$G/HF ⭐ 7
Guests online: 101

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 Crackers

1 Mr. Z  (9.9)
2 Antitrack  (9.8)
3 OTD  (9.8)
4 Fungus  (9.8)
5 S!R  (9.8)

Page generated in: 0.069 sec.