English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 20 August 2016, 00:59   #81
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 368
Quote:
Originally Posted by matthey View Post
Is a <150MHz FPGA processor a modern processor? I agree that there is less advantage to a branch hint bit as the prediction technique gets better but high end processors have gshare/adaptive dynamic prediction (there is a several cycle latency with these techniques so it still could be useful in a few cases). More likely for 68k processors is 2 bit saturating or no dynamic prediction where a hint bit would be "useful" if faster executing code is considered "useful". It would be helpful to see some timed results of a variety of code executing with no dynamic prediction and with a hybrid 2 bit saturating with hint bit but everyone has already decided what is "useful". The cost of a hint bit on the 68k is so high that it is practically free but lets reject it as not "useful" even though most research shows a branch prediction improvement for practically free.
With "modern" I mean competent branch prediction. If then the design is stretched out over several huge FPGAs and running at an effective clock rate of 1MHz (similar to verification efforts of real processor designs before ASIC realization) doesn't matter.

The fact is hint bits doesn't help much, only for startup (first time a branch is seen) where a static prediction fails (backwards taken, forwards not taken). After it have been noticed by the branch predictor the hint doesn't matter anymore. The saving is in other words 1x branch mispredict penalty for cold code where branches doesn't follow the normal static prediction pattern.

To compare to some modern high-performance processors: some doesn't even do static prediction according to the branch direction, they just assume a never seen branch will not be taken. In other words some designers doesn't even think static predictions are worth the effort even though this have much higher overheads (e.g. one misprediction per loop).

Quote:
We are talking of branches in code here where a 32 bit displacement already gives +-4 GB displacement. If all the code of the AmigaOS was combined into one executable it would probably not exceed this. If all the code which was released for cost on the Amiga in the first year was combined into one executable it would probably not exceed this. I don't think it would be a problem to divide code up into sections this small even if 64 bit addressing existed. The problem with PC relative addressing is not the branch displacement range but the code density deterioration and use of an expensive addressing mode because of a lack of range in PC relative addressing modes (beyond +-32kB). This is where the 2 new PC relative addressing modes proposed could practically eliminate both problems. Even then, 64 bit PC relative displacements are not necessary and would likely never be used. Code is much smaller than data even on modern processors.
I agree. Look at it as a similar choice as the RISC V being capable to expand to 128 bit address space. No it is not likely to be used much and even with 128 bit address space 64 bit (or even 32 bit) displacements/offsets should be enough for nearly everything.
Megol is offline  
Old 01 September 2016, 13:04   #82
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
maybe instead of introducing new user-mode instructions that existing software won't use, existing compilers/assemblers don't support &c... (plus what if someone else produces a competing 68k implementation? there is no guarantee they will respect your extensions)

How about just introducing support for more than one hardware thread, either by hyperthreading or dual-core. Instructions to support this could be supervisor-mode only so not affecting most developers (at least not OS-friendly ones!) An operating system patch would be required to take advantage of it, but then all existing software can benefit from improved multitasking performance.
Mrs Beanbag is offline  
Old 01 September 2016, 13:36   #83
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by Mrs Beanbag View Post
How about just introducing support for more than one hardware thread, either by hyperthreading or dual-core. Instructions to support this could be supervisor-mode only so not affecting most developers (at least not OS-friendly ones!) An operating system patch would be required to take advantage of it, but then all existing software can benefit from improved multitasking performance.
You require a lot more than a few instructions and a simple system patch to do that !
What you are asking for here is called SMP and the OS is simply not adapted to this.
meynaf is offline  
Old 01 September 2016, 20:28   #84
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by meynaf View Post
You require a lot more than a few instructions and a simple system patch to do that !
What you are asking for here is called SMP and the OS is simply not adapted to this.
of course, i didn't mean to suggest that all that would be required is a few more instructions. implementing a multi-core or hyperthreaded CPU would be far more involved than that. I only meant that any new instructions that were required could be made supervisor-privileged and thus no concern of the typical application programmer (although maybe some hardware-specific demo could use them!)

