Future of ELKS

Future of ELKS

[Miguel Bolanos]

Good day to all,

The project seems to be finally awaking from a very long period of
inactivity, this can be reflected not only by the traffic on the mailing
list, but on the amount of people hanging around at the irc channel and
the quality of the discussions over there.

Based on this facts, I believe that it is important that all the people
involved and interested in ELKS, provide their own opinions on what the
future of ELKS should be... I know of many wanting to have specific
features that are not currently in the kernel.. and others that as well
have interesting ideas for code reduction and improvements. So if you
are one them, please feel free yourself, as all this feedback is
important for us upgrade the TODO and roadmap of the project.

The current things that are been done are:

- Creation of an additional kernel that will use linux 2.6 coding style,
this is been done because we are looking forward to enable the
possibility of including support for 8086 and similar on the official
linux kernel as an option... of course this is will take a long time,
and doesn't mean that work on the current "production kernel" will be
depricated or anything like that, we which to encorage you to keep
contributing on the "production" kernel.. and the "new" kernel project
will be a work in parallel that at some point will have all this
improvements on the production kernel merged.

- A possibility of using gcc to create 8086 binaries might be a
possibility with a patch created by our irc friend boto. If the tests of
this are successful we will enable elkscmd to let the users decide if
they which to use gcc-8086 or our current bcc :)

Anyways thats all for now. Hope to hear back from all.
best wishes

Mike

Re: Future of ELKS

[I'm in Void]

Hi all,

onsdagen den 19 maj 2004 22.55 skrev Miguel Bolanos:
> Good day to all,
> 
> The project seems to be finally awaking from a very long period of
> inactivity, this can be reflected not only by the traffic on the mailing
> list, but on the amount of people hanging around at the irc channel and
> the quality of the discussions over there.
> 
> 
> - A possibility of using gcc to create 8086 binaries might be a
> possibility with a patch created by our irc friend boto. If the tests of
> this are successful we will enable elkscmd to let the users decide if
> they which to use gcc-8086 or our current bcc :)

This would be a major lift imho. Even if elks is 'never' even gona be a subset 
of linux, and that is not a major aspect for me at least as the 8088 in 
itself is cool to have good programs for, the idea to shift more to linux 
side is appealing.
I have also thought in the areas of netbsd kernels, to let it work in a subset 
environment. All this might come if the gcc-8088 compiler seams stable for 
it.


> 
> Anyways thats all for now. Hope to hear back from all.
> best wishes
> 
> Mike

/Benka
-- 
"I love Saturday morning cartoons, what classic humour!  This is what
entertainment is all about ... Idiots, explosives and falling anvils."
		-- Calvin and Hobbes, Bill Watterson

Re: Future of ELKS

[Miguel Bolanos]

Greetings,

On Wed, 2004-05-19 at 21:39, I'm in Void wrote:
> Hi all,
> 
> onsdagen den 19 maj 2004 22.55 skrev Miguel Bolanos:
> > Good day to all,
> > 
> > The project seems to be finally awaking from a very long period of
> > inactivity, this can be reflected not only by the traffic on the mailing
> > list, but on the amount of people hanging around at the irc channel and
> > the quality of the discussions over there.
> > 
> > 
> > - A possibility of using gcc to create 8086 binaries might be a
> > possibility with a patch created by our irc friend boto. If the tests of
> > this are successful we will enable elkscmd to let the users decide if
> > they which to use gcc-8086 or our current bcc :)
> 
> This would be a major lift imho. Even if elks is 'never' even gona be a subset 
> of linux, and that is not a major aspect for me at least as the 8088 in 
> itself is cool to have good programs for, the idea to shift more to linux 
> side is appealing.
> I have also thought in the areas of netbsd kernels, to let it work in a subset 
> environment. All this might come if the gcc-8088 compiler seams stable for 
> it.

Sure, I'm pretty sure that this ELKS - gcc-8086 will call A LOT of
attention, and in the mean time yes other projects could follow us and
use gcc-8086 too.
Lets just support the project.. remember that the more testers and
success and failure reports that we get, the best results that we get
obviously the best results that we will get.

best wishes

Mike

> 
> 
> > 
> > Anyways thats all for now. Hope to hear back from all.
> > best wishes
> > 
> > Mike
> 
> /Benka

Re: Future of ELKS

[Javier Sedano]

Hello, elksers,

	firstly, could you remember us the information to access the IRC? I can 
not even find the list archive...

	Being a plain elks user, and not a elks hacker, I would like elks (et 
al.) to focus on:

	1) Be more "user friendly". Of course, and elks user is probably a 
hacker, at least to an extent, so "user friendly" does not mean "dumb 
winuser friendly", but neither should mean "only-the-programmer 
friendly". It should not be a specific feature, but an elks way of live. 
I would like that anybody able to compile and run a Linux kernel was 
able to compile and run an elks kernel.
	I know it is not the kind of work that hackers love (I hate it!), but 
it is mandatory for plain final users.

	2) Include a good swap support. There is some support for swap, but it 
is one of such hacker-only features.

	3) Include IP support. Again, it is available for hackers, and only a 
few interfaces are supported (slip?, ppp?), and are a bit hidden and the 
routes are very, very hard-coded. Ethernet support, at least for some 
cards (NE2000, that common 8bit 3com whose name i can not remember,...) 
would be really great.

	4) Self contained compiler. The compiler should be able to compile 
itself, and thus run on elks (as you know, other open source compilers 
compile themselves in the "./configure; make; make install" procedure). 
Also, a "make" runnable on elks is needed.

	5) More applications. Editors, web browsers, email/news clients,... 
What about games? Can roge run on elks? Roge would be the killer app for 
elks ;-) Such applications may be dificult to be run on 8086/640k, 
but... you know: say "it is impossible", and someone will do it just to 
laugh at you.

	6) An ELKS distribution, such as EDE. The distribution should be able 
to install to a hard disk from floppy disks, configure the basic 
behaviour, and manage packages (at least, keep track of the installed 
packages, files owned by a given package,...). The main work here is to 
keep track of the ongoing elks developments.

	7) A graphical environment, with a window manager and applications (at 
least, terminal). Again, it may be dificult to be done with 640k. 
Compliance with X would be great, but may be impossible ;-)

	As you notice, many of the features are actually outside the elks 
kernel itself, but are perceived by user like a whole.


Miguel Bolanos wrote:
> Good day to all,
> 
> The project seems to be finally awaking from a very long period of
> inactivity, this can be reflected not only by the traffic on the mailing
> list, but on the amount of people hanging around at the irc channel and
> the quality of the discussions over there.
> 
> Based on this facts, I believe that it is important that all the people
> involved and interested in ELKS, provide their own opinions on what the
> future of ELKS should be... I know of many wanting to have specific
> features that are not currently in the kernel.. and others that as well
> have interesting ideas for code reduction and improvements. So if you
> are one them, please feel free yourself, as all this feedback is
> important for us upgrade the TODO and roadmap of the project.
> 
> The current things that are been done are:
> 
> - Creation of an additional kernel that will use linux 2.6 coding style,
> this is been done because we are looking forward to enable the
> possibility of including support for 8086 and similar on the official
> linux kernel as an option... of course this is will take a long time,
> and doesn't mean that work on the current "production kernel" will be
> depricated or anything like that, we which to encorage you to keep
> contributing on the "production" kernel.. and the "new" kernel project
> will be a work in parallel that at some point will have all this
> improvements on the production kernel merged.
> 
> - A possibility of using gcc to create 8086 binaries might be a
> possibility with a patch created by our irc friend boto. If the tests of
> this are successful we will enable elkscmd to let the users decide if
> they which to use gcc-8086 or our current bcc :)
> 
> Anyways thats all for now. Hope to hear back from all.
> best wishes
> 
> Mike
> 
> -
> 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
> 

-- 
Javier Sedano Jarillo: javier.sedano@agora-2000.com
                        (http://www.it.uc3m.es/~jsedano)
Agora Systems, S.A.
C/Aravaca 12
E-28040 Madrid (Spain)
Tel.: +34 91 533 58 57
Fax.: +34 91 534 84 77
--------
Who searches the Truth, is in risk of finding it.

Re: Future of ELKS

[Miguel Bolanos]

Greetings,

On Thu, 2004-05-20 at 05:42, Javier Sedano wrote:
> Hello, elksers,

Elksers ... hehe 

> 
> 	firstly, could you remember us the information to access the IRC? I can 
> not even find the list archive...

Yes sure no problem:

server: irc.freenode.net
chan:	#elks

I will be upgrading the website today and will ensure that this info is
easily found there.

> 
> 	Being a plain elks user, and not a elks hacker, I would like elks (et 
> al.) to focus on:
> 
> 	1) Be more "user friendly". Of course, and elks user is probably a 
> hacker, at least to an extent, so "user friendly" does not mean "dumb 
> winuser friendly", but neither should mean "only-the-programmer 
> friendly". It should not be a specific feature, but an elks way of live. 
> I would like that anybody able to compile and run a Linux kernel was 
> able to compile and run an elks kernel.
> 	I know it is not the kind of work that hackers love (I hate it!), but 
> it is mandatory for plain final users.

