| | 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....
|
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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? |
| | trident
Registered: May 2002
Posts: 91 |
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). |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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. |
| | trident
Registered: May 2002
Posts: 91 |
If you are bent on running your threads inside processes, use Contiki. |
| | gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Oswald, I'll still call them threads. :) |
| | Krill
Registered: Apr 2002
Posts: 2980 |
Oswald: Are you trolling? |
| | Skate
Registered: Jul 2003
Posts: 494 |
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. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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.
|
| | Stryyker
Registered: Dec 2001
Posts: 468 |
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. |
| | trident
Registered: May 2002
Posts: 91 |
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 | |