As for SMP, well maybe it need not be fully-symmetric multiprocessing, perhaps only one core/thread could be capable of supervisor mode thus the operating system itself would be restricted to single threaded operation, but since the OS already has programmer-abstracted multitasking (i.e. pre-emptive, not co-operative multitasking) how much trouble could it really cause if two user tasks or processes were running simultaneously on different cores? Not that i'm saying it would be a small feat. But really impossible? Eventually it will have to happen, if someone wants to bring 68k into the 21st century.
Mrs Beanbag is offline  
Old 01 September 2016, 20:39   #85
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by Mrs Beanbag View Post
As for SMP, well maybe it need not be fully-symmetric multiprocessing, perhaps only one core/thread could be capable of supervisor mode thus the operating system itself would be restricted to single threaded operation (...)
The operating system does not normally run in supervisor mode.


Quote:
Originally Posted by Mrs Beanbag View Post
(...) how much trouble could it really cause if two user tasks or processes were running simultaneously on different cores?
Quite a lot of trouble. Consider two programs accessing the same list, especially with inline versions of Forbid/Disable.
meynaf is offline  
Old 01 September 2016, 21:00   #86
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by meynaf View Post
The operating system does not normally run in supervisor mode.
ok but when it is switching/scheduling tasks surely it is?

Quote:
Quite a lot of trouble. Consider two programs accessing the same list, especially with inline versions of Forbid/Disable.
without Forbid/Disable that would be potentially troublesome even just with pre-emptive multitasking on a single core. And i don't know what is meant by "inline versions" of these functions. not going through the Exec library to do this sounds like asking for trouble. But Exec's Forbid/Disable could be made to temporarily halt all other threads. This might not be optimal, but then again, how often does it happen?
Mrs Beanbag is offline  
Old 01 September 2016, 21:23   #87
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by Mrs Beanbag View Post
ok but when it is switching/scheduling tasks surely it is?
When switching yes, when scheduling not necessarily. The OS goes into supervisor mode only when it is mandatory.


Quote:
Originally Posted by Mrs Beanbag View Post
without Forbid/Disable that would be potentially troublesome even just with pre-emptive multitasking on a single core.
That depends. A single instruction is atomic on a single core and this fact is used quite a lot.


Quote:
Originally Posted by Mrs Beanbag View Post
And i don't know what is meant by "inline versions" of these functions.
Something like addq.b #1,tdnestcnt(a6) or move.w #$4000,$dff09a.


Quote:
Originally Posted by Mrs Beanbag View Post
not going through the Exec library to do this sounds like asking for trouble.
The OS itself does it. Some apps probably also do.


Quote:
Originally Posted by Mrs Beanbag View Post
But Exec's Forbid/Disable could be made to temporarily halt all other threads. This might not be optimal, but then again, how often does it happen?
It's not that simple. You can't halt all other threads regardless of what they're doing : many cases can go haywire, like when some thread calls Disable while the main one is actually executing an interrupt...

Besides, the OS task lists are totally incompatible with multiple core - they're not designed for that at all.
meynaf is offline  
Old 01 September 2016, 21:59   #88
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by meynaf View Post
When switching yes, when scheduling not necessarily. The OS goes into supervisor mode only when it is mandatory.
This whole mechanism will need recoding anyway...

Quote:
That depends. A single instruction is atomic on a single core and this fact is used quite a lot.
x86 and other ISAs must have also had to get round this kind of thing somehow...

Quote:
Something like addq.b #1,tdnestcnt(a6) or move.w #$4000,$dff09a.

The OS itself does it. Some apps probably also do.
Wherever the OS itself does it, can be patched. Ok maybe just a complete custom ROM!

Quote:
It's not that simple. You can't halt all other threads regardless of what they're doing : many cases can go haywire, like when some thread calls Disable while the main one is actually executing an interrupt...
hmm i see your point... and if two cores execute mutually-problematic instructions at the same time, which gets priority? Then again, x86 et al must also have had to overcome this sort of thing, this doesn't seem like a 68k specific problem.