OK I still don't get very clear your idea of  "User friendly"... when u
refer to Linux kernel compilation.. i guess u mean kernels dialog ? We
are working a making elks work like regular linux kernel... but this
will take a little while.. and having dialog .. hehe this will take yet
another bit more. Anyways if this is not what you mean, please tell some
more specific ideas of your definition to "User friendly" :)

> 
> 	2) Include a good swap support. There is some support for swap, but it 
> is one of such hacker-only features.

Yes this is going to the TODO.

> 
> 	3) Include IP support. Again, it is available for hackers, and only a 
> few interfaces are supported (slip?, ppp?), and are a bit hidden and the 
> routes are very, very hard-coded. Ethernet support, at least for some 
> cards (NE2000, that common 8bit 3com whose name i can not remember,...) 
> would be really great.

Is on the TODO since a while :)

> 
> 	4) Self contained compiler. The compiler should be able to compile 
> itself, and thus run on elks (as you know, other open source compilers 
> compile themselves in the "./configure; make; make install" procedure). 
> Also, a "make" runnable on elks is needed.

we will see what comes along with this gcc-8086 thing.

> 
> 	5) More applications. Editors, web browsers, email/news clients,... 
> What about games? Can roge run on elks? Roge would be the killer app for 
> elks ;-) Such applications may be dificult to be run on 8086/640k, 
> but... you know: say "it is impossible", and someone will do it just to 
> laugh at you.
> 

Well basicaly, we need to make a clear point. ELKS is an Embeddable
linux kernel subset.. not a distro.. BUT... i guess that in the mean
time we will find a way to put all this stuff together to make elks
actually worth the try.


> 	6) An ELKS distribution, such as EDE. The distribution should be able 
> to install to a hard disk from floppy disks, configure the basic 
> behaviour, and manage packages (at least, keep track of the installed 
> packages, files owned by a given package,...). The main work here is to 
> keep track of the ongoing elks developments.
> 

Agree.

> 	7) A graphical environment, with a window manager and applications (at 
> least, terminal). Again, it may be dificult to be done with 640k. 
> Compliance with X would be great, but may be impossible ;-)
> 

There was a little talk about this topic on irc some days ago.. but i
guess i need to make some research on this before giving a valid
opinion.

> 	As you notice, many of the features are actually outside the elks 
> kernel itself, but are perceived by user like a whole.
> 

Well your comments are VERY welcome, and we sure appreciate the fact of
taking some time to provide this feedback.. this is will be of great use
for the team... hopefully we will keep getting feedback from you, and
meet on irc :)
best wishes

Mike

> 
> Miguel Bolanos wrote:
> > Good day to all,
> > 
> > The project seems to be finally awaking from a very long period of
> > inactivity, this can be reflected not only by the traffic on the mailing
> > list, but on the amount of people hanging around at the irc channel and
> > the quality of the discussions over there.
> > 
> > Based on this facts, I believe that it is important that all the people
> > involved and interested in ELKS, provide their own opinions on what the
> > future of ELKS should be... I know of many wanting to have specific
> > features that are not currently in the kernel.. and others that as well
> > have interesting ideas for code reduction and improvements. So if you
> > are one them, please feel free yourself, as all this feedback is
> > important for us upgrade the TODO and roadmap of the project.
> > 
> > The current things that are been done are:
> > 
> > - Creation of an additional kernel that will use linux 2.6 coding style,
> > this is been done because we are looking forward to enable the
> > possibility of including support for 8086 and similar on the official
> > linux kernel as an option... of course this is will take a long time,
> > and doesn't mean that work on the current "production kernel" will be
> > depricated or anything like that, we which to encorage you to keep
> > contributing on the "production" kernel.. and the "new" kernel project
> > will be a work in parallel that at some point will have all this
> > improvements on the production kernel merged.
> > 
> > - A possibility of using gcc to create 8086 binaries might be a
> > possibility with a patch created by our irc friend boto. If the tests of
> > this are successful we will enable elkscmd to let the users decide if
> > they which to use gcc-8086 or our current bcc :)
> > 
> > Anyways thats all for now. Hope to hear back from all.
> > best wishes
> > 
> > Mike
> > 
> > -
> > 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: Future of ELKS

[Eduardo Pereira Habkost]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

On Thu, May 20, 2004 at 09:15:28AM -0600, Miguel Bolanos wrote:
<snip>
> 
> > 
> > 	4) Self contained compiler. The compiler should be able to compile 
> > itself, and thus run on elks (as you know, other open source compilers 
> > compile themselves in the "./configure; make; make install" procedure). 
> > Also, a "make" runnable on elks is needed.
> 
> we will see what comes along with this gcc-8086 thing.

I guess that running gcc on 8086 will not be possible (or at least it will
not be a simple task), the cc1 binary on my i386 is 2MB, and it will not
be smaller if built for running on 8086. gcc is not a small compiler. The
point is making a 8086 target for gcc. Running gcc on 8086 is another story,
and I guess that is almost impossible. (and not worth, at least for me)

The issue about running a compiler in a 8086 is that it is too
small. Running a good compiler and development environment on such small
hardware is not easy, and if we choose go this way, we should choose
leaving away other things that we would like, including gcc-8086. If we
choose that all development environment neede to build elks should run
on 8086, too, we will have additional limitations, and we will need first:

1. Create a good development environment that runs on elks (we don't
   have it). This environment will have all limitations that the 8086
   hardware will impose to us
2. Make elks build using it

IMHO, this would be almost impossible.

> 
> > 
> > 	5) More applications. Editors, web browsers, email/news clients,... 
> > What about games? Can roge run on elks? Roge would be the killer app for 
> > elks ;-) Such applications may be dificult to be run on 8086/640k, 
> > but... you know: say "it is impossible", and someone will do it just to 
> > laugh at you.
> > 
> 
> Well basicaly, we need to make a clear point. ELKS is an Embeddable
> linux kernel subset.. not a distro.. BUT... i guess that in the mean
> time we will find a way to put all this stuff together to make elks
> actually worth the try.

Hey, someone know if a 8086 is fast enough run emulators for those old
8-bit game consoles?  8)

> 
<snip>
>

--
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Future of ELKS

[Andrey Romanenko]

hi there,

>Hey, someone know if a 8086 is fast enough run emulators for those old
>8-bit game consoles?  8)
>
>  
>
it depends on what performance you expect from it. I would say it 
capable of running CP/M and all software of those days. But if you meant 
hardware emulation lets say ZX_SPECTRUM_48 - my answer is NO! absolutely 
impossible 10 times slower than required. You need at least 386dx33.

Andrey

Re: Future of ELKS

[Dan Olson]

> hi there,
>
> >Hey, someone know if a 8086 is fast enough run emulators for those old
> >8-bit game consoles?  8)
> >
> >
> >
> it depends on what performance you expect from it. I would say it
> capable of running CP/M and all software of those days.

It'll run CP/M-86 nativly, and if you have a V20 or V30 you can even run
8080 code nativly!

 But if you meant
> hardware emulation lets say ZX_SPECTRUM_48 - my answer is NO! absolutely
> impossible 10 times slower than required. You need at least 386dx33.

I have a Commodore VIC-20 emulator that runs on the 80286!

	Dan

Re: Future of ELKS

[Javier Sedano]

Hi,

Eduardo Pereira Habkost wrote:
> 
> I guess that running gcc on 8086 will not be possible (or at least it will
> not be a simple task), the cc1 binary on my i386 is 2MB, and it will not
> be smaller if built for running on 8086. gcc is not a small compiler. The
> point is making a 8086 target for gcc. Running gcc on 8086 is another story,
> and I guess that is almost impossible. (and not worth, at least for me)
> 

	I supposed so. gcc is bloatware for elks. Even "vi" is :-PPP

> The issue about running a compiler in a 8086 is that it is too
> small. Running a good compiler and development environment on such small
> hardware is not easy, and if we choose go this way, we should choose
> leaving away other things that we would like, including gcc-8086. If we
> choose that all development environment neede to build elks should run
> on 8086, too, we will have additional limitations, and we will need first:
> 
> 1. Create a good development environment that runs on elks (we don't
>    have it). This environment will have all limitations that the 8086
>    hardware will impose to us
> 2. Make elks build using it
> 
> IMHO, this would be almost impossible.
> 

	Minix's ACK does so. Of course, it imposes limitations to the programs 
(the 64k limit), but is good enough for many applications. I heard 
something about ACK sources... did they free them?

Regards,


