| |
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
|
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
I took a quick peek and I don't see anything in there to set up the threads' stack areas. You really should run this sort of thing through a (VICE's) monitor to see what's happening.
edit: Scratch that. I completely missed the table ;)
The fact remains that fiddling with the stack is error prone and accidentally putting some push/pop sequence in the wrong order would blow the entire thing up, so I suggest simply walking through it line-by-line to see that you get the values you expect.
Also instead of having a separate PCB block to store the register state and return address in why not simply keep it directly on the thread's stack? Also the 6502 generally prefers separate arrays for each of the structure's members rather than one big array of structures which you have to multiply the index to get access to. |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Quote:why not simply keep it directly on the thread's stack?
Damn, that's so obvious and simple that I totally missed it. :) This will get me around a lot of error prone stack fiddling too, I'll try to adapt it later. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
I think I've got it. The registers seem to be restored in reverse order. Consider y for instance. When it's pushed you store it in thread_data+6, but in the return sequence it gets popped into A instead. |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Thanks, looks like it really was that. Hey, and I was SO sure it was the correct order. The stack really can be nasty. :) |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Here's a somewhat cleaned up example for the threading code. Maybe this can be put onto codebase, any objections against it?
!to "threading.prg",cbm
!cpu 6510
num_threads = 2
thread_num = $fd ; current thread number
;--------------------------------------------------------------------------
*= $0801
!byte <.eol,>.eol,0,0,$9e
!text "2061"
.eol: !byte 0,0,0
*= $080d
init: sei
lda #<context_switch
ldx #>context_switch
sta $0314
stx $0315
; initialize threads
ldx #0
stx thread_num
; main thread is automatically setup by first irq
; we only need to setup further threads
; split stack
tsx
txa
tay
sec
sbc #$20
tax
txs
; push thread data
; program counter, status register, a, x, y
lda #>thread2
pha
lda #<thread2
pha
lda #0
pha
pha
pha
pha
; save stack pointer
tsx
txa
sta thread_data+1
; restore old stack pointer
tya
tax
txs
cli
; go to main thread
jmp thread1
;--------------------------------------------------------------------------
context_switch:
; save stack pointer
ldy thread_num
tsx
txa
sta thread_data,y
; next thread, wraparound
iny
cpy #num_threads
bne nowrap
ldy #0
nowrap:
sty thread_num
; restore thread
lda thread_data,y
tax
txs
jmp $ea31
;--------------------------------------------------------------------------
thread1:
inc $d020
ldy #$01
jsr wait2
jmp thread1
thread2:
lda #<msg1
ldy #>msg1
jsr $ab1e
ldy #0
jsr wait2
jmp thread2
wait2:
- ldx #0
dex
bne *-1
dey
bne -
rts
;--------------------------------------------------------------------------
msg1: !pet "hello, here is thread 2!",13,0
thread_data:
|
| |
Burglar
Registered: Dec 2004
Posts: 1051 |
so whats your goal for c64 'threads'? |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: so whats your goal for c64 'threads'?
They're actually surprisingly useful.
For instance I'm currently working on a NES demo (a 6502-based system BTW) where I want to run a high priority task during vblank, since that's the only time you can access VRAM, and other lower-priority code the rest of the time.
Unfortunately I was forced to redesign the vblank code in such a way as to run out of time (which ended up costing a lot of extra time and memory since anything unpredictable had to be moved out of the blanking period) since that damned console lacks a decent interrupt source.
Similar schemes are often useful in more complex game setups and the like too, and operating systems of course.
As always the problem with multithreading is working out the synchronization, and this is no less true on the 6502. But I suppose it isn't that much different from synchronizing your code with an interrupt handler (hint: use the RMW instructions to implement locks and the like). |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Burglar: It's cool to have them. No, seriously, I was thinking of something along the lines of calculating an effect while irq-loading the next part of a demo. This gets very easy with threads. You'd just need more elaborate scheduling here. |
| |
trident
Registered: May 2002
Posts: 81 |
Preemptive multithreading is very useful when rastertime is particularly tight and when the timing of your routines are not critical, as you don't need to worry about the exact execution time of your code. IIRC, I think I used a simple form of multithreading for Hellfork where one thread draws the outlines of the scene and one calculates the movement of the player. The threads are scheduled when the ESCOS routine is not active and each thread runs about 25 times per second (I think - I don't think I ever measured it and I didn't really need to as the preemptive multithreading took care of the scheduling).
Hellfork also uses another, more elaborate, "static multithreading" technique (essentially a variant of rate monotonic scheduling): the ESCOS and eor fill routines are interleaved in a cycle-exact way so that the 3D scene can be drawn with all borders open. A precalc routine that keeps track of the cycle count of every instruction produces a cycle-exact mixture of an ESCOS routine and an EOR fill routine. The same precalc function also produces an interleaved ESCOS and sample player routine. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
multithreading/tasking is an OS thing, if you're looking for speed you better forget them, as there are smarter methods to solve your problems without the costly context switchings.
loading while effect runs:
1. modify the loader to exit after every xth byte
2. run the loader in the "main" program, and your effect from "irq" dont worry if your effect takes more than one frame, do it like this:
irqstart inc $dö19
..
..
..
cli
lda effect_already_runs
beq yes
dec effect_already_runs
jsr effect
inc effect_already_runs
yes rti
make sure to use the stack to save the regs, otherwise the "irq reentering" trick wont work.
when your effect finishes, the timeframe left until the next "effect calling" irq will be automagically used by the loader. |
| |
trident
Registered: May 2002
Posts: 81 |
Oswald: you just described preemptive multithreading: the IRQ is one thread that preempts the main thread. "Multithreading" is just the name for it.
Using the stack to save the regs = context switch. Context switching is not expensive on a 6502 since there is no memory protection. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
this is not multithreading nor tasking. for that the irq "task" should be handled like:
a) save and restore the irq's cpu state on exit/enter. this doesnt happen. there's only "context switch" for one "thread". there's no seperate stacks, etc.
b) there are no fixed exit and entry points of real threads like the irq in my example
|
| |
trident
Registered: May 2002
Posts: 81 |
Saving state is done implicitly when registers and the CPU status word are pushed onto the stack. Multiple stacks are not necessary, since there is only one level of preemption: the IRQ thread runs on the same stack as the main thread. Switching between multiple "main" threads is easy too, since one can use different parts of the stack at $100 for different threads: ldx $stack_pointer_of_the_other_thread; txs; jmp $ea81;
But, as you say, preemtpive multithreading is often not the most efficient way to get the job done (and is obviously no silver bullet). The nice thing with timer-based preemptive multithreading is that you don't need to specify things like "modify the loader to exit after every xth byte" or "calculate x mandelbrot pixels", but you can say "load data from the drive during the next 10 raster lines" or "rotate vectors for 20 raster line", without needing to specify exactly how many bytes to load, pixels to calcluate, or vectors to rotate.
At the end of the day, it is just another tool in the toolbox. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"Saving state is done implicitly when registers and the CPU status word are pushed onto the stack. "
once again: the interrupt "thread"'s state is not saved anywhere. threads have no fixed entry and exit points. even if it were multithreading it were not a premptive one: "Cooperative multithreading, on the other hand, relies on the threads themselves to relinquish control once they are at a stopping point"
also: "Threads do not own resources except for a stack, a copy of the registers including the program counter, and thread-local storage"
since when does an irq have an own stack, copy of registers, and program counter?
get your facts straight please. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:
since when does an irq have an own stack, copy of registers, and program counter?
thats pretty common on many architectures actually...and in a way, you can do it on c64 aswell. that you have to adjust said things "manually" in the isr is mostly an implementation detail, not a violation of the basic principle. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Groepaz, possibly. but in my example the irq doesnt has an own stack/pc/registers, so I beg trident not to call that approach preemptive multithreading. its neither preemptive/multithreading. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
infact, it is :) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
please define exactly what do you think is:
a) multithreadnig
b) a thread
c) preemptive
then show me how is my example a preemptive multithreading. thanks in advance. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
i am not going to write a dozen pages of text here, really. also trident is in a much better position to explain it, so i'll leave it to him. if he cares anyway =P |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
maybe you shouldnt troll around as a mod, and state stupid things which are untrue. can you prove it ? no. then stop trolling. now you may modify your own post to "sorry for trolling :("
thanks in advance. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
you have an interisting definition of trolling, really :) |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
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). |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: you have an interisting definition of trolling, really :)
and you have childish arguments, and trolling techniques. :) |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Please use 4chan for all your trolling needs! (Or heise.de for ze Germans) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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).
but it gives back control by own will which is cooperative. also threads does not preempt/return to other threads by own will. also threads has own context, stack, etc, which an interrupt clearly does not have. its just an interrupt not a thread. |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
One argument in Oswalds favor could be that the effect "thread" locks the system thread until it's done and then returns, so it's actually not preemtive multithreading. For it to be preemtive, it would have to be interrupted by the system for the main thread to run. It's not Cooperative multithreading either, because the main thread do not relinquish the system resources for the effect thread to run (unless you'd like to argument that the IRQ does that for it). It's not one nor the other. I doubt it would be considered multithreading. Dualthreading at most :)
That said, the concept of writing a multithreading kernel for the C64 is a very interesting concept. I'm not sure how useful it is (I lack the imagination for that, I guess), but it's really neat. Isn't there going to be some problems with stack in your implementation, Gregg?.. I mean, the more threads you add, the less stack there'd be free for each thread, correct?.. And copying the complete stack per thread (plus state) is going to be expensive in terms of both memory usage and CPU time spend on task switching... Hmm..
EDIT: Didn't see your previous reply, Dr. O.. So in fact we agree on this :) |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Quote: Isn't there going to be some problems with stack in your implementation, Gregg?.. I mean, the more threads you add, the less stack there'd be free for each thread, correct?..
Yes, I'm simply moving the stack pointer down by a fixed amount for each thread. This limits the the number of threads as well as the maximum recursion depth, but I don't think either will be a real issue on the c64... this is meant to be used for a handful of threads, not dozens and dozens of threads.
Quote:And copying the complete stack per thread (plus state) is going to be expensive in terms of both memory usage and CPU time spend on task switching...
I'm not copying the stack, but merely changing the stack pointer. The initialization only pushes initial thread data onto the stack, to make it possible to actually start it. |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Quote: Quote: Isn't there going to be some problems with stack in your implementation, Gregg?.. I mean, the more threads you add, the less stack there'd be free for each thread, correct?..
Yes, I'm simply moving the stack pointer down by a fixed amount for each thread. This limits the the number of threads as well as the maximum recursion depth, but I don't think either will be a real issue on the c64... this is meant to be used for a handful of threads, not dozens and dozens of threads.
Quote:And copying the complete stack per thread (plus state) is going to be expensive in terms of both memory usage and CPU time spend on task switching...
I'm not copying the stack, but merely changing the stack pointer. The initialization only pushes initial thread data onto the stack, to make it possible to actually start it.
Yeah, I know you aren't copying the stack (I did look at the code, you know :)= ).. I was thinking that the implications of doing so would be relatively severe (on this system). The current implementation would enforce limitations on each thread. Effectively this means that adding a thread can result in previously added threads to stop working if they rely on a serain amount of the stack frame (if the stack is divided in to equal size per thread). |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Yeah, but I hope you're not going to seriously use recursion for algorithms on the c64, are you? :p I doubt this ever becomes a real problem. Even the tiny stack offset of $20 bytes allows a recursion depth (JSR) of 13... that's quite enough :) |
| |
Krill
Registered: Apr 2002
Posts: 2856 |
Quote: but it gives back control by own will which is cooperative. also threads does not preempt/return to other threads by own will. also threads has own context, stack, etc, which an interrupt clearly does not have. its just an interrupt not a thread.
What are you nitpicking about anyways?
It is a fact that everything described here is some sort of multithreading. The details as to whether, e.g., who is in charge of what, or whether a thread has a complete own stack on its own or not, are not relevant.
Also pretty many embedded systems, among others, implement preemptive multithreading using timer interrupts and then switch states "manually".
Furthermore, there is any number of variations for multithreading in general, as to what is static, what is shared or private, et cetera.
That said, multithreading on C64 is neither expensive nor useless. I have used it myself here and there, and generic/elegant solutions are not bound to be expensive. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
oh yeah, to hell with nitpicking, and correct use of terms. finally we may freely say that the c64 OS was a preemptive multitasking and multithreading system indeed :) BEFORE the amiga (!!!) which didnt even had multithreading ! ;) |
| |
Krill
Registered: Apr 2002
Posts: 2856 |
Did you deliberately grossly mix up the terms now? |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Krill, well if you say that interrupts are threads, then I'm with you. then the c64 OS is multithreading, doesnt it ? |
| |
trident
Registered: May 2002
Posts: 81 |
Quote: One argument in Oswalds favor could be that the effect "thread" locks the system thread until it's done and then returns, so it's actually not preemtive multithreading. For it to be preemtive, it would have to be interrupted by the system for the main thread to run. It's not Cooperative multithreading either, because the main thread do not relinquish the system resources for the effect thread to run (unless you'd like to argument that the IRQ does that for it). It's not one nor the other. I doubt it would be considered multithreading. Dualthreading at most :)
That said, the concept of writing a multithreading kernel for the C64 is a very interesting concept. I'm not sure how useful it is (I lack the imagination for that, I guess), but it's really neat. Isn't there going to be some problems with stack in your implementation, Gregg?.. I mean, the more threads you add, the less stack there'd be free for each thread, correct?.. And copying the complete stack per thread (plus state) is going to be expensive in terms of both memory usage and CPU time spend on task switching... Hmm..
EDIT: Didn't see your previous reply, Dr. O.. So in fact we agree on this :)
A main program + IRQ is actually preemptive multithreading with priorities and two threads - even though we may not see this at first, because we are so accustomed to viewing this as "a main program and an IRQ" and tend to think of multithreading as something difficult, costly, and heavyweight (which it isn't). The IRQ thread has a higher priority than the main thread, so the IRQ thread preempts it. The main thread has a lower priority than the IRQ thread, so the IRQ thread is never preempted, but runs to completion.
Oswald: by adding the cli instruction in your IRQ handler, you make the IRQ preemptible. Thus you potentially have more than two threads: additional IRQs will preempt the IRQ thread (and store its state on the stack).
Here are accepted definitions for these concepts:
Thread = an execution context.
Preemption = a thread is moved off the CPU and another one is moved onto the CPU.
Multithreading = the ability to run multiple threads concurrently or in parallel.
On the 6510, an execution context is the CPU registers and the parts of the stack used by the program. When a thread is preempted (or yields voluntarily) the CPU registers are stored, typically on the thread's stack. An IRQ handler is an execution context. If the IRQ handler is preempted by another IRQ, the CPU registers are stored on the IRQ handler's stack. Since the IRQ handler will never be preempted by the main thread, the IRQ handler's stack can be physically placed on top of the main thread's stack.
The concepts of threads, preemption, stacks, interrupts, and priorities are difficult ones. I grew up with writing code that consisted of a main program + IRQs. It wasn't after thinking about these concepts a lot (and after writing 3-4 multithreading libraries and operating systems) that I understood that I had been doing preemptive multithreading with priorities all along :)
(For those that are interested in this, a highly related concept, which can be even trickier to grasp, is continuations (a continuation is a "snapshot" of a thread): http://en.wikipedia.org/wiki/Continuation http://c2.com/cgi/wiki?ContinuationExplanation ) |
| |
Krill
Registered: Apr 2002
Posts: 2856 |
The C64 OS, if you refer to the ROM software aka KERNAL, does not have any APIs to set up interrupts or threads. There are some basic hooks and ways to circumvent/disable the ROM routines, but in my book the C64's KERNAL is not multithreaded.
The mere hardware system, with the 6510 and various IRQ sources, is pretty well capable of multithreading. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
adam: now please, if you could tell in simple words whats the difference between a task, a process, and a thread .... it's giving me a headache all the time =P |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: The C64 OS, if you refer to the ROM software aka KERNAL, does not have any APIs to set up interrupts or threads. There are some basic hooks and ways to circumvent/disable the ROM routines, but in my book the C64's KERNAL is not multithreaded.
The mere hardware system, with the 6510 and various IRQ sources, is pretty well capable of multithreading.
how is my example multithreading then? it does not have any APIs to set up interrupts or threads. |
| |
Krill
Registered: Apr 2002
Posts: 2856 |
Oswald: To call an operating system multithreaded implies an API for that. The OS itself may use interrupts or some internal multithreading not accessible to the user, but still can't be called multithreaded from that perspective.
Any self-written code using some multithreading, and be it an OS, is multithreaded even without API.
So yes, sorry for not clearing up the different POVs earlier. |
| |
trident
Registered: May 2002
Posts: 81 |
Quote: adam: now please, if you could tell in simple words whats the difference between a task, a process, and a thread .... it's giving me a headache all the time =P
The generally accepted definition of a process is that it is a set of threads (which may include only one thread) and a set of (dedicated) resources: memory, files, etc. So a process is more "heavy-weight" than a thread.
But there is no generally accepted definition of a task... Every system and discipline seems to have its own definition. We can also add the concept of a "job" to the mess and have even more headache... :/ |
| |
Krill
Registered: Apr 2002
Posts: 2856 |
IMHO, this is all basically the same, only with quite a few overlapping borders depending on implementation and definition.
Though, yes, a little tedious not to have exact 100% agreed and understood definitions, but there are just too many details which matter in one context or not in some other. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Gregg&Krill,
IMHO you are forcing strict operating system terms into a context where there is literally no operating system.
threads lives inside processes, and processes lives inside operating systems. the term process/task&thread is meaningless without the context of an operating system. tasks own resources (memory, drivers, windows, etc) provided by the OS, and threads are forks of the given task, with their own resources: stack, register state, etc.
when it comes to the c64 how would you define a bare bone irq as a thread of a process ? how are the resources allocated who provides them? where is the scheduler? somewhere the line has to be drawn, and I'd put it much farer. Handling terms so loosely I could say that subroutines are threads aswell. they preempt the main program with the jsr, save the context to the stack, and the scheduler rts decides to go back... the terms thread/processes were invented with a reason, that being they are different and complex entities inside an OS, not to be mixed up or seriously compared with a barebone enviroment's irq handler or subroutine. Even in an OS context interrupt is a valid term and clearly distuingishable from threads/tasks. so why should we mix up our non OS irqs with threads is over me, if not for the brag effect: "look I'm multithreading". |
| |
trident
Registered: May 2002
Posts: 81 |
The concept of a thread is completely separate from the concept of an operating system. |
| |
Krill
Registered: Apr 2002
Posts: 2856 |
What trident said.
Oswald: It's all a matter of definition. You are entitled to have your own one, but frankly, it opposes the current academical and scientific view. And there is multithreading without an OS. |
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
In The Wild Bunch I used preemtive multithreading for the 4x4 tunnel part. The raster IRQ can be thought as the scheduler. The IRQ did all the 4x4 FLI stuff etc. and the main program did all the movetable shit. However, when I needed to switch the complete $d8xx-area the IRQ (scheduler) preemtied the main movetable code and switched to a $d8xx-updater thread, however this thread was cooperative since the movetable thread wouldn't gain back the CPU until the $d8xx update was complete. So in my case:
IRQ: Scheduler and VIC-trixer
movetable code: preemtive thread
d8xx updater code: cooperative thread
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
similar stuff is going on with the sample player in mongobong. except its different. or something =) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
I feel like being told that the sky is green, and thats the scientific and academic view. I have asked for opinions on pouet. lets see :) |
| |
trident
Registered: May 2002
Posts: 81 |
Quote: I feel like being told that the sky is green, and thats the scientific and academic view. I have asked for opinions on pouet. lets see :)
I think the problem might be what you hinted at earlier in this thread: people seem to think that multi-threading is something to brag about.
I have never heard people brag about other control flow abstractions. Do people brag about their cool way of doing subroutines? Or their awesome conditional branches? No. But for some reason people seem to think that multithreading (and particularly preemptive multithreading) is something special and something to be particularly proud about.
My point with the discussion in this thread is to show that preemptive multithreading is an abstraction that is simple and easy to understand. It is lightweight and does not require an underlying operating system. There is nothing magical about multithreading. There is nothing here to brag about.
Preemptive multithreading is what we've all been doing all along - and there is nothing special about it. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
why should we call interrupts threads ? a thread does not have a fixed entry and exit points. a thread has its context stored and restored upon exiting and entering it. when you enter an irq you dont get back the same state of the stack & the registers, when you exited, do you ? thats already 2 things it makes apart from a thread IMHO. the sky is blue. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
also operating systems gave birth to the concept "threads" so its daring to say the two concept is completely separate, or that threads exists without OSes.
Wiki:
"Multithreading
As multitasking greatly improved the throughput of computers, programmers started to implement applications as sets of cooperating processes (e.g. one process gathering input data, one process processing input data, one process writing out results on disk.) This, however, required some tools to allow processes to efficiently exchange data.
Threads were born from the idea that the most efficient way for cooperating processes to exchange data would be to share their entire memory space. Thus, threads are basically processes that run in the same memory context. Threads are described as lightweight because switching between threads does not involve changing the memory context."
its not my own definition krill, its comming from wikipedia, which according to you opposes the current academic & scientific views. |
| |
trident
Registered: May 2002
Posts: 81 |
Oswald: Look at post #1 in this thread, there you'll find multithreading without an operating system.
Every thread has a fixed entry point. Threads that run to completion have exit points. Interrupt handlers are threads that run to completion, according to the accepted definition of a thread.
We keep telling you that the sky is blue, but you keep insisting that we say that it is green. Why? |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Re the "threading with an OS" thing.
An OS can be really big or really small. If there is multi-threading, which this example shows, then the bit of code which does the context switches can be thought of as a really tiny OS.
Of course the code that runs multi-threading can also be thought of a just a tiny bit of code which does the job.
So yes, it is possible to have multi-threading without an OS per se.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
trident,
I haven't said that post#1 is not multithreading. but I think it does not :)) it is multitasking at best. multithreading means sub tasks within a task so to speak.
I'm arguing mainly that irqs are not multithreading, which you said they are, in a response to my example on how to load while an fx runs.
all of you are mixing the terms multitasking & multithreading heavily.
once again: multithreading means running cooperating processes within one task. threads were invented to make context switching faster by having them running in the same context of their parent task. this is the key.
this leads us back to that: you cannot seriously talk about threads outside the operating system context box. threads are on a sub task level and tasks is on the sub OS term level.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: Re the "threading with an OS" thing.
An OS can be really big or really small. If there is multi-threading, which this example shows, then the bit of code which does the context switches can be thought of as a really tiny OS.
Of course the code that runs multi-threading can also be thought of a just a tiny bit of code which does the job.
So yes, it is possible to have multi-threading without an OS per se.
in the c64's HW context thread is a meaningless term. as threads were invented to be able to run several cooperative subtasks within a task in an OS. we have no os, no task, how can we define threads them? they are part of tasks which we dont have at the first place. |
| |
trident
Registered: May 2002
Posts: 81 |
Oswald: multithreading, multitasking, and related concepts are tricky concepts and most of them are not very well defined. Neither require an operating system, however. (But then the concept of an operating system is not particularly well defined in computer science either... :/)
Threads are, however, a quite well defined concept and threads are completely orthogonal to the concept of an operating system. Many programming languages provide a thread abstraction, for example.
One of the key points you raise is interesting: are interrupt handlers really threads if they do not have a stack? The answer is yes, because the thread has both processor state (registers, status word, program counter) and a stack (physically located on top of the main program's stack). If the interrupt handler is preempted, the state is stored on its stack. So it is a thread.
But what if there is no memory where the state of the suspended thread can be stored? Suppose there is no stack where the interrupt handler can store its state - what is the interrupt handler then? This is where the concept of protothreads is useful: a protothread is a thread without a stack. When suspended, a protothread only remembers the program counter, but not the processor status. Protothreads therefore cannot be preempted, but must yield voluntarily at specific points. |
| |
trident
Registered: May 2002
Posts: 81 |
Quote: in the c64's HW context thread is a meaningless term. as threads were invented to be able to run several cooperative subtasks within a task in an OS. we have no os, no task, how can we define threads them? they are part of tasks which we dont have at the first place.
A thread simply is an execution context. When the C64 boots, it starts executing the main thread. The entry point of this thread is defined by the pointer at $fffa. Interrupt handlers (high-priority threads) can preempt this thread.
Threads are just an abstraction that is designed to make it possible to reason about systems. There is nothing magical about them. It is just a concept - an abstraction.
Concepts like "an interrupt handler" are in fact more complex concepts than threads. The reason we think that an interrupt handler is such an easy concept to grasp is because we've been brought up on them. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
trident,
substract 15 from 1 without the concept of negative numbers. managed? now set up a task without reserving memory, giving it I/O drivers, having a task scheduler, etc? understand me now? there's no task without OS. a task is an entity defined by the resources allocated, process ID, etc within the context of an OS.
*sigh* as a c64 coder yourself you should know that interrupts store only the "main" program's state. but themselves 'own' no pc/register/stack whatsoever. they store 0 state info of themselves. also the irq handler is NEVER preempted . you should know that the irq handler decides itself wether it goes back to "main" program or not. (remember HW turns on SEI automagically?) irqs are not threads. the sky is blue. etc. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: A thread simply is an execution context. When the C64 boots, it starts executing the main thread. The entry point of this thread is defined by the pointer at $fffa. Interrupt handlers (high-priority threads) can preempt this thread.
Threads are just an abstraction that is designed to make it possible to reason about systems. There is nothing magical about them. It is just a concept - an abstraction.
Concepts like "an interrupt handler" are in fact more complex concepts than threads. The reason we think that an interrupt handler is such an easy concept to grasp is because we've been brought up on them.
the term thread was invented to give a name to the varios >threads< that are running within a task. the term process/task was invented to name the various program entitys that are running within an OS. it builds up like a tree. you take away the tree's roots the tree falls down, so does the concept thread without the concept of a task and the task without the OS. |
| |
trident
Registered: May 2002
Posts: 81 |
The state of the interrupt handler is stored in the CPU (registers, status word, program counter) and on the stack (if the interrupt handler calls other functions, for instance). The CPU state is stored on the stack only if the interrupt handler is preempted (e.g. by an NMI - yes, interrupt handlers do get preempted sometimes).
As I previously said, the concept of a task is difficult, so it is better if we stick to the concept of threads. |
| |
trident
Registered: May 2002
Posts: 81 |
Quote: the term thread was invented to give a name to the varios >threads< that are running within a task. the term process/task was invented to name the various program entitys that are running within an OS. it builds up like a tree. you take away the tree's roots the tree falls down, so does the concept thread without the concept of a task and the task without the OS.
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: The state of the interrupt handler is stored in the CPU (registers, status word, program counter) and on the stack (if the interrupt handler calls other functions, for instance). The CPU state is stored on the stack only if the interrupt handler is preempted (e.g. by an NMI - yes, interrupt handlers do get preempted sometimes).
As I previously said, the concept of a task is difficult, so it is better if we stick to the concept of threads.
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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: 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). |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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: 81 |
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: 2856 |
Oswald: Are you trolling? |
| |
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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: 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. |
| |
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: 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.
sure, but why dont you call irqs tasks, or multitasking at the first place? why multithreading? because that word is more fashionable?... and why dont we call tasks (processes) threads, or threads processes, or processes interrupts ? or why dont we call subroutines threads, or multitasking multisubroutining? all are the same, I can proove the same way trident prooved threads are interrupts.
so why do we use so many words for the essentially same thing? maybe because they are different?
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote: Oswald: Are you trolling?
never. i am though! |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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.
|
| |
trident
Registered: May 2002
Posts: 81 |
The same book also defines the concept of interrupts. Does that mean that interrupts cannot exist outside of an operating system? |
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
within the PSPs operating system, every "task" is called "process". and they all live in the same memory space.
/o\ |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
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. |
| |
trident
Registered: May 2002
Posts: 81 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
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? :) |
| |
trident
Registered: May 2002
Posts: 81 |
Quote: 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? :)
Yeah, but how do you know if it really is a pushed status byte or just some random data that happens to look like a status byte? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
by pushing the status yourself? |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: 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.
You are wrong, the 6502 does have two operating levels, in the context of this subject. IRQ mode and the mainline mode. It's part of the status register. Note we are not mentioning the NMI here but that also interrupts the IRQ and mainline mode. The IRQ in the 6502 is level triggered and the NMI is edge triggered. There is a difference between instructions executed in IRQ mode and mainline mode. Between each instruction executed in IRQ mode there will not be any interruption by another IRQ whereas in mainline mode between each instruction the code can be interrupted. This fact is used by some multi-threading routines to get the context switch to work.
There is also a difference between code executed at reset time and that of IRQs. The reset forces the IRQ disable bit to be set which means the CPU ignores any IRQ request until the bit is cleared, of course.
It doesn't matter if code cannot tell where it was called from, this is what is known as a straw man logical fallacy, because the detection of the "source of execution" is irrelevant to being able to have an IRQ alter where the CPU resumes operation of mainline mode. My point made earlier still stands as being completely correct.
Also by setting or clearing the interrupt disable flag using SEI or CLI the code is actually causing he processor to switch between IRQ level to mainline operating level.
We can, for example, be in an IRQ, as part of the code we can use CLI followed by a series of NOPs which could then allow another IRQ to run again. This method is called a double IRQ which is useful for certain graphical tricks.
Then lets not forget the BRK instruction. On some 6502s if an NMI hits at the same time as a BRK then the BRK interrupt won't get executed. This bug highlights the operating level changes the CPU does internally.
Also in some 6502s there is a wait instruction, called WAI, which ensures that the processor is not in the middle of an instruction for when an IRQ needs to be services. This gets rid of the latency from signalling the IEQ nd the IRQ starting to be executed. This again highlights the internal operating level changes of the 6502. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
thats the biggest bullshit even in this topic I have read so far :D
WP:
"CPU modes (also called processor modes or CPU privilege levels, and by other names) are operating modes for the central processing unit of some computer architectures that place restrictions on the operations that can be performed by the process currently running in the CPU."
"At a minimum, any CPU with this type of architecture will support at least two distinct operating modes, and at least one of the modes will provide completely unrestricted operation of the CPU.
...
In kernel mode, the CPU may perform any operation provided for by its architecture. Any instruction may be executed, any I/O operation may be initiated, any area of memory may be accessed, and so on. In the other CPU modes, certain restrictions on CPU operations are enforced by the hardware. Typically certain instructions are not permitted, I/O operations may not be initiated, some areas of memory cannot be accessed etc. Usually the user-mode capabilities of the CPU are a subset of the kernel mode capabilities, but in some cases (such as hardware emulation of non-native architectures), they may be significantly different from kernel capabilities, and not just a subset of them.
At least one user mode is always defined, but some CPU architectures support multiple user modes, often with a hierarchy of privileges."
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
You are wrong and you are also using a straw man logical fallacy because I didn't write "privilege levels" I actually wrote "operating levels". When you use a straw man logical fallacy what you are doing is incorrectly restating a position into soemthing that is easily shown to be false and then refuting it, when actually you are not refuting the real position as stated.
The two terms are subtly different. *If* I had meant privilege levels I would have written it.
The 6502 has IRQ mode and non-IRQ mode operating levels, it is obvious and cannot be refuted since it is a fact. |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
Martin: I disagree with your comment about differents between code in main and IRQ modes and interrupts being generated. You have already stated interrupts can occur during IRQ - double interrupts often used for stable stable rasters. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
check again how 6502 works (in this case, differently than most other cpus), you can't fire another irq when the cpu is in irq mode :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Martin: I disagree with your comment about differents between code in main and IRQ modes and interrupts being generated. You have already stated interrupts can occur during IRQ - double interrupts often used for stable stable rasters.
No, read what I posted again. What actually happens in the double IRQ example I gave is that whatever is running in the mainline mode is interrupted by the IRQ. This sets the interrupt disable flag in the status. Then while running in IRQ mode the code executes "CLI followed by a series of NOPs which could then allow another IRQ to run again". By executing CLI the processor is switched from "not allowing IRQs mode" to "allowing IRQs mode". i.e. IRQ mode to mainline mode.
In effect using SEI puts the CPU in "not allowing IRQs mode" which is as we have termed it is "IRQ mode" for brevity. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
yeah, actually there arent just mainline and irq mode, there is carry set mode, overflow bit set mode, brk flag set mode, z flag set mode etc. count them yourself. the 6510 is actually like todays superscalar cpus. it can do multithreading, and verious privilige hierarchis, everything :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
thank god you are not trolling, i am! |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
That is different. IRQ effectively does a SEI for you. CLI just reverses it. It isn't a mode. It is a flag like Osawld has said. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
check again how 6502 works |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: That is different. IRQ effectively does a SEI for you. CLI just reverses it. It isn't a mode. It is a flag like Osawld has said.
It *is* a different operating mode or "operating level" as I use the term.
In one mode/level "the gap" between one instruction and another can be interrupted, by the IRQ line on the CPU being held low. In the other operating level/mode the IRQ line being held low will not interrupted the execution of the code in "the gap" between instructions.
I say "the gap" but really it happens at the fetch stage of the opcode.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
now define what do you mean under operating mode. as its generally used in the context I have copyed from WP for you above. also a special feature of different operating modes/privilege levels is that only the highest (kernel mode) level can change privilege. (otherwise it would be meaningless to force tasks into various modes, as they could break the mode) so in this context an irq shouldnt be able to do a cli itself. anyhow even if it couldnt do a cli it were just a dumb irq flag anyway which doesnt affects the cpu's behaviour like privilege modes do, irqs are irqs and not threads or a special privilege level or whatever the next zealot will come up with. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: It *is* a different operating mode or "operating level" as I use the term.
In one mode/level "the gap" between one instruction and another can be interrupted, by the IRQ line on the CPU being held low. In the other operating level/mode the IRQ line being held low will not interrupted the execution of the code in "the gap" between instructions.
I say "the gap" but really it happens at the fetch stage of the opcode.
for god's sake, read this, and stop talkign nonsense.
http://en.wikipedia.org/wiki/CPU_modes
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
no, the irq flag per se doesnt affect the cpu operation mode - it indicates what operation mode the cpu currently runs in though =P (and operation modes have little to do with privilegues. except privilegued modes are operation modes - but operation modes arent necessarily privilegued) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: for god's sake, read this, and stop talkign nonsense.
http://en.wikipedia.org/wiki/CPU_modes
That link does not disprove what I have been writing. By posting that link you are demonstrating that you do not understand the subtle differences, Groepaz pointed this out as well.
I already defined what is meant by "operating level" in posts 80 and 85. You are incorrectly conflating privilege level with operating level by introducing different terminology compared to what I have been using.
You need to completely ignore anything you have been writing about privilege levels because it is not relevant to what I have been posting.
|
| |
Skate
Registered: Jul 2003
Posts: 492 |
In PC world, if you need to add an FTP/HTTP component and if that component locks up your program while connecting/transfering data etc, it's time for you to learn about multi-threading. If you are using 6510, what are you going to do with it? You want to download something from a BBS while rotating a filled cube in the screen?
Of course I know multi-threading has many different use alternatives. But if you are thinking about an irq loader and an effect on the screen, what's new about this? why do we need to name it?
I don't agree with Oswald at some points but I can understand why he's fighting against naming this method "multi-threading". |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: In PC world, if you need to add an FTP/HTTP component and if that component locks up your program while connecting/transfering data etc, it's time for you to learn about multi-threading. If you are using 6510, what are you going to do with it? You want to download something from a BBS while rotating a filled cube in the screen?
Of course I know multi-threading has many different use alternatives. But if you are thinking about an irq loader and an effect on the screen, what's new about this? why do we need to name it?
I don't agree with Oswald at some points but I can understand why he's fighting against naming this method "multi-threading".
I remember I used multi-threading for a GUI OS on the 64 back in 1991 or '92, I can't remember exactly when. Back then I called it multitasking of course since that is what the Amiga called it.
This had memory management used to allocate memory for each process and when the "EXE" was loaded the OS would relocate the code for you.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: no, the irq flag per se doesnt affect the cpu operation mode - it indicates what operation mode the cpu currently runs in though =P (and operation modes have little to do with privilegues. except privilegued modes are operation modes - but operation modes arent necessarily privilegued)
http://en.wikipedia.org/wiki/Special:Search?search=operation+mo..
1st result: cpu modes on wiki
http://www.google.hu/search?q=operation+modes+cpu&ie=utf-8&oe=u..
1st result: cpu modes on wiki
the article says:
"CPU modes (also called processor modes or CPU privilege levels, and by other names) are operating modes for the central processing unit of some computer architectures that place restrictions on the operations that can be performed by the process currently running in the CPU." |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: That link does not disprove what I have been writing. By posting that link you are demonstrating that you do not understand the subtle differences, Groepaz pointed this out as well.
I already defined what is meant by "operating level" in posts 80 and 85. You are incorrectly conflating privilege level with operating level by introducing different terminology compared to what I have been using.
You need to completely ignore anything you have been writing about privilege levels because it is not relevant to what I have been posting.
oh my dear. read post #102 then. according to google & wp search engines operation modes == privileges and stuff.
I can also define that irqs are fruitcakes and then engage in endless stupid arguments, but how about just agreeing on what wp&google says?
running in an irq is not different in any way to normal "mode" anyway. I can sei/cli in both "modes" and there's no way to determine if the cpu is running in irq or "main program. thus 2 things that have nothing in difference are the same thing. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: I remember I used multi-threading for a GUI OS on the 64 back in 1991 or '92, I can't remember exactly when. Back then I called it multitasking of course since that is what the Amiga called it.
This had memory management used to allocate memory for each process and when the "EXE" was loaded the OS would relocate the code for you.
multithreading = "multitasking" within a task which is running in a multitasking enviroment.
read Wikipedia. it will help you clear up the mess in your head. |
| |
Skate
Registered: Jul 2003
Posts: 492 |
If some people agreed that multi-threading really possible on c64, then let's move this argument to the next level.
Should we call using 1541 for simultaneous calculations hyper-threading (if we use it the correct way)? |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Again Oswald what you are posting does not in any way disprove or refute what I have been posting, for the reasons already given "privilege levels" are not what I have been posting about. By posting those links you are again demonstrating that you don't know enough about the subject being discussed.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: oh my dear. read post #102 then. according to google & wp search engines operation modes == privileges and stuff.
I can also define that irqs are fruitcakes and then engage in endless stupid arguments, but how about just agreeing on what wp&google says?
running in an irq is not different in any way to normal "mode" anyway. I can sei/cli in both "modes" and there's no way to determine if the cpu is running in irq or "main program. thus 2 things that have nothing in difference are the same thing.
"according to google & wp search engines operation modes == privileges and stuff."
I wrote "operating levels". You were the one who started with all this modes stuff. I also definied that is meant by the term "operating levels" in the context of this topic in my earlier posts.
"running in an irq is not different in any way to normal "mode" anyway."
You are wrong, as already explained running with the interrupt disable flag set means that the flow of instructions cannot be interrupted by an IRQ. This is the key difference between the two 6502 operating levels.
Those links from Wikipedia are talking about something else and are not relevant to this specific topic.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
As for this comment: "I can sei/cli in both "modes" and there's no way to determine if the cpu is running in irq or "main program."
By executing sei or cli you are changing the operating level of the CPU between disabling or allowing the IRQ line to interrupt the instruction execution flow.
Perhaps you would like to try this simple program which demonstrates why you are wrong.
sei
php
pla
sta $0401
cli
php
pla
sta $0402
rts
Obviously this stores different values to $401 and $402 depending on what the interrupt disable bit says, this demonstrates how to detect if the CPU is currently in disable mode (IRQ mode) or IRQ enable (mainline mode).
"thus 2 things that have nothing in difference are the same thing."
Since the instruction execution changes if the interrupt disable bit is clear and the IRQ line goes low, then you're wrong.
Since your assumption is wrong, your conclusion is also wrong.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: If some people agreed that multi-threading really possible on c64, then let's move this argument to the next level.
Should we call using 1541 for simultaneous calculations hyper-threading (if we use it the correct way)?
if some people agreed that the earth is flat, then let's move this argument to the next level: why doesnt oceans poor down at the edges of the world ? there shoud be a ring of mountains to hold the water. yes! :) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: "according to google & wp search engines operation modes == privileges and stuff."
I wrote "operating levels". You were the one who started with all this modes stuff. I also definied that is meant by the term "operating levels" in the context of this topic in my earlier posts.
"running in an irq is not different in any way to normal "mode" anyway."
You are wrong, as already explained running with the interrupt disable flag set means that the flow of instructions cannot be interrupted by an IRQ. This is the key difference between the two 6502 operating levels.
Those links from Wikipedia are talking about something else and are not relevant to this specific topic.
you are right, you have wrote about operating levels, searching for that doesnt gives any clear definition, so lets play with your definition from now on:
"6502 does have two operating levels, in the context of this subject. IRQ mode and the mainline mode"
reading the status of the I flag doesnt helps. Since you can issue a SEI/CLI regardless you're in "irq" or "mainline" "mode", there's no way to tell the difference. you can never tell if the I flag was set by code or HW.
"Since the instruction execution changes if the interrupt disable bit is clear and the IRQ line goes low, then you're wrong."
that can be parodized nicely: since the instruction execution changes if the C/V/Z/M/B flag bit is clear then you're wrong. for example the code that has been jumped on by a BCC instuction is in 'c' bit set operating level. ;)
as there is no C/V/Z/M/B bit set/clear operating level on the 6510, so there is no I bit set/clear operating level.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: If some people agreed that multi-threading really possible on c64, then let's move this argument to the next level.
Should we call using 1541 for simultaneous calculations hyper-threading (if we use it the correct way)?
Hyper-Threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources. This allows a Hyper-Threading equipped processor to pretend to be two "logical" processors to the host operating system, allowing the operating system to schedule two threads or processes simultaneously |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
SEI does not change operating level. It only blocks IRQs. Interrupts can still happen - NMI. It is still an interrupt and can be used for task scheduling. |
| |
Skate
Registered: Jul 2003
Posts: 492 |
@Oswald: Hmmm, it seems like you have peeked at wikipedia for Hyper-Threading too ;)
Actually my comment was supporting yours more than others but you completely turned your shields on.
Btw, I'm actively using multi-threading in my professional life. I'm not talking theoretically. If something I said doesn't exactly match with a "wikipedia" definition, I don't give a shit. |
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
During this argument between modern supercoders, I have an irq of my own. Can someone please explain how a double irq works? Is it an interrupt within an interrupt or what? |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
Quote: During this argument between modern supercoders, I have an irq of my own. Can someone please explain how a double irq works? Is it an interrupt within an interrupt or what?
http://codebase64.org/doku.php?id=base:double_irq has some code. It is to make cycle exactle interrupts typically for raster effects/timing like VIC tricks. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: you are right, you have wrote about operating levels, searching for that doesnt gives any clear definition, so lets play with your definition from now on:
"6502 does have two operating levels, in the context of this subject. IRQ mode and the mainline mode"
reading the status of the I flag doesnt helps. Since you can issue a SEI/CLI regardless you're in "irq" or "mainline" "mode", there's no way to tell the difference. you can never tell if the I flag was set by code or HW.
"Since the instruction execution changes if the interrupt disable bit is clear and the IRQ line goes low, then you're wrong."
that can be parodized nicely: since the instruction execution changes if the C/V/Z/M/B flag bit is clear then you're wrong. for example the code that has been jumped on by a BCC instuction is in 'c' bit set operating level. ;)
as there is no C/V/Z/M/B bit set/clear operating level on the 6510, so there is no I bit set/clear operating level.
You are wrong because reading the interrupt disable flag does allow the code to detect what operating level it is running in. This refutes your earlier statement "I can sei/cli in both "modes" and there's no way to determine if the cpu is running in irq or main program."
Obviously because the code can determine what operating level it is running in.
Being able to change between the two operating levels by using SEU/CLI is irrelevant to the point I am making. It is also irrelevant, to the point that I am making, that it is not possible to detect if the interrupt disable flag is set by software or hardware.
Since it is shown how you are wrong in the first part of your post now we get onto why you are wrong in the second half.
If you again read post 95 then it is clear that the intruction execution changes are related to the opcode fetch and the state of the IRQ line combined with the interrupt disable flag. Therefore your point about the C/V/Z/M/B and the branches is a red herring logical fallacy. You are also wrong because you are not accounting for the definition of operating level as defined in the scope of this topic.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: SEI does not change operating level. It only blocks IRQs. Interrupts can still happen - NMI. It is still an interrupt and can be used for task scheduling.
"Operating level" in the context of this topic is defined in post 80 as "One level is when it is executing an IRQ. The other not running an IRQ, we will call this the mainline."
Then if you read post 85 I specifically mention "Note we are not mentioning the NMI here but that also interrupts the IRQ and mainline mode."
So by saying "It [SEI] only blocks IRQs" means that SEI does change the operating level as defined in the scope of this topic.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
here's your definition wisey:
"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."
as you cannot decide based on the I bit or whatever, wether cpu is executing an irq or not, you dont have two operating whatevers, as when two whatever cannot be told appart its the same whatever. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: @Oswald: Hmmm, it seems like you have peeked at wikipedia for Hyper-Threading too ;)
Actually my comment was supporting yours more than others but you completely turned your shields on.
Btw, I'm actively using multi-threading in my professional life. I'm not talking theoretically. If something I said doesn't exactly match with a "wikipedia" definition, I don't give a shit.
you're using a term wrong then, according to WP and the current scientific and academic views. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote:
here's your definition wisey:
"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."
as you cannot decide based on the I bit or whatever, wether cpu is executing an irq or not, you dont have two operating whatevers, as when two whatever cannot be told appart its the same whatever.
As shown it is possible to detect the state of the interrupt disable flag.
As I have already said it is completely irrelevant, for my point, to be able to detect if the interrupt disable flag is set from the result of an interrupt or as the result of SEI.
Just so you are clear, what you wrote does not matter and does not refute what I have been posting.
So, as defined in posts 80 and 85 and in the context of this topic there are therefore two operating levels.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: you're using a term wrong then, according to WP and the current scientific and academic views.
You've not shown anything like that to be able to make such a claim. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"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."
read your definition again. how many times must I tell you the same thing? you cannot decide wether you are running irq or not, so u have no 2 op modes. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: You've not shown anything like that to be able to make such a claim.
I have quoted various sources upon what is multithreading. you have not. now rethink: who has the abilities to make such claims? |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: "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."
read your definition again. how many times must I tell you the same thing? you cannot decide wether you are running irq or not, so u have no 2 op modes.
And again I will point you to post 85 which clarifies the situation and those terms as "IRQ mode and the mainline mode" and also "Also by setting or clearing the interrupt disable flag using SEI or CLI the code is actually causing he processor to switch between IRQ level to mainline operating level."
So like I have been saying you are wrong to keep on ignoring posts 80 and 85.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: I have quoted various sources upon what is multithreading. you have not. now rethink: who has the abilities to make such claims?
You may have quoted the sources but your interpretation is flawed. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: And again I will point you to post 85 which clarifies the situation and those terms as "IRQ mode and the mainline mode" and also "Also by setting or clearing the interrupt disable flag using SEI or CLI the code is actually causing he processor to switch between IRQ level to mainline operating level."
So like I have been saying you are wrong to keep on ignoring posts 80 and 85.
so lets see your post #80
"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."
irq mode = running an irq
mainline mode = not running an irq
its crystal clear. your own stupid definition. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: You may have quoted the sources but your interpretation is flawed.
show me where. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: so lets see your post #80
"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."
irq mode = running an irq
mainline mode = not running an irq
its crystal clear. your own stupid definition.
Again you are ignoring what was written in post 85.
The two operating levels are "IRQ mode and the mainline mode". This means "by setting or clearing the interrupt disable flag using SEI or CLI the code is actually causing he processor to switch between IRQ level to mainline operating level."
So you are wrong, again. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: show me where.
For example when you keep on writing about privilege levels (post 96 is a good example), when it is irrelevant to this topic. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: Again you are ignoring what was written in post 85.
The two operating levels are "IRQ mode and the mainline mode". This means "by setting or clearing the interrupt disable flag using SEI or CLI the code is actually causing he processor to switch between IRQ level to mainline operating level."
So you are wrong, again.
then decide for god's sake, post #80 or #85 should be taken from you seriously? they are defining operating levels differently. one saying it is running or not running an irq, the other its the state of the I flag.
which of #80 or #85 post should be taken as your definition then? and which of the rest of your posts is bullshitting and which one is not ? |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: then decide for god's sake, post #80 or #85 should be taken from you seriously? they are defining operating levels differently. one saying it is running or not running an irq, the other its the state of the I flag.
which of #80 or #85 post should be taken as your definition then? and which of the rest of your posts is bullshitting and which one is not ?
It is very simple, you take both posts as part of my definition because post 85 follows on from post 80. Read post 80 first and then if you are still confused then you read post 85.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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: 5031 |
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: 647 |
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: 5031 |
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: 647 |
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: 647 |
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: 5031 |
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: 647 |
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: 5031 |
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: 647 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:
Gregg you are correct, Oswald is wrong. It's obvious to me now that he is just trolling.
no, i am! tststs |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Martin, can you bring two definitions from a "realiable" source about what is multitasking and what is multithreading, and tell me what's the difference between them ?
then can you show me based on the definitions that how's gregg's code a multithreading?
thanks. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
google: difference multithreading multitasking
first hit:
"Multitasking is running multiple "heavyweight" processes (tasks) by a single OS.
Multithreading is running multiple "lightweight" processes (threads of execution) in a single process / task / program. See What is the difference between a lightweight and a heavyweight process:
...
--->
Answer
[Short answer: threads are lightweight, programs (aka processes or tasks) are heavyweight. -Alex]
Lightweight and heavyweight processes refer the mechanics of a multi-processing system.
In a lightweight process, threads are used to divvy up the workload. Here you would see one process executing in the OS (for this application or service.) This process would posess 1 or more threads. Each of the threads in this process shares the same address space. Because threads share their address space, communication between the threads is simple and efficient. Each thread could be compared to a process in a heavyweight scenario.
What is the difference between a thread and a process?
--->
Answer
A process is an OS-level task or service. A thread runs "inside" a process and may be virtual or simulated. Generally speaking, threads share resources like memory, where processes each have their own separate memory area, and need to take more elaborate steps to share resources."
is this reliable enough? gregg havent implemented processes, thus he cant have threads either. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
2nd hit:
http://zone.ni.com/devzone/cda/tut/p/id/6424
"Multithreading extends the idea of multitasking into applications, so you can subdivide specific operations within a single application into individual threads."
3rd hit:
"Multithreading is the ability of a program or an operating system process to manage its use by more than one user at a time and to even manage multiple requests by the same user without having to have multiple copies of the program running in the computer"
http://wiki.answers.com/Q/What_is_difference_between_multiprogr..
4ht hit:
"Multitasking is the ability of an operating system to execute more than one program simultaneously. Though we say so but in reality no two programs on a single processor machine can be executed at the same time. The CPU switches from one program to the next so quickly that appears as if all of the programs are executing at the same time. Multithreading is the ability of an operating system to execute the different parts of the program, called threads, simultaneously."
gregg's program doesnt fullfill any of the above.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
http://en.wikipedia.org/wiki/Thread_(computer_science)
"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."
http://www.allinterview.com/showanswers/4943.html
"multitasking infers the mechanism to run many processes
simultaneously with user interaction. in contrast, multithreading is a mechanism of running various threads under single process within its own space."
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
This is a classic example of you not understanding the sources you cite. This is because what you cite and what you highlight in bold proves my point and disproves what you wrote earlier.
From your own quote:
"Multi-threading is running multiple "lightweight" processes (threads of execution) in a single process / task / program."
"Multitasking is running multiple "heavyweight" processes (tasks) by a single OS."
Since it can be argued that Gregg's code doesn't handle more heavyweight process switching with threads inside each process, i.e. a hierarchy of preemptive systems whereby the lightweight threads operate inside the more heavyweight tasks, then the definition of multi-threading suits Gregg's code better than the term multi-tasking.
Just so you are clear: Multi-tasking is what my OS code was doing because it had the ability to have threads inside each process and each process had its own address area dynamically allocated in memory.
Just so you are also clear: First comes multi-threading, it is more lightweight because the threads operate within the context of a process. Then comes multi-tasking, it is more heavyweight since it has the concept of processes which also can have their own threads operating inside each process.
For example:
Multi-threading:
3 threads
No extra processes. Just one large process.
Multi-tasking:
Process1.exe - 3 threads - Thread1Foo, Thread2Bar, Thread3Render
Process2.exe - 2 threads - SoundThread, VideoThread
Process3.exe - 7 threads - Thread1, Thread2, thread3 ...
In the land of PCs we use the term multi-threaded application, we don't use the term multi-tasking application. We do apply multi-tasking to the OS because the OS handles different processes, which each process capable of having its own threads.
Just so you are really clear: Gregg's code fits the definition of multi-threading a lot better than the definition of multi-tasking. |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
Looks like you're having a lot of fun here! :D |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"Since ... Gregg's code doesn't handle more heavyweight process switching with threads inside each process"
exactly. that is the key. gregg's code implements a one level hierarchy which is multitasking - without multithreading. multithreading means a 2 level hierarchy: process switching with thread switchings inside each process. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: "Since ... Gregg's code doesn't handle more heavyweight process switching with threads inside each process"
exactly. that is the key. gregg's code implements a one level hierarchy which is multitasking - without multithreading. multithreading means a 2 level hierarchy: process switching with thread switchings inside each process.
No, you have it the wrong way around, again.
Multi-threading refers to the threads inside a process. In Gregg's code there is one process that has inside it multiple threads.
Multi-tasking refers to having multiple processes and each process being capable of having multiple threads. Gregg's code does not support a hierarchy.
A single array of threads is multi-threading. This is because, as your links say, multi-threading is more lightweight.
From your own links (I'll remove the words that are confusing you and leave the quotes with the words that make it obvious):
"Multi-threading is running multiple lightweight threads of execution in a single process/program." - Gregg's code - Single array of threads.
"Multi-tasking is running multiple heavyweight processes by a single OS." - Not Gregg's code - An array of processes that each can have an array of threads.
Hence why we say multi-threaded application and multi-tasking OS.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
http://en.wikipedia.org/wiki/Process_%28computing%29
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.
as gregg's code can not run several processes (and threads inside them) it does not do multithreading.
furthermore:
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.
I can see no formal definition of a process in gregg's code. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: http://en.wikipedia.org/wiki/Process_%28computing%29
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.
as gregg's code can not run several processes (and threads inside them) it does not do multithreading.
furthermore:
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.
I can see no formal definition of a process in gregg's code.
Again you have it the wrong way around.
Multi-threading = Gregg's code because it does not support multiple processes that can have threads threads. No hierarchy.
Multi-tasking = Multiple processes that can support multiple threads. A hierarchy.
Because there is no "formal definition of a process in Gregg's code" that means it is doing multi-threading because it has one process with multiple threads inside that one process.
Again this is from your own post:
"Multi-threading is running multiple lightweight threads of execution in a single program."
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Even the link you cite proves you are wrong.
"A process may split itself into multiple 'daughter' ... threads"
It cannot be any simpler. Threads live inside processes. This is multi-tasking.
Processes can be multi-tasked.
http://en.wikipedia.org/wiki/Computer_multitasking
"multitasking is a method by which multiple ... processes ... share common processing resources such as a CPU."
This is multi-tasking.
Therefore in multi-tasking you have multiple processes which can each have multiple threads running inside each process.
It looks like this:
"OS" -> Processs -> Threads
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Gregg's code is not a collection of processes, this is because processes are generally defined as independant programs that are in their own address space and interact only through OS calls. This means Gregg's code is not multi-tasking.
Gregg's code is a collection of threads (two threads to be exact) where the code is in the same address space. Because Gregg's code only has a one dimensional list of threads this means it is multi-threading.
If Gregg's code had a two dimensional array of threads, where each process could have its own block of threads, this would be multi-tasking.
This disproves what you have been posting. Especially since your own links disprove what you have been posting. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
This quote from you explains exactly why you get it completely wrong:
"gregg havent implemented processes, thus he cant have threads either."
This is because the quote you cited from one link disproves your statement:
"Multithreading is running multiple lightweight threads of execution in a single process / task / program."
Note it says "single process/task/program". This means it is not mandatory to have support for multiple processes to be able to have support for threads. Threads can happily exist in one program or bit of code. This means no hierarchy. Gregg's code is one program. This is called multi-threading.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"Multi-threading = Gregg's code because it does not support multiple processes that can have threads threads. No hierarchy."
no hierarchy = multitasking without multithreading
hierarchy = multitasking with multithreading
there's NO multithreading WITHOUT multitasking.
threads are defined as something thats inside processes, and there are no processes without multitasking:
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.
"Multi-tasking = Multiple processes that can support multiple threads. A hierarchy."
nope. multitasking may be or may not be multithreading. multitasking doesnt support multithreading by definition. see Amiga OS for example. it is a preemptive multitasking OS without threads.
"that means it is doing multi-threading because it has one process with multiple threads inside that one process."
process cannot be defined as a process in a non multitasking but multithreading system. see above. processes are part of multitasking systems.
"Again this is from your own post:
"Multi-threading is running multiple lightweight threads of execution in a single program.""
...which program runs in a multitasking enviroment. as threads are inside processes and processes are inside multitasking OS-es. see the definitions I have quoted.
"Therefore in multi-tasking you have multiple processes which can each have multiple threads running inside each
process."
WRONG. see Amiga OS and similar again. first there was multitasking without threads. and only later were threads invented.
"It looks like this:
"OS" -> Processs -> Threads"
AmigaOS == multitasking: OS -> Process. end of story.
"Gregg's code is not a collection of processes, this is because processes are generally defined as independant programs that are in their own address space and interact only through OS calls. This means Gregg's code is not multi-tasking."
then its neither multitasking nor multithreading. I can live with that.
"Gregg's code is not a collection of processes"
fine. that means it cant have threads either. as threads are inside processes. no process - no threads.
"Gregg's code is a collection of threads (two threads to be exact) where the code is in the same address space."
cant be threads either. threads have their own stack. gregg's threads are sharing the same stack.
"If Gregg's code had a two dimensional array of threads, where each process could have its own block of threads, this would be multi-tasking"
Amiga OS.
"This disproves what you have been posting. Especially since your own links disprove what you have been posting."
not at all. only shows your lack of knowledge. multithreading is not a must for multitasking. see Amiga OS.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: This quote from you explains exactly why you get it completely wrong:
"gregg havent implemented processes, thus he cant have threads either."
This is because the quote you cited from one link disproves your statement:
"Multithreading is running multiple lightweight threads of execution in a single process / task / program."
Note it says "single process/task/program". This means it is not mandatory to have support for multiple processes to be able to have support for threads. Threads can happily exist in one program or bit of code. This means no hierarchy. Gregg's code is one program. This is called multi-threading.
"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."
no support for multiple processes = no processes. no processes = no threads.
btw,
"It looks like this:
"OS" -> Processs -> Threads"
and in your dream it looks like this: -> threads. are you really so sure that does make any sense?
you either have OS -> Process -> Threads
or OS -> process (amiga)
or OS (c64)
but this is just silly : -> threads.
|
| |
Skate
Registered: Jul 2003
Posts: 492 |
actually multi-threading can exist without multi-tasking. but there is no OS exists using multi-threading and not multi-tasking. this is why Oswald is confused. he still thinks that 9th sprite cannot be shown in a raster line ;)
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. for example if two of your applications (processes) are using sprites, you need to switch all sprite specific addresses ($d000-$d02f, SCREEN_MEMORY+$3f8-SCREEN_MEMORY+$3ff etc.) automaticly each time you switch between processes. "different processes must not affect each other!!!" this is why these documents say "multi-tasking is OS based". actually you don't need an OS for multi-tasking. But when you write these kind of process switch handling routines, it means that you've deleloped a very big structure of an OS.
I hope you have a more clear view about this now. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: actually multi-threading can exist without multi-tasking. but there is no OS exists using multi-threading and not multi-tasking. this is why Oswald is confused. he still thinks that 9th sprite cannot be shown in a raster line ;)
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. for example if two of your applications (processes) are using sprites, you need to switch all sprite specific addresses ($d000-$d02f, SCREEN_MEMORY+$3f8-SCREEN_MEMORY+$3ff etc.) automaticly each time you switch between processes. "different processes must not affect each other!!!" this is why these documents say "multi-tasking is OS based". actually you don't need an OS for multi-tasking. But when you write these kind of process switch handling routines, it means that you've deleloped a very big structure of an OS.
I hope you have a more clear view about this now.
Yes, that is exactly the reason why Oswald is confused.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Oswald your examples of Amiga OS are wrong because each process can have threads inside it, if the code is written to support it. Another example would be my pthread library for RISC OS which allowed pre-emptive multithreading inside each task where each task has its own memory mapped space from the MMU. The point being that the support for each process in the OS is heavyweight enough to allow each process to have its own threads, either from the OS or by using its own interrupts, if needed. 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.
Oswald, in post 144 you quoted:
"Multitasking is running multiple "heavyweight" processes (tasks) by a single OS."
And:
"Multithreading is running multiple "lightweight" processes (threads of execution) in a single process / task / program. See What is the difference between a lightweight and a heavyweight process:"
Do you agree that the terms lightweight refers to multi-threading and that heavyweight refers to multi-tasking?
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
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?
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
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.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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 .)) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
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.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
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.
|
| |
Skate
Registered: Jul 2003
Posts: 492 |
@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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Oswald: The Amiga OS and RISC OS do have processes that can support multi-threading though because their multi-tasking is sufficiently heavyweight to allow it. So you are still wrong.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
so, and are you sure that Amiga OS's tasks which are like the threads of OS/2 can support threads ? can you cite any definition of multitasking which makes it a neccesity that multitasking = ability to support threads? :) You CANT. its your stupid definition.
also telling me that I am confused and I am wrong does not proove anything. try reasoning that will help :)
the meaning of heavyweight and lightweight cannot be seriously interpreted without the context of an OS. as I already told you whats a heavyweight task in AmigaOS is a lightweight thread in OS/2.
"You are also wrong because you misquote what I have been writing. What I hacve been writing is this:"
I have only quoted what you have written: there's no misquoting in it
"Multi-tasking = Multiple processes that can support multiple threads. A hierarchy."
and there's nothing in the same post of the above quote you are trying now to make up was beside this sentence, in other words: you are lying again.
"This also shows why you are wrong because the definition of hierarchy is wider than just your misquote."
if the quote is wrong then YOU are wrong, because it was written by YOURSELF and not by me. liar.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Skate, you example were only correct if your example processes were interacting through resource allocators and graphics drivers with sprites. examples can be wrong just like real life.
"Proofs? :) "
or aguments, whatever.
sentences like "oswald is wrong, x is not y but z" is not arguable. and I dont want to be involved in discussions like:
- x is y
- no x is z
- no x is y
- no x is z
etc. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Oswald, the whole of your posts show why you are wrong because what you are writing contradicts the links you have been posting.
You said "try reasoning that will help". The point is many other posters have tried reasoning with you and what you do is still keep on repeating your same mistaken assumptions and posting the same links that disprove what you are writing.
It is very obvious that you are confused and you are wrong.
|
| |
Skate
Registered: Jul 2003
Posts: 492 |
@Oswald: This is my last post in this discussion. And I'm not writing anything against yours or anyone else's idea. I've already written what I know, what I think of. Now it's time for me to fuck off. Have fun... |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: @Oswald: This is my last post in this discussion. And I'm not writing anything against yours or anyone else's idea. I've already written what I know, what I think of. Now it's time for me to fuck off. Have fun...
Oswald is now using personal attacks because he knows his argument has failed and he knows he is wrong. He just doesn't want to admit it.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
atleast he isn't trolling (like me) |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Cant someone explain the difference between threads and processes, please? |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
I just checked the thread, those disagreeing with what Oswald writes are: Trident, Krill, Gregg, JackAsser, Skate and myself.
Those agreeing with Oswald are: *sound of crickets*
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Cant someone explain the difference between threads and processes, please?
It is generally accepted that multiple threads can live inside one process.
In MS Windows terms, a process is what you get when you run an EXE. This process can have one or more threads running. Hence you see a hierarchy of processes owning their own threads.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
the difference can only be explained in the context of the execution environment. (to pull my example again, in the OS of the PSP, everything is a "process". a comparable thing with similar properties in the context of a unixish OS would only qualify as a thread) |
| |
Trash
Registered: Jan 2002
Posts: 122 |
I guess my ironi tags became hidden...
My personal definition of a thread is that it is a process making some sort of work for the mainprocess. A process is for me a loop that executes somekind of code and it's also able to delegate jobs to other processes in form of threads.. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"Cant someone explain the difference between threads and processes, please?"
"the difference can only be explained in the context of the
execution environment."
--> as gregg's code doesnt implement execution enviroment it cannot be said wether it is multitasking or multithreading.
which is the same I keep telling here: if you dont define process: you have no processes -> without process you cant define threads.
like in maths for the concept of complex numbers you need to define: natural numbers -> negative numbers -> rational numbers -> irrational numbers -> complex numbers.
without defining first negative, rational, etc numbers complex numbers cannot be defined. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:
as gregg's code doesnt implement execution enviroment it cannot be said wether it is multitasking or multithreading.
LOL. how exactly would that code code run at all if there is no execution environment?
you.are.confused. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: Oswald, the whole of your posts show why you are wrong because what you are writing contradicts the links you have been posting.
You said "try reasoning that will help". The point is many other posters have tried reasoning with you and what you do is still keep on repeating your same mistaken assumptions and posting the same links that disprove what you are writing.
It is very obvious that you are confused and you are wrong.
"Multi-tasking = Multiple processes that can support multiple threads. A hierarchy."
still waiting you quoting a reliable source which states the same.
no 2 level hierarchy of processes/threads means multitasking without multithreading not what gregg's doing or you trying to force. threads without processes simply make no sense. by definition threads are parts of processes and by definition processes are part of multitasking capable OSes.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: Quote:
as gregg's code doesnt implement execution enviroment it cannot be said wether it is multitasking or multithreading.
LOL. how exactly would that code code run at all if there is no execution environment?
you.are.confused.
you said that processes and threads cannot be told appart without execution enviroment. I have assumed you are using "execution enviroment" in the sense of an OS. Since you have even brought an example where you compared 2 OS as execution enviroments. Hardware may be looked at like an execution enviroment, but the cpu/ram/bus/hdd type alone wont help tell apart threads and processes imho. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
you are, again, assuming too much and drawing conclusions from said assumptions. "execution environment" has nothing to do with OS, threads, processes - or even computers per se. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"Cant someone explain the difference between threads and processes, please?"
groepaz: "the difference can only be explained in the context of the execution environment."
groepaz: " "execution environment" has nothing to do with ... threads, processes "
conclusion: the difference between threads and proccesses can only be explained only in the context of the execution enviroment which has nothing to do with threads, processes.
thats supposed to make some sense?
what is this magical execution enviroment, it has nothing to do with processes and threads, still in its context the difference can be told between processes and threads? can you define this magical concept for me? :)
|
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
I've been thinking about this for a while now and without citing neither Google nor Wikipedia nor refer to any textbook I came to my personal conclusion which is ofcource highly subjective:
The C64 clearly has an OS. This OS takes care of IO, keyboard, cursor blink, screen scrolling and even some rudimentary memory managment if you consider the built in BASIC.
Natrually I consider this a non multitasking OS despite it being capable of f.e. formatting a disk while allowing the user to type in BASIC code. I consider it non multitasking because there are no OS-calls to create new processes. Only replace the one and only existing via LOAD+RUN.
Still this one and only process can very well use the OS to hook its own timer IRQ and implement threading by simple context switching and still be friend with the OS. This kind of threading is normally called green threads, i.e. threads implemented non OS-code.
So to conclude what I consider:
* The KERNEL is an OS.
* The OS is non multitasking allowing only one process.
* _THE_ process can implement threads any way it wants.
What do you guys think? Did I put more wood in the fire now?! ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:
conclusion: the difference between threads and proccesses can only be explained only in the context of the execution enviroment which has nothing to do with threads, processes.
thats supposed to make some sense?
no, your conclusion, again, doesnt make sense. |
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
Quote: Quote:
conclusion: the difference between threads and proccesses can only be explained only in the context of the execution enviroment which has nothing to do with threads, processes.
thats supposed to make some sense?
no, your conclusion, again, doesnt make sense.
ROFL. OK. ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
its not my conclusion. its your sentences concatenated after each other:
"the difference can only be explained in the context of the execution environment. "execution environment" has nothing to do with OS, threads, processes - or even computers per se."
now define execution enviroment, or you still wanna play this childish game giving it different meanings each post just to contradict my reasonings? :) come on.
oh one more contradiction:
"LOL. how exactly would that code code run at all if there is no execution environment?" "execution environment" has nothing to do with OS, threads, processes - or even computers per se."
what's all this bullshit dear groepaz? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
the execution environment, as the name says, defines the environment code is executed under. it can be anything, a piece of paper, a cpu with some ram, a c64 - with or without it's OS -, or a fully fledged operating system, or even a process within said operating system. threads or processes are not needed, nor relevant, to define a execution environment. there dont have to be threads or processes for an execution environment to exist.
however, there CAN be processes and threads in a execution environment. if your execution environment is windows, THEN the execution environment (for a thread) involves a process, and the execution environment for said process involves a multitasking OS/sheduler/whateveryouwanttocallitidontcare. if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads.
and thats why you must first define what the execution environment is before you can define other things which live in said environment. depending on the environment the distinction between processes and threads can't be made, because no such hirarchic distinction exists (and infact, they are sometimes called processes, and sometimes called threads in such environments, although the same thing is described).
this is also pretty much the source of your confusion. you are drawing conclusions from definitions made in the execution environment of a multitasking operating system, and apply them to a barebones embedded system without one.
or to quote your favourite example: when the sky is blue, drawing the conclusion that everything that is blue must be somehow related to sky is... you know the word.
|
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
I asked a colleague of mine, who is known as an expert in this field (multi threading, concurrency) to read this thread and give me his opinion about it. This is a guy who published articles on this subject for serious sites like serverside.com.
His conclusion is that all of you are crazy and by proxy, so am I. He even asked me if it wasn't time for us to move on to, oh, the amiga for example?
So thank you guys, thank you for making me look bad! ;)
Seriously though, insults notwithstanding, I kinda like this discussion, one of the more interesting ones here in a long time. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"this is also pretty much the source of your confusion. you are drawing conclusions from definitions made in the execution environment of a multitasking operating system, and apply them to a barebones embedded system without one."
exactly. processes & threads are by definition entitys inside the exectution enviroment of a multitasking OS. Its not me who tries to apply them to a barebone system, I am saying that the concepts thread&process does make no sense without the execution environment of a multitasking OS. or more correctly: a thread does make no sence without the execution enviroment of its process.
I have already said this in post #42:
"you are forcing strict operating system terms into a context where there is literally no operating system.
threads lives inside processes, and processes lives inside operating systems. the term process/task&thread is meaningless without the context of an operating system" |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Not correct Oswald because threads can exist in processes or task or a program. (From your cite in post 144). In this case Gregg's example is a single process or a program. It does not need an OS with multiple processes to be able to implement multi-threading. All that matters here is that Gregg's code implements lightweight switching of a his program which is multi-threading, as per the definition contained in the links you provided. All the links you posted show you are wrong because your interpretation of those links is flawed because you are getting confused about what is a heavyweight process and what is a lightweight thread within a process.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:
processes & threads are by definition entitys inside the exectution enviroment of a multitasking OS.
no, not at all. the common way of explaining them involves a multitasking os, thats true. the sky is blue, but not everything blue is sky.
Quote:
threads lives inside processes, and processes lives inside operating systems. the term process/task&thread is meaningless without the context of an operating system"
and no matter how often you repeat it, it doesnt get more true.
one day you should talk to someone who has actual experience with embedded systems. don't show him this thread though, unless you like to get bitchslapped =P
|
| |
Frantic
Registered: Mar 2003
Posts: 1633 |
This topic is closed. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: This topic is closed.
If only that were true, but Oswald still keeps on trolling. ;)
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: Not correct Oswald because threads can exist in processes or task or a program. (From your cite in post 144). In this case Gregg's example is a single process or a program. It does not need an OS with multiple processes to be able to implement multi-threading. All that matters here is that Gregg's code implements lightweight switching of a his program which is multi-threading, as per the definition contained in the links you provided. All the links you posted show you are wrong because your interpretation of those links is flawed because you are getting confused about what is a heavyweight process and what is a lightweight thread within a process.
Not correct Martin because threads can only exist in processes or task or a program. (From my cite in post 144). In this case Gregg's example is not a single process or a program. It does need an OS with multiple processes to be able to implement multi-threading. All that matters here is that Gregg's code doesnt implements processes of a his program which is not multi-threading, as per the definition contained in the links I provided. All the links I posted show you are wrong because your interpretation of those links is flawed because you are getting confused about what is a heavyweight process and what is a lightweight thread within a process. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
It is obvious to everyone reading this thread that you are trolling because you know you are wrong but you don't want to admit it. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
It is obvious to everyone reading this thread that you are trolling because you know you are wrong but you don't want to admit it. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
"if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads."
gregg's example uses the c64 as an embedded system without an os per se. so based on groepaz' words:
->you are wrong-> you know you are wrong -> you are trolling. live with it :)
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: Quote:
processes & threads are by definition entitys inside the exectution enviroment of a multitasking OS.
no, not at all. the common way of explaining them involves a multitasking os, thats true. the sky is blue, but not everything blue is sky.
Quote:
threads lives inside processes, and processes lives inside operating systems. the term process/task&thread is meaningless without the context of an operating system"
and no matter how often you repeat it, it doesnt get more true.
one day you should talk to someone who has actual experience with embedded systems. don't show him this thread though, unless you like to get bitchslapped =P
"no, not at all. the common way of explaining them involves a multitasking os, thats true. the sky is blue, but not everything blue is sky."
the terms/concepts process/thread originate from multitasking OSes. Multitasking OSes invented them. Thread as a concept has evolved and born from the concept of the process. Threads furthermore are the result also of the modern cpu design as they can use their pipeline and other parallel parts more efficient running threads. when one thread has a cache miss, then the other one gets scheduled for example. then there is SMT simultaneuos multi threading which means truly parallel execution of threads.
threads in todays world are anything but changing return values in a stack manually.
"and no matter how often you repeat it, it doesnt get more true."
is that an argument?
"one day you should talk to someone who has actual experience with embedded systems. don't show him this thread though, unless you like to get bitchslapped =P"
"if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads"
seems you're gonna be bitchslapped.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11154 |
Quote:
"if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads"
seems you're gonna be bitchslapped.
you are still thinking that because the sky is blue, everysthing blue must be sky.
just because there are no threads or processes in your execution environment it doesn't mean threads can not exist within said environment.
anyway, feel free to go on drawing your false conclusions. i'll try my best not to post anymore in this thread, its futile anyways and everything has been said twice anyway.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Oswald you wrote: "gregg's example uses the c64 as an embedded system without an os per se."
You are wrong on at least two counts here.
Firstly:
Gregg's example code (post 6) uses an OS, the ones defined in memory locations $a000-$bfff and $e000-$ffff, then demonstrates multi-threaded operation by using an interrupt to alter the flow of the mainline operating context at regular intervals.
Unless you can prove that Gregg's code (post 6) doesn't use BASIC and doesn't use locations $0314 and $0315. Unfortunately for you you cannot prove that because as you might know the contents of $0314/$0315 get used by $ff58 JMP ($0314). $ff58 of course just happens to be in the C64's KERNAL, which is one part of the C64's OS.
Secondly, Groepaz's comment you quoted does not support your case, in actual fact it tells you why you are wrong. This is because it says:
"if your execution environment is an embedded system without an os per se, then the execution environment does NOT involve processes nor threads."
The C64 is not an embedded system without an OS, the C64 is a personal computer with two ROMs that comprise its OS. I know you seem to love Wikipedia so I'll cite the link for you. http://en.wikipedia.org/wiki/Embedded_system
Note the bit on that page that has "personal computer" linked? Good, I'm glad. Now you will admit you are wrong.
Also note the use of the word "if" used by Groepaz. It isn't saying "the C64 is an embedded system", it is saying "if your execution environment is an embedded system without an OS per se" and that is a very obvious difference.
Thirdly, Gregg's example code can be thought of as part of an OS that specifically deals with lightweight mutli-tasking, even if the code is tiny it can still be thought of as part of an OS, so that means you are wrong Oswald.
Fourthly, Groepaz goes on to say:
"this is also pretty much the source of your confusion. you are drawing conclusions from definitions made in the execution environment of a multitasking operating system, and apply them to a barebones embedded system without one."
As Groepaz says, you are confused Oswald because you are making faulty assumptions and reaching incorrect conclusions.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
10 PRINT "BY DEFINITION THREADS ARE PARTS OF PROCESSES AND PROCESSES ARE PARTS OF MULTITASKINS OSES";
20 GOTO 10
"anyway, feel free to go on drawing your false conclusions. i'll try my best not to post anymore in this thread, its futile anyways and everything has been said twice anyway."
|
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
All this arguing and it is still not clear who is correct. How can one conclude anything when both arguing parties are "right"? Can't! Is there someone else, who can clarify this subject for sure? |
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
Quote: All this arguing and it is still not clear who is correct. How can one conclude anything when both arguing parties are "right"? Can't! Is there someone else, who can clarify this subject for sure?
I can clarify. You are all idiots. |
| |
trident
Registered: May 2002
Posts: 81 |
Having read the last few days of posts, the problem isn't that anyone is completely incorrect here - Oswald is correct in many ways - the problem is that these concepts are inherently difficult.
The important thing to realize is that there is nothing magical about these concepts: an operating system is not a magical entity, it is just another program. A process is just a convenient definition that does not necessarily have anything to do with operating systems, but that also has changed its meaning over the years. Wikipedia is not the authoritative source. Multithreading is nothing to brag about, it is just another programming tool.
There is only one really good way to grasp these things: read a couple of good books on the subject of programming and operating systems (Knuth, Tanenbaum, Silberschatz/Galvin are good names to know), read a couple of good books on concurrent programming languages, write a couple of operating systems, write a couple of multithreading libraries, write a couple of compilers, learn how different CPU architectures work by doing low-level programming on them, step-by-step debug multithreaded code in a debugger, design a CPU architecture and think about interrupt handling and stacks, and constantly challenge your own presumptions. After doing this a few times one usually finds out that these concepts are not as easy and clear as one initially thought :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Having read the last few days of posts, the problem isn't that anyone is completely incorrect here - Oswald is correct in many ways - the problem is that these concepts are inherently difficult.
The important thing to realize is that there is nothing magical about these concepts: an operating system is not a magical entity, it is just another program. A process is just a convenient definition that does not necessarily have anything to do with operating systems, but that also has changed its meaning over the years. Wikipedia is not the authoritative source. Multithreading is nothing to brag about, it is just another programming tool.
There is only one really good way to grasp these things: read a couple of good books on the subject of programming and operating systems (Knuth, Tanenbaum, Silberschatz/Galvin are good names to know), read a couple of good books on concurrent programming languages, write a couple of operating systems, write a couple of multithreading libraries, write a couple of compilers, learn how different CPU architectures work by doing low-level programming on them, step-by-step debug multithreaded code in a debugger, design a CPU architecture and think about interrupt handling and stacks, and constantly challenge your own presumptions. After doing this a few times one usually finds out that these concepts are not as easy and clear as one initially thought :)
Yes, Oswald is lacking the experience to be able to make these distinctions and instead resorts to trying to cite different parts of Wikipedia without understanding the much bigger picture.
Although I have to say a multi-threading system with multi-tasking processes is something to brag about as it's quite a lot of code to implement memory management, hardware resources management etc. ;)
|
| |
Frantic
Registered: Mar 2003
Posts: 1633 |
This THREAD is closed. Admit it! |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
The thread is closed but the process continues... |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
ExitThread(-1);
? ;)
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: Yes, Oswald is lacking the experience to be able to make these distinctions and instead resorts to trying to cite different parts of Wikipedia without understanding the much bigger picture.
Although I have to say a multi-threading system with multi-tasking processes is something to brag about as it's quite a lot of code to implement memory management, hardware resources management etc. ;)
Oh my dear. You lack the defined experience aswell, and you lack the brains to realize that aswell. Your only goal left is discredit me by saying your mantra "you are wrong, confused, etc" instead of having arguments that makes any sense. Groepaz its time to close the topic, as it is entering personal only stage. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
You are wrong, I have the experience and the brains.
It is obvious that you do not because you are resorting to personal attacks instead of refuting the argument put before you. Your own posts discredit yourself and your "argument" because what you have been posting is demonstrably incorrect and the links you have been posting also show you are wrong. Lastly, the other posters in this thread are also telling you the same thing, that you are wrong. Yet you still continue to post the same rubbish.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
No I have the experience and brains and you dont, furthermore you are wrong because your own explanations proove you wrong. also you know you are wrong, but you dont admit that so you are trolling. now go back to kinder/trollgarten with this style of arguing dumbfuck.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Your repeated personal attacks demonstrate you're trolling and that your "argument" has failed. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Your disability to refuse my arguments prooves that u r wrong. Oh forgot to add ur fave "point": it prooves aswell u r trolling. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
It's clear that this discussion has lost all form of relevant content. Please stop it before you loose the respect you earned in other contexts. |
| |
Martin Piper
Registered: Nov 2007
Posts: 647 |
Quote: Your disability to refuse my arguments prooves that u r wrong. Oh forgot to add ur fave "point": it prooves aswell u r trolling.
Your "arguments" are refuted because the links you provided do not support your case, if you actually read the links without selectively quoting tiny sections they also show exactly why you are wrong, you have not refuted my counter arguments, also you have not refuted the counter arguments of everybody else that says you're wrong. Since you are unable to refute any of this you are trolling and using personal attacks instead. |