Quote:
Besides, the OS task lists are totally incompatible with multiple core - they're not designed for that at all.
can we extend the task list in a way that doesn't break (most) old software?

While it's fruitful to think of all the problems i'm someone who prefers to imagine solutions. I'm just going to wait for a second opinion on this tbh because i'm a little out of my depth (but i'm a fast learner).
Mrs Beanbag is offline  
Old 02 September 2016, 08:56   #89
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by Mrs Beanbag View Post
This whole mechanism will need recoding anyway...
If you fancy rewrite the whole kernel, just do it


Quote:
Originally Posted by Mrs Beanbag View Post
x86 and other ISAs must have also had to get round this kind of thing somehow...
They didn't have to - it's Amiga specific problem.


Quote:
Originally Posted by Mrs Beanbag View Post
Wherever the OS itself does it, can be patched. Ok maybe just a complete custom ROM!
Yeah, if the whole ROM is rewritten and all incompatible apps are rewritten as well, it can work


Quote:
Originally Posted by Mrs Beanbag View Post
hmm i see your point... and if two cores execute mutually-problematic instructions at the same time, which gets priority? Then again, x86 et al must also have had to overcome this sort of thing, this doesn't seem like a 68k specific problem.
There is no 68k specific problem that i can see. For me the actual ISA is already enough to support SMP.
The problem is Amiga specific.


Quote:
Originally Posted by Mrs Beanbag View Post
can we extend the task list in a way that doesn't break (most) old software?
The struct doesn't have room for more info and can't be size extended. Dos processes could perhaps, but not Exec tasks.
All monitoring software expects the lists to be in the normal way, so it would break if the lists get changed.


Quote:
Originally Posted by Mrs Beanbag View Post
While it's fruitful to think of all the problems i'm someone who prefers to imagine solutions. I'm just going to wait for a second opinion on this tbh because i'm a little out of my depth (but i'm a fast learner).
The only solution would be complete sandboxing of old apps.
meynaf is offline  
Old 02 September 2016, 11:49   #90
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by meynaf View Post
They didn't have to - it's Amiga specific problem.

There is no 68k specific problem that i can see. For me the actual ISA is already enough to support SMP.
The problem is Amiga specific.
forgive me but i don't see how any issue created by the atomicity of 68k instructions, or the handling of interrupts, is specifically an Amiga problem.

Quote:
The struct doesn't have room for more info and can't be size extended. Dos processes could perhaps, but not Exec tasks.
Two-way associative map between the Exec task struct and the extra data?

Quote:
The only solution would be complete sandboxing of old apps.
even apps that don't bang hardware, don't use interrupts, and don't communicate with each other so are completely unaware of each other's existence? i won't deny there is any problem but i feel you are somewhat overstating it.

If there is specifically an Amiga problem, it must be because, either, the OS itself is doing something non-SMP-safe (which can be fixed, in principle), or the OS is so hands-off that individual apps are going above its head and doing things directly. I realise the latter case does happen. But not in every program, constantly. These must be specific use-cases that can be enumerated.

Perhaps a more concrete example would help me understand.
Mrs Beanbag is offline  
Old 02 September 2016, 12:29   #91
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by Mrs Beanbag View Post
forgive me but i don't see how any issue created by the atomicity of 68k instructions, or the handling of interrupts, is specifically an Amiga problem.
Because the Amiga is the only true multitasking system allowing the programs to take over the machine.


Quote:
Originally Posted by Mrs Beanbag View Post
Two-way associative map between the Exec task struct and the extra data?
The only way to find the extra data from the Exec task struct, is to perform some kind of search in a list. Not good in parts that must be very swift. But ok, that could work - in category "ugly but works".
You just have to hope someone will rewrite existing system monitors to not break when handling tasks directly...


Quote:
Originally Posted by Mrs Beanbag View Post
even apps that don't bang hardware, don't use interrupts, and don't communicate with each other so are completely unaware of each other's existence? i won't deny there is any problem but i feel you are somewhat overstating it.

If there is specifically an Amiga problem, it must be because, either, the OS itself is doing something non-SMP-safe (which can be fixed, in principle), or the OS is so hands-off that individual apps are going above its head and doing things directly. I realise the latter case does happen. But not in every program, constantly. These must be specific use-cases that can be enumerated.

Perhaps a more concrete example would help me understand.
The whole OS is non-SMP-safe. Do you want to rewrite it all ?
Apps are written with the assumption there is a single cpu in the machine.
I can't give you a concrete example.
But what i know for sure is that if something can go wrong, something will go wrong.

Anyway do we really need SMP ? What would that bring us ? Other systems have it because 1) they are unable to multitask properly without it and 2) this is the only way to write higher performance numbers on the paper (and marketing likes these numbers).
meynaf is offline  
Old 02 September 2016, 12:54   #92
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by meynaf View Post
You just have to hope someone will rewrite existing system monitors to not break when handling tasks directly...
Granted, this is one category of application that will need updating.

