Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » Operating systems that made use of the 386 task switching hardware?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Operating systems that made use of the 386 task switching hardware? [message #394669] Mon, 18 May 2020 08:07 Go to next message
Anonymous
Karma:
Originally posted by: Johann 'Myrkraverk' Oskarsson

Dear a.f.computers,

I'm reading Advanced 80386 Programming Techniques [1], and it covers the
386's own task switching mechanism. Now as I understand it, "modern"
operating systems such as Linux and 386BSD did not make use of these
hardware facilities for various reasons; and at least in the case of
Linux I know it did not make use of call gates for system calls [2].

Did any operating system at the time [3] actually make use of these
hardware task switching facilities? Do we know why, or why not? Did
NT, or OS/2?

[1] by James Turley; the edition I have is copyright 1999.

[2] Solaris 10, on the other hand had support for both call gates and
interrupt based system calls for 32bit code; maybe Illumos still has
this support but I haven't checked.

[3] I'm not certain what era is appropriate for 386 based operating
systems.

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
Re: Operating systems that made use of the 386 task switching hardware? [message #394670 is a reply to message #394669] Mon, 18 May 2020 08:31 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Carlos E.R.

On 18/05/2020 14.07, Johann 'Myrkraverk' Oskarsson wrote:
> Dear a.f.computers,
>
> I'm reading Advanced 80386 Programming Techniques [1], and it covers the
> 386's own task switching mechanism.  Now as I understand it, "modern"
> operating systems such as Linux and 386BSD did not make use of these
> hardware facilities for various reasons; and at least in the case of
> Linux I know it did not make use of call gates for system calls [2].
>
> Did any operating system at the time [3] actually make use of these
> hardware task switching facilities?  Do we know why, or why not?  Did
> NT, or OS/2?
>
> [1] by James Turley; the edition I have is copyright 1999.
>
> [2] Solaris 10, on the other hand had support for both call gates and
> interrupt based system calls for 32bit code; maybe Illumos still has
> this support but I haven't checked.
>
> [3] I'm not certain what era is appropriate for 386 based operating
> systems.

I remember reading of this around 1990, and at the time I didn't know of
anything using those features.


--
Cheers, Carlos.
Re: Operating systems that made use of the 386 task switching hardware? [message #394671 is a reply to message #394669] Mon, 18 May 2020 08:48 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Mon, 18 May 2020 20:07:28 +0800, Johann 'Myrkraverk' Oskarsson wrote:

> I'm reading Advanced 80386 Programming Techniques [1], and it covers the
> 386's own task switching mechanism. Now as I understand it, "modern"
> operating systems such as Linux and 386BSD did not make use of these
> hardware facilities for various reasons; and at least in the case of
> Linux I know it did not make use of call gates for system calls [2].
>
> Did any operating system at the time [3] actually make use of these
> hardware task switching facilities? Do we know why, or why not? Did
> NT, or OS/2?

OS/2 didn't use the TSS for task switching; that would have flushed all
the segment register caches, the TLBs, and that caused protection checks
as the segment registers were reloaded. It minimally used a single TSS
for privilege level transition.

It did, however, use call gates.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: Operating systems that made use of the 386 task switching hardware? [message #394678 is a reply to message #394669] Mon, 18 May 2020 15:12 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 3639
Registered: February 2012
Karma: 0
Senior Member
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
> Dear a.f.computers,
>
> I'm reading Advanced 80386 Programming Techniques [1], and it covers the
> 386's own task switching mechanism. Now as I understand it, "modern"
> operating systems such as Linux and 386BSD did not make use of these
> hardware facilities for various reasons; and at least in the case of
> Linux I know it did not make use of call gates for system calls [2].
>
> Did any operating system at the time [3] actually make use of these
> hardware task switching facilities? Do we know why, or why not? Did
> NT, or OS/2?

For the most part, it make task switches far to costly; software could
do the switch far more effectively.
Re: Operating systems that made use of the 386 task switching hardware? [message #394685 is a reply to message #394678] Mon, 18 May 2020 22:07 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Johann 'Myrkraverk' Oskarsson

On 19/05/2020 3:12 am, Scott Lurndal wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>> Dear a.f.computers,
>>
>> I'm reading Advanced 80386 Programming Techniques [1], and it covers the
>> 386's own task switching mechanism. Now as I understand it, "modern"
>> operating systems such as Linux and 386BSD did not make use of these
>> hardware facilities for various reasons; and at least in the case of
>> Linux I know it did not make use of call gates for system calls [2].
>>
>> Did any operating system at the time [3] actually make use of these
>> hardware task switching facilities? Do we know why, or why not? Did
>> NT, or OS/2?
>
> For the most part, it make task switches far to costly; software could
> do the switch far more effectively.
>

Yes, This is what the 386BSD people had to say [1] about the JUMP TSS
instruction:

> As a matter of fact, while comprehensive, we find it too slow to use
> efficiently for our purposes. However, to be fair to the designers of
> the 386, if you need to do all of the things that JUMP TSS offers,
> using this instruction is probably your best bet.

In the next paragraph they continue with:

> We know that by saving fewer registers, we end up doing fewer loads
> and stores, and hence make our end-to-end cost lower. In our 386BSD
> swtch() function (see Listing Four), we get away with saving only
> six registers. We don't need to save %eax, %edx, and %ecx because
> these are compiler temporary registers which are discarded on return.
> We also don't save the segment registers because they don't change in
> this version of the system. In contrast, pushal saves eight registers
> and JMP TSS saves 20. Adding up the instruction costs, our approach is
> the best of the three.

I cannot say if they did benchmarks or just hand counted the cost of the
different strategies; but it's clear they decided JUMP TSS was too ex-
pensive.

So, would we consider the JUMP TSS instruction a design blunder at
Intel? According to WP [2], amd64 does not support this instruction at
all.

[1]
https://386bsd.org/releases/porting-unix-to-the-386-the-basi c-kernel-multiprogramming-and-multiprogramming-and-multitask ing-part-ii-article

[2] https://en.wikipedia.org/wiki/Task_state_segment

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
Re: Operating systems that made use of the 386 task switching hardware? [message #394686 is a reply to message #394685] Mon, 18 May 2020 22:38 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1059
Registered: December 2011
Karma: 0
Senior Member
In article <kbHwG.426283$XQ5.392452@fx28.am4>,
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> So, would we consider the JUMP TSS instruction a design blunder at
> Intel? According to WP [2], amd64 does not support this instruction at all.

JMP TSS took about 300 cycles compared to 2 for an ordinary register
push so it wasn't a hard calculation to make.

I think it's just part of a myopic attitude that that the segmenty
goodness of the 286 and 386 were so great that the horrible
performance didn't matter.

Segment loads on 286 and 386 were so slow that if you wanted decent
performance you had to cram your code and data into as few segments as
possible to avoid segment switches. They didn't even make the obvious
speedup of checking if you were reloading the same value into a
segment register, so you had to write all your code with short jumps
and calls, with long mode glue when you absolutely had to switch
segments.


--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Operating systems that made use of the 386 task switching hardware? [message #394690 is a reply to message #394685] Tue, 19 May 2020 00:43 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 4644
Registered: January 2012
Karma: 0
Senior Member
On 2020-05-19, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

> So, would we consider the JUMP TSS instruction a design blunder at
> Intel? According to WP [2], amd64 does not support this instruction at
> all.

"It seemed like a good idea at the time..."

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: Operating systems that made use of the 386 task switching hardware? [message #394699 is a reply to message #394669] Tue, 19 May 2020 11:22 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: timcaffrey420

On Monday, May 18, 2020 at 8:07:46 AM UTC-4, Johann 'Myrkraverk' Oskarsson wrote:
> Dear a.f.computers,
>
> I'm reading Advanced 80386 Programming Techniques [1], and it covers the
> 386's own task switching mechanism. Now as I understand it, "modern"
> operating systems such as Linux and 386BSD did not make use of these
> hardware facilities for various reasons; and at least in the case of
> Linux I know it did not make use of call gates for system calls [2].
>
> Did any operating system at the time [3] actually make use of these
> hardware task switching facilities? Do we know why, or why not? Did
> NT, or OS/2?
>
> [1] by James Turley; the edition I have is copyright 1999.
>
> [2] Solaris 10, on the other hand had support for both call gates and
> interrupt based system calls for 32bit code; maybe Illumos still has
> this support but I haven't checked.
>
> [3] I'm not certain what era is appropriate for 386 based operating
> systems.
>
> --
> Johann | email: invalid -> com | www.myrkraverk.com/blog/
> I'm not from the Internet, I just work there. | twitter: @myrkraverk

Convergent Technology's OS (CTOS) used TSS's extensively in the protected
mode version. I'm not sure why, they didn't really isolate tasks from
each other. I figured this out when I was trying to write an interrupt
driver for the serial port. When the CPU got an interrupt, it went
through a task gate for the interrupt service routine, figured out
it needed to alert my device driver and called through another task
gate. On a 8Mhz 286 I couldn't keep up with 9600 bps, because it bounced
out through the two task gates on the way back to user space before it got
the next interrupt. 4 task gates between characters was just too much overhead. Most frustrating project I ever worked on.

- Tim
Re: Operating systems that made use of the 386 task switching hardware? [message #394700 is a reply to message #394690] Tue, 19 May 2020 11:45 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 3639
Registered: February 2012
Karma: 0
Senior Member
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> On 2020-05-19, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>
>> So, would we consider the JUMP TSS instruction a design blunder at
>> Intel? According to WP [2], amd64 does not support this instruction at
>> all.
>
> "It seemed like a good idea at the time..."

And it was state of the art in the late 70's early 80's. Burroughs
medium systems used a similar instruction (BRV, Branch Virtual Reinstate)
that would save the state for the current task and restore the state for
the next task (including the base pointer for the segment tables for
the task).
Re: Operating systems that made use of the 386 task switching hardware? [message #394701 is a reply to message #394700] Tue, 19 May 2020 11:48 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Tue, 19 May 2020 15:45:22 +0000, Scott Lurndal wrote:

> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>> On 2020-05-19, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
>> wrote:
>>
>>> So, would we consider the JUMP TSS instruction a design blunder at
>>> Intel? According to WP [2], amd64 does not support this instruction
>>> at all.
>>
>> "It seemed like a good idea at the time..."
>
> And it was state of the art in the late 70's early 80's. Burroughs
> medium systems used a similar instruction (BRV, Branch Virtual
> Reinstate)
> that would save the state for the current task and restore the state for
> the next task (including the base pointer for the segment tables for the
> task).

The problem was making the TSS switch such a complete switch, with so
much context. Other architectures cached page and segment table entries
separately, and re-acquired them as and when required. Saving just the
working registers could be pretty fast. And with public segments for the
OS (where the segment entries were rarely changed) helped a lot.




--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: Operating systems that made use of the 386 task switching hardware? [message #394706 is a reply to message #394700] Tue, 19 May 2020 13:24 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 7344
Registered: December 2011
Karma: 0
Senior Member
Scott Lurndal <scott@slp53.sl.home> wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>> On 2020-05-19, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>>
>>> So, would we consider the JUMP TSS instruction a design blunder at
>>> Intel? According to WP [2], amd64 does not support this instruction at
>>> all.
>>
>> "It seemed like a good idea at the time..."
>
> And it was state of the art in the late 70's early 80's. Burroughs
> medium systems used a similar instruction (BRV, Branch Virtual Reinstate)
> that would save the state for the current task and restore the state for
> the next task (including the base pointer for the segment tables for
> the task).
>

I would imagine Burroughs did a bit of a better job with it, though.

--
Pete
Re: Operating systems that made use of the 386 task switching hardware? [message #394707 is a reply to message #394706] Tue, 19 May 2020 13:32 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 3639
Registered: February 2012
Karma: 0
Senior Member
Peter Flass <peter_flass@yahoo.com> writes:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>> On 2020-05-19, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>>>
>>>> So, would we consider the JUMP TSS instruction a design blunder at
>>>> Intel? According to WP [2], amd64 does not support this instruction at
>>>> all.
>>>
>>> "It seemed like a good idea at the time..."
>>
>> And it was state of the art in the late 70's early 80's. Burroughs
>> medium systems used a similar instruction (BRV, Branch Virtual Reinstate)
>> that would save the state for the current task and restore the state for
>> the next task (including the base pointer for the segment tables for
>> the task).
>>
>
> I would imagine Burroughs did a bit of a better job with it, though.

I would say so, but then I was on the new architecture team when the
instruction was created :-)

Here's the simulator version of the instruction:

/**
* Branch Reinstate Virtual (Rev B).
*
* @param opp The operation descriptor
* @return false
*/
bool
c_processor::op_brv(struct _op *opp)
{
mem_addr_t sb = c_system::self()->get_subbase();
mem_addr_t rleaddr = sb + 6002;
mem_addr_t rle;
struct timeval end_time;

flush_mcp_data();

if (!is_control()
|| !is_kernel()) {
instruction_error(IE_PRIV_VIOLATION);
}

if (p_bfl == 1) {
rle = get_address(7, getdigits(p_operands[0]->getaddress()+2, 6));

if (gethex(rle+RLIST_WAIT_FIELD, RLIST_WAIT_FIELD_LEN) == 0x800000) {
ulong tp = gethex(sb+6000, 8);

puthex(rle+RLIST_NEXT, RLIST_NEXT_LEN, tp);
puthex(sb+6000, 2, 0xc7);
putdigits(rleaddr, 6, rle-sb);
puthex(rle+RLIST_WAIT_FIELD, 1,
(gethex(rle+RLIST_WAIT_FIELD, 1) & ~0x8));
}
}
//
// Select next task from the ready-list
//
while (!is_nullptr(rleaddr)) {
rle = getdigits(rleaddr, 6)+sb;
//
// If the task is not runnable, delink it from the ready-list. If
// the task is runnable, set the current processor number into the
// owning process field and drop through to the reinstate code.
//
if (gethex(rle+RLIST_WAIT_FIELD, RLIST_WAIT_FIELD_LEN) == 0) {
putdigits(rle+RLIST_PROC_NUM, RLIST_PROC_NUM_LEN, p_procnum);
} else {
if (getdigits(rle+RLIST_PROC_NUM, RLIST_PROC_NUM_LEN) != 0) {
rleaddr = rle+RLIST_NEXT+2;
continue;
}
puthex(rle+RLIST_WAIT_FIELD, 1, gethex(rle+RLIST_WAIT_FIELD, 1)|8);
puthex(rleaddr, 6, gethex(rle+RLIST_NEXT+2, 6));
//
// On to next ready-list element
//
continue;
}
//
// Reinstate the top runnable ready-list task
//
p_curtask = rle;
p_curtasknum = getdigits(p_curtask+RLIST_TASKNUM, RLIST_TASKNUM_LEN);

set_mode(MODE_EXECUTING);
p_kerneltime += difftime_usec(&end_time, &p_kernstart);
c_system::self()->unlock_kernel(); // Release kernel lock

if (!p_accumulator.load(p_curtask+RLIST_ACCUM, &p_rd)) {
handle_fault();
}
p_mop.load(p_curtask+RLIST_MOP);
p_imask.load(p_curtask+RLIST_IMASK);
#if defined(VSIM_DEBUG)
p_logger->trace("[%1.1lu/%4.4lu] set Imask=%3.3lx\n",
p_procnum, p_curtasknum, p_imask.get_val());
#endif
for(ulong i=4, source=p_curtask+RLIST_MOBIX; i < 8; i++, source += 8) {
p_ix[i]->load(source);
}
p_toggles.load(p_curtask+RLIST_MODE);
p_com_ovf = gethex(p_curtask+RLIST_COMS, RLIST_COMS_LEN);
if (!p_active_env.load(p_curtask+RLIST_ACTIVE_ENV)) {
address_error(AE_EO_INV_MSD);
}
load_mat(p_curtask, false);
p_ip = getdigits(p_curtask+RLIST_IP, RLIST_IP_LEN);

gettimeofday(&p_taskstart, NULL);

//
// The real hardware has a running timer that will trigger when the
// top digit hits zero. We'll do it here, instead. The timer has plenty
// of room to continue to run, and the task will be charged accordingly.
//
if (p_mp->getdigit(p_curtask+RLIST_TSR) == 0) {
p_interrupts.raise_timer_interrupt();
}

//
// Update the task number at base+82 (the rev B spec doesn't say this!)
// --- How will this work with multiple processors
// XXX Maybe this only needs to be done on entry to
// interrupt procedure?
//
putdigits(sb+82, 4,
getdigits(p_curtask+RLIST_TASKNUM, RLIST_TASKNUM_LEN));

if (is_soft_fault_enabled()) {
if (getdigits(p_curtask+8, 1) != 0) {
p_logger->trace("Soft Fault Hardware Call invoked\n");
soft_fault();
hardware_call(opp, false, 0);
}
}

p_taken = true;
alarm_check();
return false;
}

idle(opp);

return false;
}
Re: Operating systems that made use of the 386 task switching hardware? [message #394713 is a reply to message #394669] Tue, 19 May 2020 22:01 Go to previous messageGo to next message
Daiyu Hurst is currently offline  Daiyu Hurst
Messages: 76
Registered: December 2012
Karma: 0
Member
On Monday, May 18, 2020 at 8:07:46 AM UTC-4, Johann 'Myrkraverk' Oskarsson wrote:
> Dear a.f.computers,
>
> I'm reading Advanced 80386 Programming Techniques [1], and it covers the
> 386's own task switching mechanism. Now as I understand it, "modern"
> operating systems such as Linux and 386BSD did not make use of these
> hardware facilities for various reasons; and at least in the case of
> Linux I know it did not make use of call gates for system calls [2].
>
> Did any operating system at the time [3] actually make use of these
> hardware task switching facilities? Do we know why, or why not? Did
> NT, or OS/2?

Intel's RTOS 386 product.

-Dai
Re: Operating systems that made use of the 386 task switching hardware? [message #394805 is a reply to message #394669] Fri, 22 May 2020 11:24 Go to previous message
Anonymous
Karma:
Originally posted by: antispam

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> Dear a.f.computers,
>
> I'm reading Advanced 80386 Programming Techniques [1], and it covers the
> 386's own task switching mechanism. Now as I understand it, "modern"
> operating systems such as Linux and 386BSD did not make use of these
> hardware facilities for various reasons; and at least in the case of
> Linux I know it did not make use of call gates for system calls [2].

Linux 0.01 used 386's own task switching to implement process switch.
That handed in later versions.

--
Waldek Hebisch
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: Sillycon Valley history
Next Topic: Convergent Technology Workstations and "Rats game"??
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Jul 09 04:22:22 EDT 2020

Total time taken to generate the page: 0.03820 seconds