New GCC compiler for 8086 cpu's

New GCC compiler for 8086 cpu's

[Juan Perez-Sanchez]

For those interested, Mentor announced a GCC back end for 8086 family of cpu's.
See the link:

https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/

Following the links there you can reach the page for download.
This seems to be a development based on ia16-gcc previously mentioned
in this list, but using a newer version of GCC and all rough edges
rounded.

I used this compiler to build the ELKS kernel. The kernel produced
appears to work fine. The compiler is very fast and produces a smaller
kernel.

Re: New GCC compiler for 8086 cpu's

[Tom]

On 14/06/17 01:08, Juan Perez-Sanchez wrote:
> For those interested, Mentor announced a GCC back end for 8086 family of cpu's.
> See the link:
>
> https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/
>
> Following the links there you can reach the page for download.
> This seems to be a development based on ia16-gcc previously mentioned
> in this list, but using a newer version of GCC and all rough edges
> rounded.
>
> I used this compiler to build the ELKS kernel. The kernel produced
> appears to work fine. The compiler is very fast and produces a smaller
> kernel.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Does it recurse? ie can you build it so it works on ELKS?

Tom

Re: New GCC compiler for 8086 cpu's

[Juan Perez-Sanchez]

No. GCC is huge and ELKS is tiny. It's impossible to fit GCC in elks.

On Wed, Jun 14, 2017 at 1:47 AM, Tom <madtom1999@googlemail.com> wrote:
> On 14/06/17 01:08, Juan Perez-Sanchez wrote:
>>
>> For those interested, Mentor announced a GCC back end for 8086 family of
>> cpu's.
>> See the link:
>>
>>
>> https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/
>>
>> Following the links there you can reach the page for download.
>> This seems to be a development based on ia16-gcc previously mentioned
>> in this list, but using a newer version of GCC and all rough edges
>> rounded.
>>
>> I used this compiler to build the ELKS kernel. The kernel produced
>> appears to work fine. The compiler is very fast and produces a smaller
>> kernel.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> Does it recurse? ie can you build it so it works on ELKS?
>
> Tom
>

Re: New GCC compiler for 8086 cpu's

[Edoardo]

Hi Juan
How much smaller?
If I remember correctly, one of ELKS limits was that binaries had to
fit on a 64KB page, and that was due to the compiler we used (dev86 /
bcc).
Do you think/know if GCC may solve this limit, being able to produce
multi-page binaries?

On Wed, Jun 14, 2017 at 2:08 AM, Juan Perez-Sanchez <lithoxs@gmail.com> wrote:
> For those interested, Mentor announced a GCC back end for 8086 family of cpu's.
> See the link:
>
> https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/
>
> Following the links there you can reach the page for download.
> This seems to be a development based on ia16-gcc previously mentioned
> in this list, but using a newer version of GCC and all rough edges
> rounded.
>
> I used this compiler to build the ELKS kernel. The kernel produced
> appears to work fine. The compiler is very fast and produces a smaller
> kernel.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New GCC compiler for 8086 cpu's

[Juan Perez-Sanchez]

On Thu, Jun 15, 2017 at 5:19 AM, Edoardo <eddyx89@gmail.com> wrote:
> How much smaller?

The current kernel with a configuration similar to the default
configuration for the 0.1.3 version,
compiled with BCC has a code size of 51216 bytes. With the new
compiler, size is 48288 bytes.
This is 2928 bytes less (5.7%).

> If I remember correctly, one of ELKS limits was that binaries had to
> fit on a 64KB page, and that was due to the compiler we used (dev86 /
> bcc).

Actually, code size <=  64KB and separately  (data + bss + stack sizes) <= 64KB.

> Do you think/know if GCC may solve this limit, being able to produce
> multi-page binaries?

No, those limits still holds.

Re: New GCC compiler for 8086 cpu's