Quote:
The whole OS is non-SMP-safe. Do you want to rewrite it all ?
I don't, personally, on my own, but people are already rewriting it. Maybe we should bring AROS 68k team into this discussion?

Quote:
Apps are written with the assumption there is a single cpu in the machine.
I can't give you a concrete example.
I work on apps all the time that have been written without any awareness of multi-core, they still work fine on my dual-core PC. A single app still runs single-threaded, it need worry about other cores no more than it need worry about other tasks or processes. The app won't be any faster if i don't rework it to use multiple threads, but it still runs.

Quote:
But what i know for sure is that if something can go wrong, something will go wrong.
Something can always go wrong, no matter what you do, it's no reason never to do anything.

Quote:
Anyway do we really need SMP ? What would that bring us ? Other systems have it because 1) they are unable to multitask properly without it and 2) this is the only way to write higher performance numbers on the paper (and marketing likes these numbers).
Do we NEED it? Do we NEED an enhanced 68k? Do we need an Amiga at all? Sometimes we just want to do stuff to see if we can do them... but never mind that...

Multicore exists because, single-thread instruction-level parallelism limit was reached, Gigahertz limit was reached, demand for faster processing didn't stop, but (thankfully) modern workloads are increasingly multi-threaded by nature. It doesn't just increase specs on paper. It also actually works.

Although, before trying multi-core, i'd suggest hyperthreading, which is more-or-less equivalent to pre-emptive multitasking, with task switching every CPU cycle, so should create fewer problems (?) both for the OS and user programs.
Mrs Beanbag is offline  
Old 02 September 2016, 13:25   #93
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by Mrs Beanbag View Post
I work on apps all the time that have been written without any awareness of multi-core, they still work fine on my dual-core PC. A single app still runs single-threaded, it need worry about other cores no more than it need worry about other tasks or processes. The app won't be any faster if i don't rework it to use multiple threads, but it still runs.
Of course it runs, because the OS won't allow you to write something that doesn't.
Your program is isolated in its own space and has no access to other programs space, let alone system structs.
(Hey, wait. This is exactly what i told about when writing about sandboxing the apps...)


Quote:
Originally Posted by Mrs Beanbag View Post
Something can always go wrong, no matter what you do, it's no reason never to do anything.
Sure but when seeing a wall it's better not to run into it.


Quote:
Originally Posted by Mrs Beanbag View Post
Do we NEED it? Do we NEED an enhanced 68k? Do we need an Amiga at all?
We *do* need an enhanced 68k (or something having the same coding flexibility). At least I do.


Quote:
Originally Posted by Mrs Beanbag View Post
Multicore exists because, single-thread instruction-level parallelism limit was reached, Gigahertz limit was reached, demand for faster processing didn't stop,
Exactly - but ask yourself the question of why multicore didn't appear before the limits were reached...


Quote:
Originally Posted by Mrs Beanbag View Post
but (thankfully) modern workloads are increasingly multi-threaded by nature.
Do we execute "modern workloads" on an Amiga ?
What are they anyway ?


