| |
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 |
your definition is flawed then. post #80 says the 2 modes are running or not running irq. post #85 says its about the I flag. in reality post #85 was just a reality skewer machine so you can save yourself being laughed at coz of the stupidity of pst #80. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: For example when you keep on writing about privilege levels (post 96 is a good example), when it is irrelevant to this topic.
that doesnt show how is my interpretation flawed on the sources which are telling what is multithreading. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: your definition is flawed then. post #80 says the 2 modes are running or not running irq. post #85 says its about the I flag. in reality post #85 was just a reality skewer machine so you can save yourself being laughed at coz of the stupidity of pst #80.
It is not flawed. "Executing an IRQ" in the context of the 6502 means "having the interrupt disable flag set" because it is not possible for the 6502 to execute an IRQ of the same level when it is already in IRQ mode and because by definition if the interrupt disable flag is clear then another IRQ can be executed therrfore it is not running an IRQ.
Post 85 is not some "skewer machine" it is the more verbose explanation of a point that was made earlier in post 80. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: It is not flawed. "Executing an IRQ" in the context of the 6502 means "having the interrupt disable flag set" because it is not possible for the 6502 to execute an IRQ of the same level when it is already in IRQ mode and because by definition if the interrupt disable flag is clear then another IRQ can be executed therrfore it is not running an IRQ.
Post 85 is not some "skewer machine" it is the more verbose explanation of a point that was made earlier in post 80.
"Executing an IRQ" in the context of the 6502 means "having the interrupt disable flag set"
thank you. you have prooved yourself now as a complete idiot. until next time. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: that doesnt show how is my interpretation flawed on the sources which are telling what is multithreading.
You seemed to think privilege levels were somehow relevant to this specific topic of multi-threading on the 6502 yet you failed to show why.
You also claimed with regards to multi-threading "then no process exists without before being formally defined within a multitasking capable OS, and threads can only exist within processes." and "and are not to be mistaked with some primitive interrupt driven flow control mechanism running in a non OS enviroment."
Basically you are saying "it's not multi-threading because the C64 OS doesn't have it".
In the context of the C64 your argument is completely meaningless since someone can write code that completely replaces the ROMs. So looking at Gregg's code in the first post which does interrupt controlled program flow that can be considered as a tiny "C64 OS" kernal which implements a schedular which controls the multi-threading, therefore that means he correctly used the term multi-threading. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: "Executing an IRQ" in the context of the 6502 means "having the interrupt disable flag set"
thank you. you have prooved yourself now as a complete idiot. until next time.
It is a perfectly valid statement and I note your use of a personal attack shows that you are unable to refute it. You are still wrong.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you know there's a point when you give up and say: yes mice have five legs, because you have defined their tail as a fifth leg. I dont want to argue about fucking stupid stuff like tails==legs , or executing irqs == i flag set.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: you know there's a point when you give up and say: yes mice have five legs, because you have defined their tail as a fifth leg. I dont want to argue about fucking stupid stuff like tails==legs , or executing irqs == i flag set.
Again you demonstrate that you make irrelevant and incorrect statements instead of refuting the actual argument I have made.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: You seemed to think privilege levels were somehow relevant to this specific topic of multi-threading on the 6502 yet you failed to show why.
You also claimed with regards to multi-threading "then no process exists without before being formally defined within a multitasking capable OS, and threads can only exist within processes." and "and are not to be mistaked with some primitive interrupt driven flow control mechanism running in a non OS enviroment."
Basically you are saying "it's not multi-threading because the C64 OS doesn't have it".
In the context of the C64 your argument is completely meaningless since someone can write code that completely replaces the ROMs. So looking at Gregg's code in the first post which does interrupt controlled program flow that can be considered as a tiny "C64 OS" kernal which implements a schedular which controls the multi-threading, therefore that means he correctly used the term multi-threading.
if you were as wise as you think you are, you would write schedulEr and multithreading, without the "-". it shows clearly how much you have read up on this topic.
threads are lightweight subprocesses running inside of the context of a process which is running in an enviroment which can run many processes in a multitasking enviroment. as long gregg's code doesnt atleast implicitly defines processes AND threads, its at best a multitasking "enviroment".
cya. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: The effect thread interrupts the main thread without any knowledge or consent of it. And that's by definition how preemption works (see WP for example).
Gregg you are correct, Oswald is wrong. It's obvious to me now that he is just trolling. You have written a scheduler that demonstrates preemptive multi-threading, as it is understood by the reliable sources that matter on this subject (i.e. not Oswald's mistaken assumptions).
OK, at the moment it has no way to change the entry point of each thread, or the priority of each thread, or when to start or stop a thread or even the number of threads running without assembling a new bit of code. But still that does not affect the fact of the matter that preemptive multi-threading is possible on the C64. |
| Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | ... | 22 | 23 - Next |