-- 
Javier Sedano Jarillo: javier.sedano@agora-2000.com
                        (http://www.it.uc3m.es/~jsedano)
Agora Systems, S.A.
C/Aravaca 12
E-28040 Madrid (Spain)
Tel.: +34 91 533 58 57
Fax.: +34 91 534 84 77
--------
do computers dream of electric penguins?

Re: Future of ELKS

[Gábor Lénárt]

Re,

On Thu, May 20, 2004 at 07:30:11PM +0200, Javier Sedano wrote:
> >I guess that running gcc on 8086 will not be possible (or at least it will
> >not be a simple task), the cc1 binary on my i386 is 2MB, and it will not
> >be smaller if built for running on 8086. gcc is not a small compiler. The
> >point is making a 8086 target for gcc. Running gcc on 8086 is another 
> >story,
> >and I guess that is almost impossible. (and not worth, at least for me)
> >
> 
> 	I supposed so. gcc is bloatware for elks. Even "vi" is :-PPP

Just visist www.cc65.org.

It's a C compiler (OK, it does not support all of the ANSI C though) for
6502 CPU family like 6510 used in Commodore 64. And there IS a full
GUI/Internet (!) enabled Operating System for C64 which is written in C, and
cc65 was used as C compiler for this project. This OS is named Contiki, and
it DOES support TCP/IP and others on an UNEXPANDED Commodore 64 (yeah, 64K
RAM and 8bit CPU running @ ~1MHz). Just visist:
http://www.dunkels.com/adam/contiki/ Contiki was ported to other systems as
well, even x86.

Ok, sure, cc65 can not compile itself, but 6502 CPU is a very limited
one compared even to 8086, the stack space is only 256 bytes, for example.
[so cc65 is a cross compiler]

Sorry, if this news is OT here though :)

The only meaning of my mail is the fact that 8086 if far much powerfull CPU
than 6502, so it SHOULD BE possible to write a good C compiler for it
which can even compile itself :) Though of course it should not be an
amazing fact, since some (...hmm...) years ago, 8086 was new and fresh ;-)

And again: sorry for the OT here ...

- Gábor (larta'H)
-
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: Future of ELKS

[Jody]

*snip*
> Just visist www.cc65.org.
>
> It's a C compiler (OK, it does not support all of the ANSI C though) for
> 6502 CPU family like 6510 used in Commodore 64. And there IS a full
> GUI/Internet (!) enabled Operating System for C64 which is written in C,
and
> cc65 was used as C compiler for this project. This OS is named Contiki,
and
> it DOES support TCP/IP and others on an UNEXPANDED Commodore 64 (yeah,
64K
> RAM and 8bit CPU running @ ~1MHz). Just visist:
> http://www.dunkels.com/adam/contiki/ Contiki was ported to other systems
as
> well, even x86.

Contiki is certainly an example for the little guys in the computer world,
proving that we can get stuff like a primitive port of Lynx running in a
cramped memory space.

> Ok, sure, cc65 can not compile itself, but 6502 CPU is a very limited
> one compared even to 8086, the stack space is only 256 bytes, for
example.
> [so cc65 is a cross compiler]

65xx/65816 are my most favored series of CPUs, and while the '816 has no
MMU or anything, it DOES have full 24-bit addressing instructions available
(NO SEGMENTATION) and a lot of other goodies that the 65xx didn't have, and
it only had 256 instructions so I suppose you would call it a RISC 16-bit
CPU. :)

> Sorry, if this news is OT here though :)

Slightly off-topic, but of course anything discussing stuff similar to ELKS
(running modern-ish stuff on really old hardware) and the possibility of
using that to enrich ELKS would always be welcome 'off-topic' conversation
for ELKS.

> The only meaning of my mail is the fact that 8086 if far much powerfull
CPU
> than 6502, so it SHOULD BE possible to write a good C compiler for it
> which can even compile itself :) Though of course it should not be an
> amazing fact, since some (...hmm...) years ago, 8086 was new and fresh
;-)

The 8086/88's biggest limitation has to be the segmented memory model to
retain compatibility with some old CPU (8085?) and these compatibility
efforts have hindered Intel CPUs for a long time...but even then, we DO
have two advantages over 'RISC-like' CPUs such as the 65xx[x] series with
our 8086/88 CPUs:

1.  CISC coding on the 80x86-series does more work with less memory
(unfortunately with more clock cycles though), thus saving us memory if we
(or our compiler) use the code very well, and
2.  The 80x86 has more than 64KB of RAM, typically 256KB (our minimal
target system) and up.

Considering that we are able to save memory with a complex instruction set,
and have more memory to work with as well, I think that anyone who writes a
program (save the kernel perhaps) that uses up more than 64KB of RAM in the
first place is either A: not writing the program with memory usage in mind,
which is critical on this platform more so than the 386+ counterparts, or
B: undertaking a LEGITIMATELY LARGE task, such as an X-like GUI or a C
compiler implementation.  For a minimal system of 256KB, we'll need the
core stuff (kernel, init, sh) to run in less than 128KB or so combined
(very very possible, especially with modular and optimized drivers when we
get there) and the C compiler to use around 128KB total, perhaps with some
sort of work file on a block device if it needs more space.  That's what
temporary files are for, no?

Just my $0.02, let me know if any of that stuff helps anyone.  I'm trying
to learn some C coding, so I can do something worth something on ELKS
instead of talking about it all the time, telling developers what direction
to go in, and saying "I'll write documentation for it but I can't yet
because it doesn't have a LILO equivalent yet..."

Jody

Re: Future of ELKS

[Gábor Lénárt]

Hello,

On Fri, May 21, 2004 at 10:15:23AM -0400, Jody wrote:
> Contiki is certainly an example for the little guys in the computer world,
> proving that we can get stuff like a primitive port of Lynx running in a
> cramped memory space.

Yes, some guys even does not beleive in his eyes when something runs with
less powerfull hw than a typical m$ os requires ;-))
Though it's not so amazing for me, since I've coded even tcp networking
for C64 once, though it was not finished at all becouse of lack of enough
free time (as usuall ...).

> 
> > Ok, sure, cc65 can not compile itself, but 6502 CPU is a very limited
> > one compared even to 8086, the stack space is only 256 bytes, for
> example.
> > [so cc65 is a cross compiler]
> 
> 65xx/65816 are my most favored series of CPUs, and while the '816 has no
> MMU or anything, it DOES have full 24-bit addressing instructions available
> (NO SEGMENTATION) and a lot of other goodies that the 65xx didn't have, and
> it only had 256 instructions so I suppose you would call it a RISC 16-bit
> CPU. :)

65816 has got 24 bit addressing (with storing bank number at the opcode
as well) but the area of these instructions are much weaker than bank
based instructions which work with the current data bank or such, and so on.
So it is not a TRUE 24 bit linear addressing platform, but it is closer the
goal than eg Enterprise with Z80 CPU where external logic maps some parts
of the 4Mbyte address space into the 64K address space of the Z80 CPU, sure
:) Sorry, though I'm familiar with 6502 and eg Z80, 65816 is known a little
by me, I've read only some dox, several years ago so maybe my knowledge on
it is quite limited ...

> > Sorry, if this news is OT here though :)
> 
> Slightly off-topic, but of course anything discussing stuff similar to ELKS
> (running modern-ish stuff on really old hardware) and the possibility of
> using that to enrich ELKS would always be welcome 'off-topic' conversation
> for ELKS.

OK, my only though was that even some 8bit hw has got the power to run an
ELKS-like OS. Just think on Enterprise-128, I've described above (4Mb
addressing page with "paging", though the base machine has got only
128K RAM by default, you can expand it).

This is quite interesting for me, since I've started develope a cross
platform '8 bit' OS tough not in C but mixed assembly and a 'C subset'
language, with a layered design (a 'monitor' layer with detect hw, provide
low level access to the hw, and loads and links the kernel & other drivers
on booting, and the arch independent kernel which only depends on the CPU
type, so all Z80 based machines should have run the same kernel but of
couse different monitor).

> > The only meaning of my mail is the fact that 8086 if far much powerfull
> CPU
> > than 6502, so it SHOULD BE possible to write a good C compiler for it
> > which can even compile itself :) Though of course it should not be an
> > amazing fact, since some (...hmm...) years ago, 8086 was new and fresh
> ;-)
> 
> The 8086/88's biggest limitation has to be the segmented memory model to
> retain compatibility with some old CPU (8085?) and these compatibility

Hmmm. I've known that it would be too complex to create a CPU with
linear addressing of 20bit address space (1Mbyte) so they've implemeneted
a segmented model. Sure, I could be wrong on this.

> efforts have hindered Intel CPUs for a long time...but even then, we DO
> have two advantages over 'RISC-like' CPUs such as the 65xx[x] series with
> our 8086/88 CPUs:
> 
> 1.  CISC coding on the 80x86-series does more work with less memory
> (unfortunately with more clock cycles though), thus saving us memory if we
> (or our compiler) use the code very well, and
> 2.  The 80x86 has more than 64KB of RAM, typically 256KB (our minimal
> target system) and up.
> 
> Considering that we are able to save memory with a complex instruction set,
> and have more memory to work with as well, I think that anyone who writes a
> program (save the kernel perhaps) that uses up more than 64KB of RAM in the
> first place is either A: not writing the program with memory usage in mind,
> which is critical on this platform more so than the 386+ counterparts, or
> B: undertaking a LEGITIMATELY LARGE task, such as an X-like GUI or a C
> compiler implementation.  For a minimal system of 256KB, we'll need the

Some C compilers for 8086 CPU was able to create multi segment programs
with even 'far' functions, pointers etc ... Of course it's quite ugly
compared to a linear model, but an optimalizing compiler should solve
the problem to do this quite efficiently eg with trying to keep stuffs
in one segment which refers each other quite often, or such.