Quote:
Originally Posted by Mrs Beanbag View Post
It doesn't just increase specs on paper.
This is what they wanted you to believe. But how to know, without any reference to compare with ? Do we have single core, single threaded multi-gigahertz cpus running on operating systems not smp aware ?


Quote:
Originally Posted by Mrs Beanbag View Post
It also actually works.
Yes but this has a cost.


Quote:
Originally Posted by Mrs Beanbag View Post
Although, before trying multi-core, i'd suggest hyperthreading, which is more-or-less equivalent to pre-emptive multitasking, with task switching every CPU cycle, so should create fewer problems (?) both for the OS and user programs.
Perhaps but neither the OS nor user programs actually have a use for this.
I even have some code that would break if task priorities were broken.
meynaf is offline  
Old 02 September 2016, 13:48   #94
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by meynaf View Post
Of course it runs, because the OS won't allow you to write something that doesn't.
Your program is isolated in its own space and has no access to other programs space, let alone system structs.
(Hey, wait. This is exactly what i told about when writing about sandboxing the apps...)
ok. most programs don't write into other program's space (on purpose!) Maybe some do, for interprocess communication. These programs don't merely "have no access" to other program's space, they have no interaction with other programs whatsoever, except by such mundane means as reading and writing files. But how it makes a difference whether the other program is on another core or hyperthread, or just another task, i have yet to establish. The same sort of problems can be encountered. If two programs are inserting into the same linked list, for instance, if a task switch happens while in the middle of doing it, bad things can happen.

Accessing system structs might be more troublesome, but then again it always was. How many programs written for KS1.3 break on 3.1?

Quote:
We *do* need an enhanced 68k (or something having the same coding flexibility). At least I do.
what for?

i'd like it. i don't "need" it.

Quote:
Do we execute "modern workloads" on an Amiga ?
What are they anyway ?
fair play, but i could certainly imagine getting use out of it, if it were there. Amiga OS obviously doesn't have quite the menagerie of background services as Windows or Linux but if i could be rendering some image or compressing some big file, or play an MP3 (which the cool kids are doing these days), and still get on with something else without hinderance, that would be nice.

Quote:
I even have some code that would break if task priorities were broken.
sounds like bad code
Mrs Beanbag is offline  
Old 02 September 2016, 14:24   #95
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by Mrs Beanbag View Post
ok. most programs don't write into other program's space (on purpose!) Maybe some do, for interprocess communication. These programs don't merely "have no access" to other program's space, they have no interaction with other programs whatsoever, except by such mundane means as reading and writing files. But how it makes a difference whether the other program is on another core or hyperthread, or just another task, i have yet to establish. The same sort of problems can be encountered. If two programs are inserting into the same linked list, for instance, if a task switch happens while in the middle of doing it, bad things can happen.
Sure many programs would work exactly the same.
The problem with running on several cores is that normal, simple concurrent access protections fail. And we're not supposed to use CAS, CAS2 instruction types on the Amiga (the manual says it, right ?) - so this ought to require some hardware modding as well (= not just changing the cpu with a simple trapdoor accelerator).


Quote:
Originally Posted by Mrs Beanbag View Post
Accessing system structs might be more troublesome, but then again it always was. How many programs written for KS1.3 break on 3.1?
So it boils down to having a new OS version and break a few programs in the process ? Hmm...


Quote:
Originally Posted by Mrs Beanbag View Post
fair play, but i could certainly imagine getting use out of it, if it were there. Amiga OS obviously doesn't have quite the menagerie of background services as Windows or Linux but if i could be rendering some image or compressing some big file, or play an MP3 (which the cool kids are doing these days), and still get on with something else without hinderance, that would be nice.
Take some uae in jit mode. There you can render some image, compress some big file, play some mp3 and still get on with something else (please notice, however, that you scarcely do all these together !).


