Can anyone think of a better name than TCHECK? There should be some single word that could make up most of the name. I used "check" like one would check a basketball with an opposition teammate before starting play again. The word "register" applies, too, but it's too long and means, well... registers.
TCHECK D,S/# 'Write S/# into D and jump to self. On subsequent iterations, don't write D, but jump to self if D <> 0.
This gets rid of the need for TRESUME.
Removing TRESUME is good, as there were some usage cases of that, which worried me...
There is a more packed suggested version of TCHECK in #6041, which uses the now empty opcode of TRESUME, to create a new JB31 opcode. That allows TCHECK to signal efficiently in both directions.
Can anyone think of a better name than TCHECK? There should be some single word that could make up most of the name. I used "check" like one would check a basketball with an opposition teammate before starting play again. The word "register" applies, too, but it's too long and means, well... registers.
Give this loops until released, how about LOOPNZ (or the variant would be LOOPB31 ) ?
or can also? like this "Task B notices the non-0 value and can do whatever it wants about it and can also write 0 to the register to release Task A." PS: I'm not being picky about the wording, just trying to understand the flow.
Actually, it's more like "must" write 0 to the register to release Task A or do a JMPTASK to force Task A to go do something else. Task A is pretty much stopped and st the mercy of some other task to get going again. Not a problem at all just something to be aware of.
It will read better than the "jz base,@$" currently in the monitor code.
Can anyone think of a better name than TCHECK? There should be some single word that could make up most of the name. I used "check" like one would check a basketball with an opposition teammate before starting play again. The word "register" applies, too, but it's too long and means, well... registers.
/COLOR]Task B notices the non-0 value and can do whatever it wants about it, but can write 0 to the register to release Task A.]
is this - but can or can't?
or can also? like this "Task B notices the non-0 value and can do whatever it wants about it and can also write 0 to the register to release Task A."
PS: I'm not being picky about the wording, just trying to understand the flow.
Sorry about that. I knew the wording was a little weird.
This TCHECK instruction has a few different uses, though all of them are inter-task related. TCHECK can be used to know that a task or a thread has arrived at a certain point and is waiting to be released. Or, it could be used as a breakpoint, signalling that it got to a location and is now waiting for further handling. TCHECK's big value is that it atomically (via a single instruction) signals to other tasks that a point has been reached and then waits for some interaction. The interaction can be simply releasing it to carry on by writing a zero to the D register used by TCHECK, or it can be starving that task of time slots, so that it goes dormant, allowing you to perform some kind of alien abduction maneuver, where you swap out the TCHECK with another instruction and let it run further, or do some kind of context swap, where you begin running another program in that task, later coming back to execute more of the original program. It's a nifty mechanism that could facilitate a lot of different things. It was pretty much thought up by people on this forum.
Can anyone think of a better name than TCHECK? There should be some single word that could make up most of the name. I used "check" like one would check a basketball with an opposition teammate before starting play again. The word "register" applies, too, but it's too long and means, well... registers.
Haha! We're almost back to TYIELD again. The task is yielding its powers of execution until some other task decides when and what it should do to continue.
(too bad TROUNDABOUT is too long....best analogy!)
TSUBMIT - submit to will of other task
TSKPASS - pass control of your future to some other task
TSKASK - ask some other task what you should do?
TINTRPT - interrupt the other task (kidding!!)
TLOITER - stop and wait around until something happens
TNOTIFY - tell some other task something - let it decide what to do
Those are both pretty good names. I'm kind of partial to THOLD because WAIT is already an instruction, and HOLD seems a little more open-ended about what might be happening.
We are checking and we are optionally authorizing or releasing and signalling...
TCOORD, in that all of these things are coordinating the behavior between tasks?
Just saw THOLD, and I like that one.
Fixating on coordinate for a moment, makes me thing of TSYNC, in that we are doing what it takes to insure the various tasks do things according to plan.
But it needs to convey something about what both operands do.
The LOOPNZ register part shows it is waiting while register is NZ, but the 2ns param is written so it could be WLOOPNZ register,#WrValue -> Write to Register and Loop while register Non Zero
...but that really doesn't convey it's relationship to a task. It does however pack the low level function into the mnemonic. Personally, I would rather it have task or T as part of the name so that context of when to use it is clear.
TSYNC: (TASK SYNC) Writes value (#) or value contained in source register (S) to destination (D), then begins jumping back to itself while destination is non zero.
I have a question. Is the value written once, or is it written on every loop? Secondly, if source is immediate # then the same value would be written there, but would source also be allowed to be the standard contents of register, (non #) mode, as well?
Seems to me, another task could change the source register contents, which would be updated to the supervisor or scheduler task on every loop iteration.
Intended behavior? Just asking at this point in an attempt to fully understand the instruction.
Haha! We're almost back to TYIELD again. The task is yielding its powers of execution until some other task decides when and what it should do to continue.
(too bad TROUNDABOUT is too long....best analogy!)
TSUBMIT - submit to will of other task
TSKPASS - pass control of your future to some other task
TSKASK - ask some other task what you should do?
TINTRPT - interrupt the other task (kidding!!)
TLOITER - stop and wait around until something happens
TNOTIFY - tell some other task something - let it decide what to do
We are checking and we are optionally authorizing or releasing and signalling...
TCOORD, in that all of these things are coordinating the behavior between tasks?
Just saw THOLD, and I like that one.
Fixating on coordinate for a moment, makes me thing of TSYNC, in that we are doing what it takes to insure the various tasks do things according to plan.
That's all I got.
TSYNC is pretty good. It implies a certain use case, though. TCOORD is good, but it will never read well because of the double O's.
Sorry about that. I knew the wording was a little weird.
This TCHECK instruction has a few different uses, though all of them are inter-task related. TCHECK can be used to know that a task or a thread has arrived at a certain point and is waiting to be released. Or, it could be used as a breakpoint, signalling that it got to a location and is now waiting for further handling. TCHECK's big value is that it atomically (via a single instruction) signals to other tasks that a point has been reached and then waits for some interaction. The interaction can be simply releasing it to carry on by writing a zero to the D register used by TCHECK, or it can be starving that task of time slots, so that it goes dormant, allowing you to perform some kind of alien abduction maneuver, where you swap out the TCHECK with another instruction and let it run further, or do some kind of context swap, where you begin running another program in that task, later coming back to execute more of the original program. It's a nifty mechanism that could facilitate a lot of different things.
Taking that approach with something like waitvid would be strange and difficult to associate with the intended scope of use cases, would it not? That's the question being posed here. Instead of waitvid, which summarizes the higher level functionality, we would get something like WAFACV, (wait and fetch aux memory color values....) which is just crappy.
Personally, I would understand this instruction from both the mnemonic you've put out there jmg, and the functional description. Next question, "what do I use that for?", which is kind of the naming discussion at hand. Once I've read the functional description, I'm left with the mnemonic, and duplicating all that info really doesn't get a person thinking about tasks, more like loops and we've got jump instructions for that, and worse, this one really isn't intended for those use cases at all, which is confusing. Everybody who might want to loop, would take a look at this loop thing and wonder, "what good does that do for my loop?"
When tasking, it's going to be obvious to go look through the tasking instructions for solutions, not some looping thing. Not that your mnemonic is bad. It isn't. I just don't think it gets at usability as well as one could.
I have a question. Is the value written once, or is it written on every loop? Secondly, if source is immediate # then the same value would be written there, but would source also be allowed to be the standard contents of register, (non #) mode, as well?
It only writes on the first iteration. Subsequent iterations loop if D is not zero. The value written can be a constant or a register.
as in: Halt definition, to stop; cease moving, operating, etc., either permanently or temporarily.
Or, actually I still like TPAUSE
THALT is pretty good! It's nice and terse and reads well.
It works well, too, because it doesn't imply something that may or may not happen afterwards, like how TPAUSE suggests that things will resume, when maybe that's just not in the program.
Comments
is this - but can or can't?
or can also? like this " Task B notices the non-0 value and can do whatever it wants about it and can also write 0 to the register to release Task A."
PS: I'm not being picky about the wording, just trying to understand the flow.
Removing TRESUME is good, as there were some usage cases of that, which worried me...
There is a more packed suggested version of TCHECK in #6041, which uses the now empty opcode of TRESUME, to create a new JB31 opcode. That allows TCHECK to signal efficiently in both directions.
Give this loops until released, how about LOOPNZ (or the variant would be LOOPB31 ) ?
Actually, it's more like "must" write 0 to the register to release Task A or do a JMPTASK to force Task A to go do something else. Task A is pretty much stopped and st the mercy of some other task to get going again. Not a problem at all just something to be aware of.
It will read better than the "jz base,@$" currently in the monitor code.
Maybe THOLD for task hold or TWAIT for task wait?
Sorry about that. I knew the wording was a little weird.
This TCHECK instruction has a few different uses, though all of them are inter-task related. TCHECK can be used to know that a task or a thread has arrived at a certain point and is waiting to be released. Or, it could be used as a breakpoint, signalling that it got to a location and is now waiting for further handling. TCHECK's big value is that it atomically (via a single instruction) signals to other tasks that a point has been reached and then waits for some interaction. The interaction can be simply releasing it to carry on by writing a zero to the D register used by TCHECK, or it can be starving that task of time slots, so that it goes dormant, allowing you to perform some kind of alien abduction maneuver, where you swap out the TCHECK with another instruction and let it run further, or do some kind of context swap, where you begin running another program in that task, later coming back to execute more of the original program. It's a nifty mechanism that could facilitate a lot of different things. It was pretty much thought up by people on this forum.
Haha! We're almost back to TYIELD again. The task is yielding its powers of execution until some other task decides when and what it should do to continue.
(too bad TROUNDABOUT is too long....best analogy!)
TSUBMIT - submit to will of other task
TSKPASS - pass control of your future to some other task
TSKASK - ask some other task what you should do?
TINTRPT - interrupt the other task (kidding!!)
TLOITER - stop and wait around until something happens
TNOTIFY - tell some other task something - let it decide what to do
FLAGTSK - pass a flag to some other task
I think I'm out of ideas...lucky for you guys!
But it needs to convey something about what both operands do.
Those are both pretty good names. I'm kind of partial to THOLD because WAIT is already an instruction, and HOLD seems a little more open-ended about what might be happening.
TCOORD, in that all of these things are coordinating the behavior between tasks?
Just saw THOLD, and I like that one.
Fixating on coordinate for a moment, makes me thing of TSYNC, in that we are doing what it takes to insure the various tasks do things according to plan.
That's all I got.
The LOOPNZ register part shows it is waiting while register is NZ, but the 2ns param is written so it could be
WLOOPNZ register,#WrValue -> Write to Register and Loop while register Non Zero
TSYNC: (TASK SYNC) Writes value (#) or value contained in source register (S) to destination (D), then begins jumping back to itself while destination is non zero.
I have a question. Is the value written once, or is it written on every loop? Secondly, if source is immediate # then the same value would be written there, but would source also be allowed to be the standard contents of register, (non #) mode, as well?
Seems to me, another task could change the source register contents, which would be updated to the supervisor or scheduler task on every loop iteration.
Intended behavior? Just asking at this point in an attempt to fully understand the instruction.
Yeah, those are pretty imaginative.
TSYNC is pretty good. It implies a certain use case, though. TCOORD is good, but it will never read well because of the double O's.
It's hopefully pretty clear to anyone that
WLOOPNZ register,#WrValue -> Write to Register and Loop while register Non Zero
is going to loop forever, unless someone else changes that register.
- so the someone-else / Task nature, is fairly implicit.
Thanks!! Chip that's great!!
Hehe, I like TLOITER, but may not cross language barriers too well ?
It does almost say Write to Register and Loop while register Non Zero in a slang-manner.
Taking that approach with something like waitvid would be strange and difficult to associate with the intended scope of use cases, would it not? That's the question being posed here. Instead of waitvid, which summarizes the higher level functionality, we would get something like WAFACV, (wait and fetch aux memory color values....) which is just crappy.
Personally, I would understand this instruction from both the mnemonic you've put out there jmg, and the functional description. Next question, "what do I use that for?", which is kind of the naming discussion at hand. Once I've read the functional description, I'm left with the mnemonic, and duplicating all that info really doesn't get a person thinking about tasks, more like loops and we've got jump instructions for that, and worse, this one really isn't intended for those use cases at all, which is confusing. Everybody who might want to loop, would take a look at this loop thing and wonder, "what good does that do for my loop?"
When tasking, it's going to be obvious to go look through the tasking instructions for solutions, not some looping thing. Not that your mnemonic is bad. It isn't. I just don't think it gets at usability as well as one could.
Attending to something that needs attending to. The signaling task would be indicating it needs attending to of some sort.
Of course, somebody is gonna say it, TIT for TAT. At least it's not SEX, found on the 6809.
Which brings me to TINTENT or TINT for short, neither read as well as I would like, but this instruction enables intent between tasks.
Maybe now that's all I've got. The thesaurus is at a point of diminishing returns now.
Whatever it gets named, I feel good about it.
How about TCONTROL , TOPTIONS , TCHOICES, TJUDGE, TVALUATE , TAPPRAISE
TWTF, TLOL, TOMG, TWTYM.... Yeah, kidding...
It only writes on the first iteration. Subsequent iterations loop if D is not zero. The value written can be a constant or a register.
as in: Halt definition, to stop; cease moving, operating, etc., either permanently or temporarily.
Or, actually I still like TPAUSE
THALT is pretty good! It's nice and terse and reads well.
It works well, too, because it doesn't imply something that may or may not happen afterwards, like how TPAUSE suggests that things will resume, when maybe that's just not in the program.
or TSIGLNZ ?
Task Signaling by Write to Register and Loop while register Non Zero