> core stuff (kernel, init, sh) to run in less than 128KB or so combined
> (very very possible, especially with modular and optimized drivers when we
> get there) and the C compiler to use around 128KB total, perhaps with some
> sort of work file on a block device if it needs more space.  That's what
> temporary files are for, no?

Hmmm, the only problem with a native ELKS C compiler (which run on ELKS) is
optimalization. It's not too hard to write a C compiler. Even for resource
weak systems. But good optimization done by a modern compiler requires quite
large amount of CPU power and memory. So maybe it's quite hard to transform
a good old XT into an ELKS development and programming platform ;-)
Though I've write compiler myself it was for a self constructed language
and not for C (though the compiler itself was written in C), so 'writing
a C compiler' is not a topic which is known too much by me, as you see ...

> Just my $0.02, let me know if any of that stuff helps anyone.  I'm trying
> to learn some C coding, so I can do something worth something on ELKS
> instead of talking about it all the time, telling developers what direction
> to go in, and saying "I'll write documentation for it but I can't yet
> because it doesn't have a LILO equivalent yet..."

:)

- Gábor (larta'H)
-
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: Future of ELKS

[Alan Cox]

On Llu, 2004-05-24 at 10:29, Gábor Lénárt wrote:
> OK, my only though was that even some 8bit hw has got the power to run an
> ELKS-like OS. Just think on Enterprise-128, I've described above (4Mb
> addressing page with "paging", though the base machine has got only
> 128K RAM by default, you can expand it).

Dave Braun did a Unix v7 clone (UZI) for banked Z80.


As far as compilers and segmentation and the like go, the Xenix 286
people supported multisegment binaries and swapping of them on 286
systems, but not 8086. They used protected mode (obviously),
segmentation and carefully arranged segment numbering so that you could
deduce the next segment of a block of code or data.

-
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: Future of ELKS

[David Given]

Eduardo Pereira Habkost wrote:
[...]
> 1. Create a good development environment that runs on elks (we don't
>    have it). This environment will have all limitations that the 8086
>    hardware will impose to us
> 2. Make elks build using it
> 
> IMHO, this would be almost impossible.

Well... no!

People these days are used to very big computers. You don't realise just 
what's possible in a small amount of space. The granddaddy of Unix 
systems, the PDP11 [*], was a 64kB-64kB I/D system. Sound familiar? 
That's exactly the same as what's supported by ELKS.

As for compilers... well, I have a full ANSI C compiler that runs on 
CP/M. It runs in 64kB of memory shared between code and data and it'll 
generate moderately decent Z80 code. If that's possible, then a 
self-hosted ANSI C compiler for ELKS is certainly possible.

The problem is *finding* one... compilers are expensive technology, and 
there's only a few open-source compilers around. Most of them are pretty 
large. ELKS' current compiler, bcc, is a well-hacked version of Minix's 
compiler. It only supports K&R, with a nasty preprocessor that converts 
ANSI to K&R, but it will run self-hosted on Minix so it should run on 
ELKS, too.

And a development environment is not that complicated. All you need is 
to be able to run make, the compiler front end, and the compiler back 
end, concurrently. Add in init and that makes four processes. If each 
one of these uses its maximum of 128kB of memory that means it'll need 
512kB of memory. That's pushing it on a 640kB system, what with the 
kernel and system workspace in there, but manageable. On a 286 with a 
real MMU it's easy.

If Minix can do it, with its slow and inefficient microkernel, ELKS can 
certainly do it.

[...]
> Hey, someone know if a 8086 is fast enough run emulators for those old
> 8-bit game consoles?  8)

Nah. A 4.77MHz 8086 does not get a lot of work done. Say you want to 
emulate a 2MHz 6502, such as the BBC Micro... this means you have about 
two and a half cycles to emulate each 6502 cycle. Just not possible.


[*] Or maybe the PDP7. I always get the two confused.

-- 
dg@cowlark.com --- http://www.cowlark.com
My other account has a real signature.

Re: Future of ELKS

[Stefan de Konink]

> [...]
> > Hey, someone know if a 8086 is fast enough run emulators for those old
> > 8-bit game consoles?  8)
>
> Nah. A 4.77MHz 8086 does not get a lot of work done. Say you want to
> emulate a 2MHz 6502, such as the BBC Micro... this means you have about
> two and a half cycles to emulate each 6502 cycle. Just not possible.

Totally offtopic but I would like to know it. What if an entiere program
gets preprocessed, lets say optimized to run on a 8086. So a program reads
binary, disassembles, rewrites to 8086 code, reassembles and run.
Or am I talking garbage :S (I thought emulators did a JIT thing...)


Btw. If a mirror of the hacked elks code is needed, please give a shout.


Stefan

Re: Future of ELKS

[Chad Page]

On Fri, 21 May 2004, Stefan de Konink wrote:

> > > Hey, someone know if a 8086 is fast enough run emulators for those old
> > > 8-bit game consoles?  8)
> >
> > Nah. A 4.77MHz 8086 does not get a lot of work done. Say you want to
> > emulate a 2MHz 6502, such as the BBC Micro... this means you have about
> > two and a half cycles to emulate each 6502 cycle. Just not possible.

	Yup... the memory access speed is *much* slower for instance. 
When I was working on ELKS little tweaks which wouldn't be noticable on
even the Pentiums of the day - let alone today's HW - were *very*
noticable on the PC. 

> Totally offtopic but I would like to know it. What if an entiere program
> gets preprocessed, lets say optimized to run on a 8086. So a program reads
> binary, disassembles, rewrites to 8086 code, reassembles and run.
> Or am I talking garbage :S (I thought emulators did a JIT thing...)

	qemu does that on the fly - it usually outputs about 10
instructions per emulated one, in my experience.  J. Meyer has stated that
an 2ghz Athlon 64 runs at about the speed of a 200mhz ppc in qemu, for
example.  Might be possible to get a better code ratio against an 8-bit
system - Intel had direct code converters from 8080 code, but even then it
might be tricky.  But you would also have to emulate the graphics
hardware, which challenges faster systems quite a bit!

	It'd be interesting to emulate a high-density p-code system on an
8086 to fit more code into ELKS, but it'd likely be too slow in practical
use.
 
	- Chad

> Btw. If a mirror of the hacked elks code is needed, please give a shout.
> 
> 
> Stefan
> 
> -
> 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: Future of ELKS

[Gregg C Levine]

Hello from Gregg C Levine
Nice to see this list is still alive and kicking.
First off all, the 6502 processor is still alive and sqawking. I won't quote
the site name for it, since it will be given later in the thread.
And second, what's the satus of the ELKS code stored on the PlanetMirror
mirror? Or for that matter somewhere on the MIT server? Or even the Germany
Linux Labs site?

But a question does hit me, Chad, if your the same person who's early work
was last seen on the MIT server, what is the status of it? This is the not
really Linux, and certainly not ELKS stuff, from the period that started
when Linus started Linux.
Gregg C Levine obiwanthejediknight atsign att dot net
<This signature will be replaced, pending an approval from the Jedi Council.
>
----- Original Message ----- 
From: "Chad Page" <cpage@silcom.com>
To: "Stefan de Konink" <skinkie@xs4all.nl>
Cc: "David Given" <dg@cowlark.com>; <linux-8086@vger.kernel.org>
Sent: Thursday, May 20, 2004 11:39 PM
Subject: Re: Future of ELKS


>
> On Fri, 21 May 2004, Stefan de Konink wrote:
>
> > > > Hey, someone know if a 8086 is fast enough run emulators for those
old
> > > > 8-bit game consoles?  8)
> > >
> > > Nah. A 4.77MHz 8086 does not get a lot of work done. Say you want to
> > > emulate a 2MHz 6502, such as the BBC Micro... this means you have
about
> > > two and a half cycles to emulate each 6502 cycle. Just not possible.
>
> Yup... the memory access speed is *much* slower for instance.
> When I was working on ELKS little tweaks which wouldn't be noticable on
> even the Pentiums of the day - let alone today's HW - were *very*
> noticable on the PC.
>
> > Totally offtopic but I would like to know it. What if an entiere program
> > gets preprocessed, lets say optimized to run on a 8086. So a program
reads
> > binary, disassembles, rewrites to 8086 code, reassembles and run.
> > Or am I talking garbage :S (I thought emulators did a JIT thing...)
>
> qemu does that on the fly - it usually outputs about 10
> instructions per emulated one, in my experience.  J. Meyer has stated that
> an 2ghz Athlon 64 runs at about the speed of a 200mhz ppc in qemu, for
> example.  Might be possible to get a better code ratio against an 8-bit
> system - Intel had direct code converters from 8080 code, but even then it
> might be tricky.  But you would also have to emulate the graphics
> hardware, which challenges faster systems quite a bit!
>
> It'd be interesting to emulate a high-density p-code system on an
> 8086 to fit more code into ELKS, but it'd likely be too slow in practical
> use.
>
> - Chad
>
> > Btw. If a mirror of the hacked elks code is needed, please give a shout.
> >
> >
> > Stefan
> >
> > -
> > 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: Future of ELKS

[Dan Olson]

> > Hey, someone know if a 8086 is fast enough run emulators for those old
> > 8-bit game consoles?  8)
>
> Nah. A 4.77MHz 8086 does not get a lot of work done. Say you want to
> emulate a 2MHz 6502, such as the BBC Micro... this means you have about
> two and a half cycles to emulate each 6502 cycle. Just not possible.

Who said it had to be 4.77MHz?  I've seen at least 10MHz 8088s, and 286s
up to 20MHz I think, and of course both are 16 bit vs. 8.  Not to imply
that it's a good idea, just that it can be done if you clock the CPU fast
enough :)

	Dan

Re: Future of ELKS

[Jody]

> People these days are used to very big computers. You don't realise just
> what's possible in a small amount of space. The granddaddy of Unix
> systems, the PDP11 [*], was a 64kB-64kB I/D system. Sound familiar?
> That's exactly the same as what's supported by ELKS.
>
> As for compilers... well, I have a full ANSI C compiler that runs on
> CP/M. It runs in 64kB of memory shared between code and data and it'll
> generate moderately decent Z80 code. If that's possible, then a
> self-hosted ANSI C compiler for ELKS is certainly possible.

If the ELKS system as a whole is designed (evolved?) correctly, we will
certainly see the potential for a native C compiler within it.  By hacking
gcc to death, I hope we will reach this more quickly...

> The problem is *finding* one... compilers are expensive technology, and
> there's only a few open-source compilers around. Most of them are pretty
> large. ELKS' current compiler, bcc, is a well-hacked version of Minix's
> compiler. It only supports K&R, with a nasty preprocessor that converts
> ANSI to K&R, but it will run self-hosted on Minix so it should run on
> ELKS, too.

It doesn't yet, but then again, someone in here with the initiative can
surely "bcc-ize" bcc (if anything I have said ever sounded like utterly
crappy word chopping...that was it) but that will take a lot of work, just
like the proposed gcc-8086 attempts will.

> And a development environment is not that complicated. All you need is
> to be able to run make, the compiler front end, and the compiler back
> end, concurrently. Add in init and that makes four processes. If each
> one of these uses its maximum of 128kB of memory that means it'll need
> 512kB of memory. That's pushing it on a 640kB system, what with the
> kernel and system workspace in there, but manageable. On a 286 with a
> real MMU it's easy.

Of course if we write it right, there's the likelihood that we won't eat
entire segments with each process...which would be necessary for a 256K
working system in my opinion.

> If Minix can do it, with its slow and inefficient microkernel, ELKS can
> certainly do it.
>
> [...]
> > Hey, someone know if a 8086 is fast enough run emulators for those old
> > 8-bit game consoles?  8)
>
> Nah. A 4.77MHz 8086 does not get a lot of work done. Say you want to
> emulate a 2MHz 6502, such as the BBC Micro... this means you have about
> two and a half cycles to emulate each 6502 cycle. Just not possible.

Emulation and 8086 don't mix! *grin*

Jody

Re: Future of ELKS

[Eduardo Pereira Habkost]

[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]

On Fri, May 21, 2004 at 12:43:02AM +0100, David Given wrote:
> Eduardo Pereira Habkost wrote:
> [...]
> >1. Create a good development environment that runs on elks (we don't
> >   have it). This environment will have all limitations that the 8086
> >   hardware will impose to us
> >2. Make elks build using it
> >
> >IMHO, this would be almost impossible.
> 
> Well... no!
> 
> People these days are used to very big computers. You don't realise just 
> what's possible in a small amount of space. The granddaddy of Unix 
> systems, the PDP11 [*], was a 64kB-64kB I/D system. Sound familiar? 
> That's exactly the same as what's supported by ELKS.
> 
> As for compilers... well, I have a full ANSI C compiler that runs on 
> CP/M. It runs in 64kB of memory shared between code and data and it'll 
> generate moderately decent Z80 code. If that's possible, then a 
> self-hosted ANSI C compiler for ELKS is certainly possible.
> 
> The problem is *finding* one... compilers are expensive technology, and 
> there's only a few open-source compilers around. Most of them are pretty 
> large. ELKS' current compiler, bcc, is a well-hacked version of Minix's 
> compiler. It only supports K&R, with a nasty preprocessor that converts 
> ANSI to K&R, but it will run self-hosted on Minix so it should run on 
> ELKS, too.
> 

Okay, that is not *really* impossible. Not technically impossible.
The question is: we have people that can do it?

What I mean is: do we want and have people that could do the work
of making or porting a good compiler work on the 8086?

As you said: compilers are expensive, or in other words: this require
lots of work. The question is: we have enough people that would do this
work? Technically, this *is* possible, you are right, but my question is:
the ELKS project is interested in spending efforts directed to creating a
good development environment (read: a good compiler, a 'make', linker,
and their friends, and that makes the work of creating and porting
applications not so expensive) that runs on ELKS? This environment could
be the better we can do for the 8086, but it could have limitations
that the "bloated" tools (*hint* GNU *hint*) don't have (yes, yes,
I know someone can make a "perfect" system that do wonderful things,
but we still don't have it). I would like to know if we want this.

> And a development environment is not that complicated. All you need is 
> to be able to run make, the compiler front end, and the compiler back 
> end, concurrently. Add in init and that makes four processes. If each 
> one of these uses its maximum of 128kB of memory that means it'll need 
> 512kB of memory. That's pushing it on a 640kB system, what with the 
> kernel and system workspace in there, but manageable. On a 286 with a 
> real MMU it's easy.

What I mean by "development environment", is what I said above: a good
compiler a 'make' or similar tool, a linker, and their friends. It is not
so complicated, but someone should code it. Do we have people that can
do this? If someone wants to do it, he is very welcome. But do we want
to spend efforts doing this? Will it be worth? I don't know. For me it
is not worth, just because I don't want to run a compiler on my 8086,
but someone could really want it, who knows?

Anyway, if we want to take this way, someone should work on that
development environment, or the project would stop again.

> 
> If Minix can do it, with its slow and inefficient microkernel, ELKS can 
> certainly do it.
> 
> [...]
> >Hey, someone know if a 8086 is fast enough run emulators for those old
> >8-bit game consoles?  8)
> 
> Nah. A 4.77MHz 8086 does not get a lot of work done. Say you want to 
> emulate a 2MHz 6502, such as the BBC Micro... this means you have about 
> two and a half cycles to emulate each 6502 cycle. Just not possible.

Ohh, sad. I should forget it.

> 
> 
> [*] Or maybe the PDP7. I always get the two confused.
> 

-- 
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Future of ELKS

[David Given]

On Friday 21 May 2004 14:24, Eduardo Pereira Habkost wrote:
[...]
> What I mean is: do we want and have people that could do the work
> of making or porting a good compiler work on the 8086?
[...]
> but my question is:
> the ELKS project is interested in spending efforts directed to creating a
> good development environment (read: a good compiler, a 'make', linker,
> > and their friends, and that makes the work of creating and porting 
> applications not so expensive) that runs on ELKS?

Well... Minix has all this. It all works, it's all debugged, it's all open 
source. It all runs self-hosted on Minix with a 64/64 split address space.

The only problem is that Minix' compiler, bcc, only supports K&R C. However, 
there are tools available that will convert ANSI C into K&R C; that's how 
ELKS is currently built. Admittedly, you don't get the superior type checking 
that ANSI C gives you, but it does build.

As I see it, there are three real options here:

a) Put quite a lot of effort into writing an ANSI C compiler that will run 
self-hosted on ELKS (and Minix).

b) Give up on building anything self-hosted and cross-compile everything using 
gcc or Turbo C++ (which produces good code, and has been released for free by 
Borland: http://community.borland.com/article/0,1410,20841,00.html).

c) Do both. Cross-compile with an ANSI C compiler, but build self-hosted using 
bcc and unprotoize. This has the advantage that we get the advanced type 
checking of ANSI C if we cross-compile, but the lightweight toolchain of K&R 
if it's built self-hosted.

Interestingly enough, (c) is already what we have. It's just that nobody has 
really got around to setting up a self-hosted system. There's nothing 
technically stopping it from working, except for the occasional minor bug.

(BTW, if you look at the mailing list archives, way back in the mists of time 
there was a six-month discussion on what compiler to use. Let's not do that 
again...)

On Friday 21 May 2004 15:15, Jody wrote:
[...]
> The 8086/88's biggest limitation has to be the segmented memory model to
> retain compatibility with some old CPU (8085?) and these compatibility
> efforts have hindered Intel CPUs for a long time...

Segmentation is also what makes ELKS work at all on the 8086. It acts as a 
poor-man's MMU. Without segmentation, you wouldn't be able to have 
relocatable processes; you wouldn't be able to do any kind of swapping or 
move code around at run time.

(Remember that a 64/64 process is using 16-bit points for everything. It never 
touches its segment registers. If you copy the process onto disk, reload it 
elsewhere, restore its registers but make sure that the segment registers 
point to its new location in memory, it'll never even notice.)

Yes, we *could* use some kind of larger memory model with bigger pointers, but 
I wouldn't recommend it. Using multiple segments makes stuff far more 
complicated --- particularly as ints and pointers will now be different sizes 
--- and any 8086 program that needs more than 128kB is probably too big 
anyway.

If you think 128kB of RAM is too small to do anything useful, I strongly urge 
you to go out and look into CP/M. Your average CP/M system had about 60kB 
free for user applications, shared between code and data. 8080 and Z80 code 
is significantly more verbose than 8086 code. But look at all those 
applications...

-- 
+- David Given --McQ-+ "I can handle myself. I've been in a fire fight.
|  dg@cowlark.com    | Well, I was in a fire.... Actually I was fired.
| (dg@tao-group.com) | from a fry cook opertunity." --- Firefly, _War
+- www.cowlark.com --+ Stories_

Re: Future of ELKS

[Michael McConnell]

David Given wrote:
> The only problem is that Minix' compiler, bcc, only supports K&R C. However, 
> there are tools available that will convert ANSI C into K&R C; that's how 
> ELKS is currently built. Admittedly, you don't get the superior type checking 
> that ANSI C gives you, but it does build.

Minix actually uses the Amsterdam Compiler Kit, and is invoked as 'cc'.

-- 
-- Michael "Soruk" McConnell
Eridani MailStripper -- www.eridani.co.uk/MailStripper -- Uncovers Everything!
                  /* Halley */  <--- Halley's Comment

Re: Future of ELKS

[David Given]

Michael McConnell wrote:
[...]
> Minix actually uses the Amsterdam Compiler Kit, and is invoked as 'cc'.

So it does --- I could have sworn it used bcc!

Having managed to track down a copy of the ACK 
(http://www.cs.vu.nl/vakgroepen/cs/ack.html), I notice that it actually 
seems to be a really quite sophisticated cross-platform cross-language 
compiler suite. Like a gcc-light.

It supports generating code for the PDP-11, VAX, 68000, SPARC, 8080, 
8086, 80386, Z80, Z8000 and the NS16032. It understands Modula-2, K&R C, 
Fortran, Pascal, Basic, Occam, and --- get this --- *ANSI C*.

I haven't got it working yet, but has anyone used its ANSI C mode? How 
well does it work? Would this be suitable for a self-hosted ANSI C 
compiler for the 8086? A brief glance at the license would seem to 
indicate it's OSI compatible, but IANAL.

(The other thing I'm wondering about --- since the ACK has been around 
for years, and was well-known back in the early days of ELKS, why did 
ELKS standardise on bcc rather than the ACK?)

-- 
dg@cowlark.com --- http://www.cowlark.com
My other account has a real signature.

Re: Future of ELKS

[Chad Page]

On Sat, 22 May 2004, David Given wrote:

> (The other thing I'm wondering about --- since the ACK has been around 
> for years, and was well-known back in the early days of ELKS, why did 
> ELKS standardise on bcc rather than the ACK?)

	It was known of at the time (mid-90's), but not free then - I just
did some quick research and it appears to have been relicensed BSD-style
just last year.  If it's code quality is better than bcc it might be worth
looking into - when I tried running ELKS through copt the result was
noticably faster, and a bit smaller, but much less stable. 

	- Chad

Re: Future of ELKS

[Jody]

*snip*

> On Friday 21 May 2004 15:15, Jody wrote:
> [...]
> > The 8086/88's biggest limitation has to be the segmented memory model
to
> > retain compatibility with some old CPU (8085?) and these compatibility
> > efforts have hindered Intel CPUs for a long time...
>
> Segmentation is also what makes ELKS work at all on the 8086. It acts as
a
> poor-man's MMU. Without segmentation, you wouldn't be able to have
> relocatable processes; you wouldn't be able to do any kind of swapping or
> move code around at run time.
>
> (Remember that a 64/64 process is using 16-bit points for everything. It
never
> touches its segment registers. If you copy the process onto disk, reload
it
> elsewhere, restore its registers but make sure that the segment registers
> point to its new location in memory, it'll never even notice.)
>
> Yes, we *could* use some kind of larger memory model with bigger
pointers, but
> I wouldn't recommend it. Using multiple segments makes stuff far more
> complicated --- particularly as ints and pointers will now be different
sizes
> --- and any 8086 program that needs more than 128kB is probably too big
> anyway.

Disclaimer:  I don't know a ton about low-level 8086 programming, only
pieces, please correct me if I am wrong as it will benefit myself as well
as the community.

I was trying to hint that we should try to use less than 64KB per process
in another unquoted snippet...I don't know everything about 8086's but I do
know that there are PLENTY of operating systems from the past that have
done "a lot of stuff" in what we now see as a miniscule space.  I've seen a
program in less than 256 bytes (1 page in 6502 memory space) of 6502 asm
that would do a dual-algorithm decompression of the data it was attached
to.  I myself wrote an RLE decompressor to be attached to a BASIC program
that took up 110 bytes of code and about six bytes of data.  It's not
8086-related per se, but it does show that it can very well be done.  Also,
remember that good old DOS ran on PCs with 256KB of RAM or *less*
sometimes, and still did a lot of useful things.  Eventually, even when DOS
was rewritten in C (MS-DOS 3.0?) it STILL ran on ancient and "modern"
configurations.

Anyone who thinks we should eat one or two entire segments for a program
like cp, mv, rm, mkdir, or kill, is in my opinion self-limiting to the
segmentation of the architecture.  Please "think outside the box" on this.
If we write a good memory manager and programs honor the allocations of
that memory manager, there is no reason we can't break processes down into
smaller pages.  A relocatable executable format rather than dependency on
segments to do everything for us would probably help.

> If you think 128kB of RAM is too small to do anything useful, I strongly
urge
> you to go out and look into CP/M. Your average CP/M system had about 60kB
> free for user applications, shared between code and data. 8080 and Z80
code
> is significantly more verbose than 8086 code. But look at all those
> applications...

I certainly believe that 128KB is more than enough for a lot of things, and
that we're so used to inherent code bloat in both Linux and Windows that we
don't remember the "old ways" of coding sometimes...it's all about
squeezing that last 64 bytes, no?
What can I do in 64 bytes?  With my favorite CPU (6502) I can write a
routine that'll clear the entire contents of the C64's 320x200x1-bit screen
so it can be used for something, like a GUI.  I can write something that
will act as a supplementary buffer for my serial port.  I can store a small
icon (say a 2-bit color 16x16 icon for a CGA screen) for my simple
GUI...why use 64KB per process when we're already so limited and you don't
need all that?  Simplified versions of stuff like cp and mv could take only
a few kilobytes at most if written strategically.

I'm too lazy to type more, please respond to my comments ASAP so hopefully
I get them before work.  Everyone take care, and good hacking!

Jody

Re: Future of ELKS

[jb1]

On Fri, 21 May 2004, Jody wrote:

...
> GUI...why use 64KB per process when we're already so limited and you don't
> need all that?  Simplified versions of stuff like cp and mv could take only

64K is the *maximum*, not *minimum*, addressable space for the 8086/8088
without changing a segment register; the minimum is 16 *bytes*. The
segment registers merely provide a 64K window into linear address space on
16 byte boundaries. For example, the hexadecimal segment:offset addresses
5550:0010 and 5551:0000 are the same memory location. It's up to the 
programmer or the operating system to prevent the 5551:XXXX area from 
being corrupted by something that should only alter 5550:000X.

Re: Future of ELKS

[Chad Page]

On Sat, 22 May 2004 jb1@btstream.com wrote:

> 5550:0010 and 5551:0000 are the same memory location. It's up to the 
> programmer or the operating system to prevent the 5551:XXXX area from 
> being corrupted by something that should only alter 5550:000X.

	Unfortunatly there isn't anything the OS can do in real mode to
prevent it... some fancier 808x boxes had some level of hardware memory
protection, and it was added to the 286 in protected mode.

	- Chad

Re: Future of ELKS

[Gábor Lénárt]

On Fri, May 21, 2004 at 02:38:59PM -0400, Jody wrote:
> I was trying to hint that we should try to use less than 64KB per process
> in another unquoted snippet...I don't know everything about 8086's but I do

You can use even 1 byte granulity if you wish, sure it's now hw based.
Segmenting in real mode (as 8086 does) only means that a 64K "window"
starts at every 16 bytes. Sure these "windows" (segments) are overlapping
each other! I mean:

linear_address="segment_address"*16+offset

where "segment_address" is the number you write into the segment registers
(CS,DS,ES,SS, and FS and GS in the case of 386+).  Of course you can say
that at (segment:offsset)  0x1000:0 you have a memory allocation using
32 bytes memory, and at 0x1002:0 you have another block and such. The
only problem that there is no hw protection so setting data segment register
(DS) to 0x1000 you should NOT write offsets greater than 0x1F (decimal 31),
since you have got 32 bytes there, remember?

The 64K is the maximum. Like in 286 protected mode, but there you have got
hw mechanism to limit eg to 32 byte, and an exception will be generated if
you try to use an offset greater than the size of the segment (in protected
mode segment registers stores selectors which are indices in the LDT or GDT
- local/global descriptor tables, which are describing linear starting
address of the segment, protection and so on).

And at 386, you can choose between byte or page granility, with selecting
page granulity (4096 bytes) you can create 4G wide segment. That is the
so called linear addressing used by almost all modern OSes on 386+. This
is possible, since there is another mechanism over segmenting at 386+ named
paging. But is's another story :)


- Gábor (larta'H)
-
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: Future of ELKS

[Javier Sedano]

Hi,

Miguel Bolanos wrote:
>>
>>	1) Be more "user friendly". Of course, and elks user is probably a 
>>hacker, at least to an extent, so "user friendly" does not mean "dumb 
>>winuser friendly", but neither should mean "only-the-programmer 
>>friendly". It should not be a specific feature, but an elks way of live. 
>>I would like that anybody able to compile and run a Linux kernel was 
>>able to compile and run an elks kernel.
>>	I know it is not the kind of work that hackers love (I hate it!), but 
>>it is mandatory for plain final users.
> 
> 
> OK I still don't get very clear your idea of  "User friendly"... when u
> refer to Linux kernel compilation.. i guess u mean kernels dialog ? We
> are working a making elks work like regular linux kernel... but this
> will take a little while.. and having dialog .. hehe this will take yet
> another bit more. Anyways if this is not what you mean, please tell some
> more specific ideas of your definition to "User friendly" :)
> 

	It is not a matter of "I don't like this method" or "I prefer GUI". I 
don't mind to edit a txt file to config something, or type "./configure; 
make; make install".
	How would I say this...? Think on Minix. It is not friendly for typical 
Windows users, but you type "make" and it works, or provides some error 
message. If your hardware is supported, it works; otherway, it doesn't. 
You don't need to do some magic with pitrix in order to create a minixfs 
for minix, or boot minix. There is not "magic", just a basic OS and HW 
knowledge.
	I am not talking on specific errors or bugs on elks, but talking on a 
"letter of intention". That is: do you want elks to be used by hackers? 
Or do you want elks to be used by final users? CAUTION: the first option 
is also aceptable (that is, OS for embebded systems, or a base for other 
to provide the user-friendliness), but... what does the programmer want? 
That's the way the freesoftware works.


Regards,

-- 
Javier Sedano Jarillo: javier.sedano@agora-2000.com
                        (http://www.it.uc3m.es/~jsedano)
Agora Systems, S.A.
C/Aravaca 12
E-28040 Madrid (Spain)
Tel.: +34 91 533 58 57
Fax.: +34 91 534 84 77
--------
Imagina que hay una guerra... y no vamos nadie.

Re: Future of ELKS

[Dan Olson]

> > 	3) Include IP support. Again, it is available for hackers, and only a
> > few interfaces are supported (slip?, ppp?), and are a bit hidden and the
> > routes are very, very hard-coded. Ethernet support, at least for some
> > cards (NE2000, that common 8bit 3com whose name i can not remember,...)
> > would be really great.
>
> Is on the TODO since a while :)

Great, that's exactly what I'd love to see, support for a NE2000 or 3C503
(Etherlink II, how could you forget ?:) and a few apps like telnet and
ftp.

	Dan

Re: Future of ELKS

[Arnaldo Carvalho de Melo]

Dan Olson wrote:

>>>	3) Include IP support. Again, it is available for hackers, and only a
>>>few interfaces are supported (slip?, ppp?), and are a bit hidden and the
>>>routes are very, very hard-coded. Ethernet support, at least for some
>>>cards (NE2000, that common 8bit 3com whose name i can not remember,...)
>>>would be really great.
>>>      
>>>
>>Is on the TODO since a while :)
>>    
>>
>
>Great, that's exactly what I'd love to see, support for a NE2000 or 3C503
>(Etherlink II, how could you forget ?:) and a few apps like telnet and
>ftp.
>
>  
>
Does anybody here considered porting uIP to ELKS? 
http://www.sics.se/~adam/uip/ I've been talking with friends about
the work I've been doing on factoring net/ code in 2.5/2.6 and how it 
could relate to 2.6-tiny (http://www.selenic.com/tiny-about/),
i.e. making it possible to disable lots of features that aren't strictly 
required to reduce the size footprint of networking
support, Matt already managed to boot linux-tiny (2.6) with as little as 
2MB of ram, more can be done and in fact several
folks are contributing patches for CONFIG_TINY with several patches 
making its way to mainline.

That, and the fact that we already have mm/nommu.c in 2.6 makes the 
future look bright for an eventual merge of ELKS into
mainline, as I discussed with Eduardo :-)

- Arnaldo

Re: Future of ELKS

[Alan Cox]

Umm Elks already has tcp/ip

Re: Future of ELKS

[Gábor Lénárt]

On Fri, May 21, 2004 at 06:08:33AM -0300, Arnaldo Carvalho de Melo wrote:
> Does anybody here considered porting uIP to ELKS? 

ELKS does support tcp/ip AFAIK.

And uIP is a great stuff for eg Contiki :) but not for ELKS, because it's
FAR-FAR too simple, it victimizes almost everything (size, performance,
features, ...) just for small memory footprint. So it's good for eg a
Commodore 64 situation (or only even a few kilos of RAM ...), but not for eg
ELKS. Probably. But maybe you have got an PC/XT with only 128K RAM or such
;-)

But you can consider lwIP (or something similar I can't remember the name).
However I don't know tcp/ip implementation of ELKS so I don't know it would
worth or not ...

- Gábor (larta'H)
-
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: Future of ELKS

[Pat Gilliland]

Very Large Caveat: I am an "end user" rather than a "developer" so all I
can offer is help with documentation and very sincere thanks to all of you
who have helped keep ELKS going.

My wish list for ELKS would include:
      a comb image that continues to a 720 floppy.
      an easy way to install from a (720) floppy to hard drive.
      some sort of modem support .

Now as for the future - a few questions. 
What is the realistic future of the 8088 architecture?  
Are there really enough machines left in existence to give ELKS a practical
purpose, or will it remain the play thing old hardware addicts?  I suspect
that even in the third world the 8088 as hardware is dead. 

A few thoughts from un-educated user space:

As I recall, the 386 (or was it 286) or better can run a number of
applications as if they were on seperate virtual 8086 machines.  Could this
be of use to simulate large clusters on a single box?  Could a number of
virtual machines be used to simulate network topologies with ELKS virtual
boxes, ELKS based virtual routers and switches and ELKS based 
"compromised" virutual machines.

Related to virtual clustering, can the limited overhead and size of the
ELKS kernel be used to advantage somehow?  I'm thinking that a light weight
kernel would allow more resources for applications - use a smaller engine
to get more room in the passenger compartment.  

ELKS as I remember,  was intially designed as an easier to understand
version of linux.  Should ELKS be kept intentionally simple as a kernel for
"student" use?

Can ELKS be used as a sort of nano-kernel used in keeping with the UNIX
ideal of creating simple inter-connectable tools?  I am way out of my depth
here, but my understanding is that some things work better in kernel space
than user space so would it be of any benefit to run applications each with
their own kernel?

Can ELKS be worked onto ultra-portable devices such as USB storage keys and
watches? Yes I realize that these devices do not in general currently have
processors but with modern chip techniques it should be simple to tuck an
8088 into some corner of the mask.  One could say browse to the files on a
keychain rather than having to mount and read it.  Reduce the form factor
further and you could have httpd on a business card to serve up your
resume, business website or what ever,  just plug it into an ethernet port
and it's there. To extend the idea - a tiny machine that serves data for a
specified number of times then rm -rf * 's it with no possiblity of user
intervention.  It could also incorporate onboard encryption and DRM - damn
there goes my soul straight to hell.   Limited play video, audio or any
other data you want. Take your key down to the video store and load up a
movie that deletes itself as it plays leaving an empty key for reuse.  Yes
I'm drifting off topic so lets just call it "prior art" and leave it that.

For the gamers, what about a video card with one ELKS processor _per pixel_
- it may not be at all efficient but would probably sell just for the
bragging factor.

An finally, I must admit it would be satisfying in a very twisted way to
make a beowulf cluster out of my two old laptops connected over a serial
link.

Pat G. 
Patrick Gilliland
InkPot Productions
www.inkpotproductions.ca
(613) 722-1439
Sent using cyberus.ca WebMail - http://www.cyberus.ca/

Re: Future of ELKS

[Miguel Bolanos]

Greetings,

On Thu, 2004-05-20 at 07:40, Pat Gilliland wrote:
> Very Large Caveat: I am an "end user" rather than a "developer" so all I
> can offer is help with documentation and very sincere thanks to all of you
> who have helped keep ELKS going.
> 

Great, we need doc writers :)

> My wish list for ELKS would include:
>       a comb image that continues to a 720 floppy.
>       an easy way to install from a (720) floppy to hard drive.
>       some sort of modem support .
> 

Noted.

> Now as for the future - a few questions. 
> What is the realistic future of the 8088 architecture?  
> Are there really enough machines left in existence to give ELKS a practical
> purpose, or will it remain the play thing old hardware addicts?  I suspect
> that even in the third world the 8088 as hardware is dead. 
> 

Well the charm of ELKS is that even though it is intended to be used on
8086 / 8088 and similar hardware, it doesn't necessarily need to be
loaded on "playing" old boxes.. but actually be applied to real
production stuff, my main example would be NASA's flightlinux.
Now i really thing that such hardware is not dead at all on the 3rd
world, in fact a few days ago i received an email from a Journalist in
London, willing to make a video-story about ELKS, and the benefits that
it can provide the 3rd world.

> A few thoughts from un-educated user space:
> 
> As I recall, the 386 (or was it 286) or better can run a number of
> applications as if they were on seperate virtual 8086 machines.  Could this
> be of use to simulate large clusters on a single box?  Could a number of
> virtual machines be used to simulate network topologies with ELKS virtual
> boxes, ELKS based virtual routers and switches and ELKS based 
> "compromised" virutual machines.

Doing such kind of cluster is actually in my _PERSONAL_ Todo list, but
as many other things in it.. if others are interested i'm open to do
team work :)

> 
> Related to virtual clustering, can the limited overhead and size of the
> ELKS kernel be used to advantage somehow?  I'm thinking that a light weight
> kernel would allow more resources for applications - use a smaller engine
> to get more room in the passenger compartment.  
> 

Even if we have a light kernel.. we will still require various nodes
(maybe 10) for the cluster to actually do useful things (my personal
thought)

> ELKS as I remember,  was intially designed as an easier to understand
> version of linux.  Should ELKS be kept intentionally simple as a kernel for
> "student" use?
> 

This is something that can be seen from different points of view... 
In one side we have current elks kernel.. its small, easy.. simple.. but
if you are for example willing to get started with elks to get enough
knowledge to then start contributing to the linux kernel, u will end up
with the surprise that the coding style on both is very different...
I started working on re-writing elks kernel code to be compatible with
regular linux kernel, this will still be of great educational use, for
the fact that it will not be compatible with the coding style, but also
will be small enough to understand by people interested in learning it.

> Can ELKS be used as a sort of nano-kernel used in keeping with the UNIX
> ideal of creating simple inter-connectable tools?  I am way out of my depth
> here, but my understanding is that some things work better in kernel space
> than user space so would it be of any benefit to run applications each with
> their own kernel?
> 

I'm more a candidate of user-space, but i guess others in here might
disagree with me, if it is the case, PLEASE lets us hear you :)
 
> Can ELKS be worked onto ultra-portable devices such as USB storage keys and
> watches? Yes I realize that these devices do not in general currently have
> processors but with modern chip techniques it should be simple to tuck an
> 8088 into some corner of the mask.  One could say browse to the files on a
> keychain rather than having to mount and read it.  Reduce the form factor
> further and you could have httpd on a business card to serve up your
> resume, business website or what ever,  just plug it into an ethernet port
> and it's there. To extend the idea - a tiny machine that serves data for a
> specified number of times then rm -rf * 's it with no possiblity of user
> intervention.  It could also incorporate onboard encryption and DRM - damn
> there goes my soul straight to hell.   Limited play video, audio or any
> other data you want. Take your key down to the video store and load up a
> movie that deletes itself as it plays leaving an empty key for reuse.  Yes
> I'm drifting off topic so lets just call it "prior art" and leave it that.
> 

Nice ideas.. this should be taken in consideration for EDE.
Neil would you please comment a bit here? 

> For the gamers, what about a video card with one ELKS processor _per pixel_
> - it may not be at all efficient but would probably sell just for the
> bragging factor.
> 

mmm.... This should be included on the notes to consider it once we get
a stable release of the kernel and ede.

> An finally, I must admit it would be satisfying in a very twisted way to
> make a beowulf cluster out of my two old laptops connected over a serial
> link.
> 

I'm looking forward to something like this too... please hang around,
and let us keep hearing from you... even join us on irc... Many things
can be done with ELKS... but to do this we need many kind of people...
coders, doc writers.. people giving feedback :)

I can tell that i feel very satisfied with the fact that many people has
provided feedback... this ensures me that elks still has long road to
go, and that the work that we all are doing is really worth it.

best wishes

Mike

> Pat G. 
> Patrick Gilliland
> InkPot Productions
> www.inkpotproductions.ca
> (613) 722-1439
> Sent using cyberus.ca WebMail - http://www.cyberus.ca/
> -
> 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: Future of ELKS

[Tommy McCabe]

Tommy McCabe <rocketjet314@yahoo.com> wrote:
--- Miguel Bolanos wrote:
> Good day to all,
> 
> The project seems to be finally awaking from a very
> long period of
> inactivity, this can be reflected not only by the
> traffic on the mailing
> list, but on the amount of people hanging around at
> the irc channel and
> the quality of the discussions over there.
> 
> Based on this facts, I believe that it is important
> that all the people
> involved and interested in ELKS, provide their own
> opinions on what the
> future of ELKS should be... I know of many wanting
> to have specific
> features that are not currently in the kernel.. and
> others that as well
> have interesting ideas for code reduction and
> improvements. So if you
> are one them, please feel free yourself, as all this
> feedback is
> important for us upgrade the TODO and roadmap of the
> project.
> 
> The current things that are been done are:
> 
> - Creation of an additional kernel that will use
> linux 2.6 coding style,
> this is been done because we are looking forward to
> enable the
> possibility of including support for 8086 and
> similar on the official
> linux kernel as an option... of course this is will
> take a long time,
> and doesn't mean that work on the current
> "production kernel" will be
> depricated or anything like that, we which to
> encorage you to keep
> contributing on the "production" kernel.. and the
> "new" kernel project
> will be a work in parallel that at some point will
> have all this
> improvements on the production kernel merged.
> 
> - A possibility of using gcc to create 8086 binaries
> might be a
> possibility with a patch created by our irc friend
> boto. If the tests of
> this are successful we will enable elkscmd to let
> the users decide if
> they which to use gcc-8086 or our current bcc :)
> 
> Anyways thats all for now. Hope to hear back from
> all.
> best wishes
> 
> Mike
> 
> -
> 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

A list of things:
1. Debug ELKS.
2. Replace the various vi flavors with e3, which has
already been ported, is easier to use, and is smaller.
3. Make sure the code is efficient as possible- 640KB
isn't a lot of room, and I would like a minimal system
to run in 256KB.
4. Get rid of the BIOS drivers and replace them with
ELKS drivers.
5. Get full 286 protected mode and extended memory
support.
6. Get all the drivers in current use out of "alpha
test".
7. Implement modules.
8. Implement PLIP.
9. Use all the space on the 1.44MB disks, and
differentiate between full3 and full5.
10. Make the devices in the image files depend on
kernel config options.
11. Make ELKS installable to a hard drive.
12. Use a more modern version of the Minix FS, or even
ext2.
13. A general code cleanup. Make ELKS
POSIX-compatible, for example, open(), read(),
write(), close(), fork(), and execve(), instead of
their ELKS counterparts. Get rid of the things such as
"the function to define a function" and
hard-to-understand things such as x->y->z, which takes
a paragraph to describe, let alone explain. Get rid of
the complex tangle of system calls to do things such
as use files.
14. Update the docs.
15. Get an ELKS GUI. Nothing fancy, with modes such as
320x200 to be compatible with CGA, but something like
the DOS GUIs of old (NOT Windows).
16. Make use of the PS/2, VGA, and FPU drivers in the
kernel.
17. Have a full choice between no FPU support,
hardware FPU support, or FPU emulation.
18. Get a different compiler, preferably one that is
ANSI-compatible, and use the whatever-it-is that
allows 1MB code segments.
19. Make the compilation as hassle-free as possible.

I have a bad hack of ELKS, which does compile,
available at 24.194.1.64. It is a standard HTTP server
with about 40KB/s of bandwidth, so don't hammer it.
Three big bugs:

1. I can't fit everything on the root disk,

2. Ash should be on the comb disk,

3. sys_execve and sys_open reutrn the 2 and 8 errors
on bootup.

Another bug, I don't know if it has been solved since
0.10, is that you can't login with ash as the default
shell.

And oppose bloat at all costs! I don't want ELKS to
bear the fate of MINIX, a half-maintained OS
half-incompatible with everything which half-works on
an 8086 and fully gobbles memory.




__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 




	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Future of ELKS

[BODRATO Stefano]

>This is quite interesting for me, since I've started develope a cross
>platform '8 bit' OS tough not in C but mixed assembly and a 'C subset'
>language, with a layered design (a 'monitor' layer with detect hw, provide
>low level access to the hw, and loads and links the kernel & other drivers
>on booting, and the arch independent kernel which only depends on the CPU
>type, so all Z80 based machines should have run the same kernel but of
>couse different monitor).

erm.. have a look at www.z88dk.org and, please, write us !!   :oP
(well, the whole old 8-bit era seems to be well represented here).

Never told about Z88DK for not going off topic, but it could be retargetted to the 8086 family and probably compiled with bcc or Borland.
I also heard that the sdcc staff had the thought to support the 80186 CPU, time ago, but it never happened.
Probably this is because the big number of already existing compilers.   I'm not proposing to do THAT job; it wouldn't make sense.

Anyway I don't think that the old 8 bit asm code can be compared EXACTLY to the 16 bit segmented one.
The 8086 code, in my opinion, is almost the 30% bigger than the Z80 one, expecially if we optimize it with relative jumps, 8 bit registers, etc.. ; just compare the opcode tables.