Quote:
Originally Posted by Mrs Beanbag View Post
sounds like bad code
On AmigaOS low priority tasks are always interrupted by higher priority ones. Or does some manual say otherwise ?
meynaf is offline  
Old 02 September 2016, 15:41   #96
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 609
You _can_ expand the task struct if you absolutely want to as was introduced with 2.x(3.x?). I have always forced that in my own Exec versions, and I don't know of any ill effect from what I have run.

It still doesn't help you with RMW operations that expect to be atomic when using a single cpu.
You have to resort to MMU trapping access to the Forbid() semaphore and the interrupt register that Disable() touches to make sure you catch them all and can properly signal the other cpu(s). That will not be pretty... nor fast. Interestingly, a 68K FPGA implementation could be given special purpose hw to accellerate these special cases, but you still have the RMW problem.
NorthWay is offline  
Old 02 September 2016, 15:49   #97
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by NorthWay View Post
You _can_ expand the task struct if you absolutely want to as was introduced with 2.x(3.x?). I have always forced that in my own Exec versions, and I don't know of any ill effect from what I have run.
What ? An app can expand that struct if it wants, but Exec itself ?
Many programs just use the size of 92 bytes to allocate new tasks and that would break !
meynaf is offline  
Old 02 September 2016, 16:17   #98
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 609
Code:
    ;* Pointer to an extended task structure.  This structure is allocated
    ;* by V36 Exec if the proper flags in tc_ETaskFlags are set.  This
    ;* field was formerly defined as:
    ;*		UWORD	TC_TRAPALLOC	    ; traps allocated
    ;*		UWORD	TC_TRAPABLE	    ; traps enabled
    ;* Please see the Exec AllocTrap() and FreeTrap() calls.
    ;*
    APTR    tc_ETask		    ; pointer to extended task structure
I have patched Exec to force setting T_ETASK(is that the correct name?) on all task creations and so far do not know any ill effect. There certainly is a possibility there can be as C= made it optional, but hopefully most useful sw is 2.0-aware.

Exec would be free to modify/extend the TC_ETASK struct for multi-cpu purposes, but that does not resolve non-atomic opcodes.
NorthWay is offline  
Old 02 September 2016, 16:46   #99
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,541
Quote:
Originally Posted by NorthWay View Post
I have patched Exec to force setting T_ETASK(is that the correct name?) on all task creations and so far do not know any ill effect. There certainly is a possibility there can be as C= made it optional, but hopefully most useful sw is 2.0-aware.
Why doing that ? Sounds like looking for trouble.


Quote:
Originally Posted by NorthWay View Post
Exec would be free to modify/extend the TC_ETASK struct for multi-cpu purposes, but that does not resolve non-atomic opcodes.
This struct doesn't appear to even be documented...

Anyway, extending the struct is something, however, what to put in some fields like execbase->ThisTask ?
meynaf is offline  
Old 02 September 2016, 18:30   #100
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 609
Quote:
Originally Posted by meynaf View Post
Why doing that ? Sounds like looking for trouble.
I was testing per-task mmu tables. I changed the private structure to hold more info.


Quote:
Originally Posted by meynaf View Post
This struct doesn't appear to even be documented...
The change to Exec is, but the struct it points to is indeed not documented and definitely so intended not to be.

Quote:
Originally Posted by meynaf View Post
Anyway, extending the struct is something, however, what to put in some fields like execbase->ThisTask ?
I haven't even begun thinking about that.
Anyone know what the OS4 devs are thinking, or what Jim Drew thought he could get away with back in the day?
NorthWay is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
BOOM (DOOM Enhanced) port to 68k NovaCoder News 125 15 July 2017 03:25
ISA Ethernet Cards jmmijo support.Hardware 13 03 February 2015 11:04
Any ISA Mach64 Information? CU_AMiGA support.Hardware 21 09 September 2007 22:17
Help converting an 8bit ISA slot to 16bit ISA slot Smiley support.Hardware 4 25 April 2006 11:20
A2000 ISA slots Unknown_K support.Hardware 1 20 March 2005 09:48

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 06:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.10004 seconds with 16 queries