[David O'Shea]

Hi Juan,

Thanks for the link!  Some questions below:

On Fri, Jun 16, 2017 at 8:23 AM, Juan Perez-Sanchez <lithoxs@gmail.com> wrote:
> On Thu, Jun 15, 2017 at 5:19 AM, Edoardo <eddyx89@gmail.com> wrote:
>> If I remember correctly, one of ELKS limits was that binaries had to
>> fit on a 64KB page, and that was due to the compiler we used (dev86 /
>> bcc).
>
> Actually, code size <=  64KB and separately  (data + bss + stack sizes) <= 64KB.
>
>> Do you think/know if GCC may solve this limit, being able to produce
>> multi-page binaries?
>
> No, those limits still holds.

I guess there are both limits in the compiler and limits in ELKS itself, right?

Alan kindly explained to me in the last few days in the thread
http://www.spinics.net/lists/linux-8086/msg00813.html what kind of
complex things ELKS would need to do to handle processes with multiple
code segments and/or multiple data segments, and those restrictions
are still there, so simply using GCC doesn't make them go away.

The "Getting Started Guide" for this new IA16 GCC actually mentions a
few limitations in this area that the new compiler has:

- Section 3.2 says "Although this version of Sourcery CodeBench Lite
uses ELF as its internal object format, it produces executables in DOS
COM format."  DOS .COM format implies a single 64KB segment for
combined code and data, i.e. tiny memory model, right?  That's more
restrictive than ELKS.

- Section 3.3 says "Far pointers currently do not work, so accessing
memory outside the program's 64kB segment requires the use of assembly
(either inline or a separate file that is assembled and then linked
into the program).", so it's not going to let you make bigger
executables even if ELKS added such support.  For what it's worth
you'd find far pointer support in OpenWatcom.

I see that ia16-elf/lib/dos-com.ld seems to have some instructions
related to making a DOS .COM file.  I've never played with GCC linker
scripts before, but I assume there's nothing in the compiler that
would prevent it from generating a full 64KB code segment and also a
full 64KB data segment, and one could make a linker script for
generating an ELKS executable with those two separate segments instead
of being limited to it all being in one segment like with a .COM file?

Apologies in advance if I'm spreading any misinformation here!

Thanks,
David

Re: New GCC compiler for 8086 cpu's

[Juan Perez-Sanchez]

> Alan kindly explained to me in the last few days in the thread
> http://www.spinics.net/lists/linux-8086/msg00813.html what kind of
> complex things ELKS would need to do to handle processes with multiple
> code segments and/or multiple data segments, and those restrictions
> are still there, so simply using GCC doesn't make them go away.
>

There are two problems: the userspace, where the above holds, and the
kernel space, where there are multiple data segments (without any
explicit compiler support). The advantages of GCC are: a modern
compiler, better inline assembly, better code, etc.

> - Section 3.2 says "Although this version of Sourcery CodeBench Lite
> uses ELF as its internal object format, it produces executables in DOS
> COM format."  DOS .COM format implies a single 64KB segment for
> combined code and data, i.e. tiny memory model, right?  That's more
> restrictive than ELKS.
>

This is more a limitation of the linker than of GCC. And workarounds
can be implemented.

> - Section 3.3 says "Far pointers currently do not work, so accessing
> memory outside the program's 64kB segment requires the use of assembly
> (either inline or a separate file that is assembled and then linked
> into the program).", so it's not going to let you make bigger
> executables even if ELKS added such support.  For what it's worth
> you'd find far pointer support in OpenWatcom.
>

Switching to another compiler would require rewriting large portions
of the current code base. So it is an important decision.
What is important for developers is that the compiler handle modern
standards, decent inline assembly, currently supported, etc.
And there are the requirements for the compiler to be open source with
an acceptable license.
Someone at this list mentioned in the past an objection to the license
of OpenWatcom.
Assuming that OpenWatcom fulfills the developer's requirements, what
is needed is a the complete certainty that its licence is acceptable.

> I see that ia16-elf/lib/dos-com.ld seems to have some instructions
> related to making a DOS .COM file.  I've never played with GCC linker
> scripts before, but I assume there's nothing in the compiler that
> would prevent it from generating a full 64KB code segment and also a
> full 64KB data segment, and one could make a linker script for
> generating an ELKS executable with those two separate segments instead
> of being limited to it all being in one segment like with a .COM file?
>

I agree. As I said, this is more a problem with the linker. Indeed,
the object files produced by GCC can be made to have separate code and
data.

Re: New GCC compiler for 8086 cpu's

[David O'Shea]

Hi Juan, all,

Thanks for your reply!  Replies below:

On Sat, Jun 17, 2017 at 4:27 AM, Juan Perez-Sanchez <lithoxs@gmail.com> wrote:
>> - Section 3.3 says "Far pointers currently do not work, so accessing
>> memory outside the program's 64kB segment requires the use of assembly
>> (either inline or a separate file that is assembled and then linked
>> into the program).", so it's not going to let you make bigger
>> executables even if ELKS added such support.  For what it's worth
>> you'd find far pointer support in OpenWatcom.
>>
>
> Switching to another compiler would require rewriting large portions
> of the current code base.

I think I saw some posts earlier where someone had compiled something
in ELKS with OpenWatcom and as a result contributed some ANSI
C-related fixes.  Perhaps it was just the kernel though?

> And there are the requirements for the compiler to be open source with
> an acceptable license.
> Someone at this list mentioned in the past an objection to the license
> of OpenWatcom.
> Assuming that OpenWatcom fulfills the developer's requirements, what
> is needed is a the complete certainty that its licence is acceptable.

I wasn't aware of this concern.  I'm not a lawyer, but I believe that
I see what you are talking about.  I'm not clear on the differences
between some of the clauses, but in
https://github.com/open-watcom/open-watcom-v2/blob/master/license.txt
I see:

"2.2 You may use, reproduce, display, perform, modify and Deploy Covered Code,
provided that in each instance:
...
(c) You must make Source Code of all Your Deployed Modifications publicly
available under the terms of this License, including the license grants set
forth in Section 3 below, for as long as you Deploy the Covered Code or twelve
(12) months from the date of initial Deployment, whichever is longer. You
should preferably distribute the Source Code of Your Deployed Modifications
electronically (e.g. download from a web site);"

To take it to the extreme, I think that by some definitions the source
would be "publicly available" if it was in the bottom drawer of a
filing cabinet in a toilet stall with a sign on the door saying
"Beware of the leopard" (apologies to Douglas Adams if I got that
wrong).  I have heard that some companies using open source software
will state that the source is available on request for a "reasonable
charge" and then consider that it is going to take some engineers many
hours to assemble the sources, so it may cost hundreds of dollars or
more.  What I'm trying to get at is that there may be "workarounds"
that make it possible to comply with the license that will most likely
not require much effort except in the unlikely event that someone
requests the source code, and for the cases that I gather people are
concerned about - internal/private use - one would expect that the
source code would not be requested.

Perhaps if it was seen as particularly beneficial to use OpenWatcom
(probably not so likely now that gcc-ia16 is available) then this
could be looked at further.

By the way, I found some more interesting information about this new
GCC: https://www.reddit.com/r/programming/comments/62sqe6/gcc_for_8088808680286_cpus/
- appears to be from the author (see also the GCC mailing list posts)
and discusses some future plans, such as support for other memory
models.  That points to https://github.com/crtc-demos/build-ia16
(saying "there are some differences between those and the ones used
for the Mentor toolchains"); https://github.com/crtc-demos/gcc-ia16
seems to have GCC 6.3 and 7.1 branches too.  Also it sounds like the
author was involved in the 8088 MPH demo, so he's certainly very much
into old PCs!

Thanks!
David

Re: New GCC compiler for 8086 cpu's

[Georg Potthast]

Hi David,

maybe you can compile Jove with Turbo-C. I read that Jove can be compiled 
for DOS. Turbo-C produces smaller executables and works (after some patches) 
with ELKS too:

http://www.alfonsomartone.itb.it/fhlvnr.html

Regarding the Watcom licence you cited, I think this applies to the Watcom-C 
code itself and not to code generated using Watcom-C. You can generate 
closed source code or public domain code with Watcom-C.

Georg

-----Ursprüngliche Nachricht----- 
From: David O'Shea
Sent: Monday, June 19, 2017 5:58 AM
To: linux-8086
Subject: Re: New GCC compiler for 8086 cpu's

Hi Juan, all,

Thanks for your reply!  Replies below:

On Sat, Jun 17, 2017 at 4:27 AM, Juan Perez-Sanchez <lithoxs@gmail.com> 
wrote:
>> - Section 3.3 says "Far pointers currently do not work, so accessing
>> memory outside the program's 64kB segment requires the use of assembly
>> (either inline or a separate file that is assembled and then linked
>> into the program).", so it's not going to let you make bigger
>> executables even if ELKS added such support.  For what it's worth
>> you'd find far pointer support in OpenWatcom.
>>
>
> Switching to another compiler would require rewriting large portions
> of the current code base.

I think I saw some posts earlier where someone had compiled something
in ELKS with OpenWatcom and as a result contributed some ANSI
C-related fixes.  Perhaps it was just the kernel though?

> And there are the requirements for the compiler to be open source with
> an acceptable license.
> Someone at this list mentioned in the past an objection to the license
> of OpenWatcom.
> Assuming that OpenWatcom fulfills the developer's requirements, what
> is needed is a the complete certainty that its licence is acceptable.

I wasn't aware of this concern.  I'm not a lawyer, but I believe that
I see what you are talking about.  I'm not clear on the differences
between some of the clauses, but in
https://github.com/open-watcom/open-watcom-v2/blob/master/license.txt
I see:

"2.2 You may use, reproduce, display, perform, modify and Deploy Covered 
Code,
provided that in each instance:
...
(c) You must make Source Code of all Your Deployed Modifications publicly
available under the terms of this License, including the license grants set
forth in Section 3 below, for as long as you Deploy the Covered Code or 
twelve
(12) months from the date of initial Deployment, whichever is longer. You
should preferably distribute the Source Code of Your Deployed Modifications
electronically (e.g. download from a web site);"

To take it to the extreme, I think that by some definitions the source
would be "publicly available" if it was in the bottom drawer of a
filing cabinet in a toilet stall with a sign on the door saying
"Beware of the leopard" (apologies to Douglas Adams if I got that
wrong).  I have heard that some companies using open source software
will state that the source is available on request for a "reasonable
charge" and then consider that it is going to take some engineers many
hours to assemble the sources, so it may cost hundreds of dollars or
more.  What I'm trying to get at is that there may be "workarounds"
that make it possible to comply with the license that will most likely
not require much effort except in the unlikely event that someone
requests the source code, and for the cases that I gather people are
concerned about - internal/private use - one would expect that the
source code would not be requested.

Perhaps if it was seen as particularly beneficial to use OpenWatcom
(probably not so likely now that gcc-ia16 is available) then this
could be looked at further.

By the way, I found some more interesting information about this new
GCC: 
https://www.reddit.com/r/programming/comments/62sqe6/gcc_for_8088808680286_cpus/
- appears to be from the author (see also the GCC mailing list posts)
and discusses some future plans, such as support for other memory
models.  That points to https://github.com/crtc-demos/build-ia16
(saying "there are some differences between those and the ones used
for the Mentor toolchains"); https://github.com/crtc-demos/gcc-ia16
seems to have GCC 6.3 and 7.1 branches too.  Also it sounds like the
author was involved in the 8088 MPH demo, so he's certainly very much
into old PCs!

Thanks!
David
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html 

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New GCC compiler for 8086 cpu's

[David O'Shea]

On Mon, Jun 19, 2017 at 4:28 PM, Georg Potthast <nospam@georgpotthast.de> wrote:
> maybe you can compile Jove with Turbo-C. I read that Jove can be compiled
> for DOS. Turbo-C produces smaller executables and works (after some patches)
> with ELKS too:
>
> http://www.alfonsomartone.itb.it/fhlvnr.html
>
> Regarding the Watcom licence you cited, I think this applies to the Watcom-C
> code itself and not to code generated using Watcom-C. You can generate
> closed source code or public domain code with Watcom-C.

Thanks!  I saw the Turbo C solution before, and it appeals to me
simply because I like DOS :)

Yes, I realise that the license issue presumably only applies to
changes you make to OpenWatcom itself, but I suppose some people may
still find it unacceptable because they want to be able to modify the
compiler for their OS without being bound to release the source code
under those terms.

I imagine that even more people would be unhappy about Turbo C.  I
have it myself, so I'd be okay, but others who don't already have
Turbo C might not want to use binaries I produced myself or to give
Embarcadero their personal details so that they can download Turbo C
themselves.

Perhaps the ideal situation is if everything can be built using bcc,
gcc or some other fully free compiler, but you can optionally compile
it using OpenWatcom or some other compiler to get faster and/or
smaller executables?

Thanks,
David

Re: New GCC compiler for 8086 cpu's

[Juan Perez-Sanchez]

On Sun, Jun 18, 2017 at 10:58 PM, David O'Shea <dcoshea@gmail.com> wrote:
> I think I saw some posts earlier where someone had compiled something
> in ELKS with OpenWatcom and as a result contributed some ANSI
> C-related fixes.  Perhaps it was just the kernel though?
>

Yes, only kernel functions.

> I wasn't aware of this concern.  I'm not a lawyer, but I believe that
> I see what you are talking about.  I'm not clear on the differences
> between some of the clauses, but in
> https://github.com/open-watcom/open-watcom-v2/blob/master/license.txt
> I see:
>

Neither me. Anyway, I read that license and concluded that the problem is:

...
2.1 You may use, reproduce, display, perform, modify and distribute Original
Code, with or without Modifications, solely for Your internal research and
development and/or Personal Use, provided that in each instance:
...

Where Personal Use means:

1.8 "Personal Use" means use of Covered Code by an individual solely for his
or her personal, private and non-commercial purposes. An individual's use of
Covered Code in his or her capacity as an officer, employee, member,
independent contractor or agent of a corporation, business or organization
(commercial or non-commercial) does not qualify as Personal Use.

That means that if you develop an embedded product, you cannot
distribute the binaries of your software if they were compiled with
OpenWatcom because the generation of those binaries is outside the
scope of clause 2.1, even if you don't charge for the software.

> Perhaps if it was seen as particularly beneficial to use OpenWatcom
> (probably not so likely now that gcc-ia16 is available) then this
> could be looked at further.
>

To have the option of compile the kernel using OpenWatcom can be
useful to find problems and measuring the quality of code produced by
BCC and ia16-elf-gcc.
For user space, there is the additional problem of the C library.
Neither OpenWatcom nor ia16-elf-gcc have ELKS as target system. To
complicate matters, BCC and ia16-elf-gcc have slightly differents C
calling conventions. I guess also OpenWatcom with the other compilers.

Juan

Re: New GCC compiler for 8086 cpu's

[Alan Cox]

On Fri, 16 Jun 2017 23:03:26 +0930
"David O'Shea" <dcoshea@gmail.com> wrote:

> Hi Juan,
> 
> Thanks for the link!  Some questions below:
> 
> On Fri, Jun 16, 2017 at 8:23 AM, Juan Perez-Sanchez <lithoxs@gmail.com> wrote:
> > On Thu, Jun 15, 2017 at 5:19 AM, Edoardo <eddyx89@gmail.com> wrote:  
> >> If I remember correctly, one of ELKS limits was that binaries had to
> >> fit on a 64KB page, and that was due to the compiler we used (dev86 /
> >> bcc).  
> >
> > Actually, code size <=  64KB and separately  (data + bss + stack sizes) <= 64KB.
> >  
> >> Do you think/know if GCC may solve this limit, being able to produce
> >> multi-page binaries?  
> >
> > No, those limits still holds.  
> 
> I guess there are both limits in the compiler and limits in ELKS itself, right?
> 
> Alan kindly explained to me in the last few days in the thread
> http://www.spinics.net/lists/linux-8086/msg00813.html what kind of
> complex things ELKS would need to do to handle processes with multiple
> code segments and/or multiple data segments, and those restrictions
> are still there, so simply using GCC doesn't make them go away.
> 
> The "Getting Started Guide" for this new IA16 GCC actually mentions a
> few limitations in this area that the new compiler has:
> 
> - Section 3.2 says "Although this version of Sourcery CodeBench Lite
> uses ELF as its internal object format, it produces executables in DOS
> COM format."  DOS .COM format implies a single 64KB segment for
> combined code and data, i.e. tiny memory model, right?  That's more
> restrictive than ELKS.

The compiler generates .COM but the rest of it can built split I/D
"small" model binaries with the same limits as DOS small model and ELKS
split I/D. That limit is that function pointers don't work totally
strictly to the C standard - but not in a way that ever matters.

In particular

	void *p = &function;

gives a 16bit offset relative to CS: for which there might exist a
different object (a variable) with the same address relative to DS. That
also means that

	uint8_t *p = (uint8_t)&function;
	*p = 4;

doesn't write over the function code as you'd expect 8)

None of this matters in the real world because comparing function
pointers, calling functions by pointer and all the normal uses work
just fine.

Alan

Re: New GCC compiler for 8086 cpu's

[Alan Cox]

On Thu, 15 Jun 2017 17:53:20 -0500
Juan Perez-Sanchez <lithoxs@gmail.com> wrote:

> On Thu, Jun 15, 2017 at 5:19 AM, Edoardo <eddyx89@gmail.com> wrote:
> > How much smaller?  
> 
> The current kernel with a configuration similar to the default
> configuration for the 0.1.3 version,
> compiled with BCC has a code size of 51216 bytes. With the new
> compiler, size is 48288 bytes.
> This is 2928 bytes less (5.7%).
> 
> > If I remember correctly, one of ELKS limits was that binaries had to
> > fit on a 64KB page, and that was due to the compiler we used (dev86 /
> > bcc).  
> 
> Actually, code size <=  64KB and separately  (data + bss + stack sizes) <= 64KB.
> 
> > Do you think/know if GCC may solve this limit, being able to produce
> > multi-page binaries?  
> 
> No, those limits still holds.

For the kernel it's good enough it could do it with a few helpers.
However the big kernel problem space is data (because of the stacks).

If an 'export symbol' thing is added and drivers are treated like kernel
modules (even if loaded together not on demand) then you can use tools to
generate stubs for each module that do a far call into the kernel. You
would probably need to disallow callbacks and modules calling each other
because while you are sort of doing a far call you need a near call
frame. Also because you'd have pointers to functions in other modules
that were not far and did not a segment attached.

Actually making it work is tricky but doable. I don't think it's needed
however - the data segment is the only really big issue.

Alan

Re: New GCC compiler for 8086 cpu's

[Juan Perez-Sanchez]

Hi,

On Mon, Jun 19, 2017 at 8:43 AM, Alan Cox <alan@llwyncelyn.cymru> wrote:
> For the kernel it's good enough it could do it with a few helpers.
> However the big kernel problem space is data (because of the stacks).
>

A simple solution for the kernel stacks is to use the user stack in
kernel mode, this is:

DS = ES = Kernel segment
SS = User data segment.

Of course, this leads to problems. And the current kernel will require
very careful inspection and corrections. But I think this is doable by
enforcing some simple rules.

What do you think?

Juan,

Re: New GCC compiler for 8086 cpu's

[Alan Cox]

> A simple solution for the kernel stacks is to use the user stack in
> kernel mode, this is:
> 
> DS = ES = Kernel segment
> SS = User data segment.

DS != SS requires far pointers.

Think about

	char x[40];
	char *p = x;


p now points to SS:something which is not the same as DS:something.

> Of course, this leads to problems. And the current kernel will require
> very careful inspection and corrections. But I think this is doable by
> enforcing some simple rules.
> 
> What do you think?

It doesn't work because you can take the address of a stack based object,
and not only that the compiler will do so itself internally when
generating code.

So to fix the stack you need a per process store for stacks and to do
something on task switch akin to


switch:
	while nothing else to run
		idle();
	if we are now the only/next thing to run (usual case)
		return;
	save our kernel stack somewhere
	(asm code to set ds: es: rep movs restore)
	change task
	load new kernel stack
	(ditto)

Note btw you can't use prefixes with rep movs on 8086 because there is a
CPU errata that a restarted rep instruction sometimes forgets the
prefixes!

The fancier version is to hash processes by stack (so say slots 1,5,9,13
use stack 0, 2,6,10,14, stack 1 .. etc). You have to keep the stack you
use for a given process constant but you can attempt to make sure that
usually a switch doesn't cause a copy in or out of stacks.

It turns out that on a small single user machine in particular the number
of task switches between tasks is miniscule. From the shell you switch
once to the app, once back to wait(), then back to the app and probably
don't switch again to anything but idle state unless the user changes
console, exits the program or runs a sub process. Now and then cron or
similar will briefly juggle things around but that's about it.

Fuzix uses the simple algorithm above on many platforms for the same
reason and it work extremely well even on a 4MHz Z80.

Alan

	

Re: New GCC compiler for 8086 cpu's

[Juan Perez-Sanchez]

On Mon, Jun 19, 2017 at 3:55 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
> It doesn't work because you can take the address of a stack based object,
> and not only that the compiler will do so itself internally when
> generating code.
>

Of course, this is the kind of problems I expect to happen. To prevent
this case, one rule of the simple set of rules would be "Use automatic
variables only within the function where it is defined". Other may be
"Take the address of objects only if the object is defined in the DS
segment". It will be necessary a heap to allocate data in DS for you
example. The question is: using an adequate kmalloc() and a simple set
of rules, can we get a functional kernel?

Re: New GCC compiler for 8086 cpu's

[Alan Cox]

> Of course, this is the kind of problems I expect to happen. To prevent
> this case, one rule of the simple set of rules would be "Use automatic
> variables only within the function where it is defined".

That still doesn't work. The compiler will generate address references to
stack objects itself as will normal things like pointers into an array.

Faced with s = s + 1 for an auto variable the compiler is likely to
generate something like a word increment of &s, but it's not going to
magically put segments in.

The DOS folks spent a long time writing very good compilers - they never
figured out a hack for this; although in many other languages SS != DS
isn't a problem.

Alan

Re: New GCC compiler for 8086 cpu's

[Juan Perez-Sanchez]

On Tue, Jun 20, 2017 at 6:37 AM, Alan Cox <alan@llwyncelyn.cymru> wrote:
> That still doesn't work. The compiler will generate address references to
> stack objects itself as will normal things like pointers into an array.
>

If we ensure the creation of stack frames, that objects will be
referenced through register BP, which by default uses the stack
segment. Using BCC there will always be stack frames. Using GCC, it
would be necessary to use -fno-omit-frame-pointer, to force the use of
BP on automatic variables and to prevent using BP as a general purpose
index register because, as already said, it will default to use the
stack segment.

> Faced with s = s + 1 for an auto variable the compiler is likely to
> generate something like a word increment of &s, but it's not going to
> magically put segments in.
>

In this simple case, the compiler will likely produce:

      INCW    offset_of_var_s[BP]

By default, the instruction will use the stack segment without needing
any segment override.

Juan

Fwd: New GCC compiler for 8086 cpu's

[David Given]

Unfortunately C doesn't distinguish between pointers to objects in the
heap and pointers to objects on the stack. Consider this:

{
  int buffer[256];
  int* pointer = buffer; // pointer points to stack frame
  pointer = malloc(256*sizeof(int)); // now it points to heap
  return buffer[0]; // so the same instruction here needs to be able
to cope with either
}

Vanilla C has two address spaces --- code and data. You're not allowed
to (portably) turn one to the other, so they can live in different
segments. But the stack and the heap are defined to be in the same
address space, and pointers to them have to be interchangeable. So
they need to live in the same segment.

-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup