i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
what do u think guys
--
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
On Wed, Apr 07, 2004 at 08:54:06PM +0800, Mohamed Aslan wrote:
> i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
> what do u think guys
That you are utterly unoriginal wanker, what else?
Previously Mohamed Aslan wrote:
> i wanna to rewrite a version of linux kernel from scratch in assembly
> for intel 386+ fo speed and a libc also in assembly for speed what do
> u think guys
Great idea. By the time you'll be done you will realize that 40 years
have passed, 386 has been obsolete for a few decades and the end result
is not really that much faster.
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Quote from "Mohamed Aslan" <[email protected]>:
> i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
> what do u think guys
Don't bother. Spending the time doing something else would almost certainly
be more productive overall.
IFF you are skilled enough to seriously contemplate doing it, why not start
thinking about a completely new operating system design instead? There is a
lot which I don't think will ever be done with GNU/Linux - why not plan for
the day we throw it all away and start again?
John.
"Mohamed Aslan" <[email protected]> writes:
> i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
> what do u think guys
Why not just write a program to translate 'C' code into assembly?
On Wed, 7 Apr 2004, Mohamed Aslan wrote:
> i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
> what do u think guys
You're 6 days late, nice try though.
On Wed, 2004-04-07 at 14:13 +0100, Sean Neakums wrote:
> Why not just write a program to translate 'C' code into assembly?
You mean like a .... compiler ? :)
--
Cioby
On Wed, 7 Apr 2004, Mohamed Aslan wrote:
> i wanna to rewrite a version of linux kernel from scratch in assembly
> for intel 386+ fo speed and a libc also in assembly for speed
> what do u think guys
> --
I have a version of libc that has a lot of code written in assembly.
All of the Linux interface, all the string stuff, etc. You can have a
copy, if you want. That is a start.
This will be a big project. There's a lot more to the Linux kernel than
just creating some I/O capability. Linux has to emulate Unix so it's
a lot more work than rolling your own 32-bit OS with a file-system.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Wed, 7 Apr 2004, Sean Neakums wrote:
> "Mohamed Aslan" <[email protected]> writes:
>
> > i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
> > what do u think guys
>
> Why not just write a program to translate 'C' code into assembly?
>
It's called a compiler and we already have several versions, none
optimum.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Wed, Apr 07, 2004 at 08:54:06PM +0800, Mohamed Aslan wrote:
> i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
> what do u think guys
That you should read the FAQ: http://www.tux.org/lkml/#s15-2
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
Hi Mohamed,
I am not sure if your intentions are real, but I am assuming they are.
Writing the linux kernel all in assembler would be almost impossible,
it has taken 10 years to get the kernel to the point it is in C, going
that all in ASM would be a) pointless and b) time consuming, your work
would be outdated before its done
Also, the technical know-how for such a task would be large, the kernel
is a collection of the knowledge, intelligence and time of hundreds of
people, I do not beleive one person could know or hold or the know how
for that (while some who do alot of hacking, linus, alan cox, etc may
know *alot*, i still don't beleive even they could do such a task)
However, if you are serious about something like this and have the
knowhow, time and will, you have a few options.
a) You could hack the kernel in C, including optimizing what is there,
making better algorithms of systems for doing things
b) You could convert some parts of the kernel to ASM for the i386 arch
specific stuff, if it can be as functional and have a usefull gain.
c) You could work on the GCC compiler for generating better assembly
code from the C output, I'm sure there are many areas this could be
improved.
d) You could work on libc, in a similar fassion to the above,
optimizing, fixing, improving and adding to it.
Best of luck with your adventures.
Cheers,
Trent
Bur.st
> i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
> what do u think guys
--
Trent "Lathiat" Lloyd <[email protected]>
Sixlabs.org (http://www.sixlabs.org/)
Bur.st Networking Inc. (http://www.bur.st/)
On Wed, 2004-04-07 at 14:54, Mohamed Aslan wrote:
> i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
> what do u think guys
this would be insanity. i would rather look at optimizing some of the
code from the kernel.
or, as mentioned before, write a new OS.
all OS:s today has some problems, and unix isnt ideal. neither is the
other ones, like windows or macos, which is based on BSD.
i believe that a team of coders, on full time to on some years, create a
new operating system, that could easily compete with unix's and windows.
but, ofcourse, this would require all development to stop on linux(if
the linux developers should do it).
and that isnt possible. so therefore development goes on to just do the
best thing possible with what we got today.
--
Regards, Redeeman
[email protected]
Richard B. Johnson wrote:
> On Wed, 7 Apr 2004, Sean Neakums wrote:
>
>
>>"Mohamed Aslan" <[email protected]> writes:
>>
>>
>>>i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
>>>what do u think guys
>>
>>Why not just write a program to translate 'C' code into assembly?
>>
>
>
> It's called a compiler and we already have several versions, none
> optimum.
>
Compilers probably will never be optimum. One has to choose
either to live with that or start "rewriting the kernel from
scratch for intel 386+" and so forth.
We all know what is appropriate on this list, so can the
interested parties - not me - please take this thread off
this list?
(directed at nobody in particular)
Thanks
> but, ofcourse, this would require all development to stop on linux(if
> the linux developers should do it).
> and that isnt possible. so therefore development goes on to just do the
> best thing possible with what we got today.
Not really - there are free, open source OS projects other than Linux in
fairly advanced stages technically, (I.E. they do more than just boot, and
can run real applications).
However, to take my attention away from Linux, an OS project would probably
have to be fairly revolutionary, and represent something that I honestly
believed could not ever be practically achieved with the Linux model.
The only obstacle that I can see to creating something better than the Linux
kernel, is that nobody is doing it yet.
John.
On Wednesday 07 April 2004 08:54 am, you wrote:
> i wanna to rewrite a version of linux kernel from scratch in assembly for
> intel 386+ fo speed and a libc also in assembly for speed what do u think
> guys
maybe you'd have fun with the LinuxBIOS crowd
http://www.linuxbios.org
--
Rob Couto [[email protected]]
Guys, gals,
you are all missing the point.
It is obvious that what we really need is a hand-optimized in-kernel
core LISP machine written in >i386 assembly, then we need to port the
rest of the kernel to run as LISP bytecode on top of that in ring1 (in
particular the security policies).
Of course, important privileged user-space such as glibc should be
ported to this highly efficient non-recursive LISP machine too for
efficiency and run on ring 2 for speed and security.
As a further benefit, this could provide us with a stable kernel binary
ABI via the LISP interfaces to which we could dynamically translate the
existing kernel modules on load, for which nvidia and the binary-only
Inifiband stack seem perfect candidates to secure industry buyin.
Oh, and of course this project needs to be managed via BitKeeper.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett
> It is obvious that what we really need is a hand-optimized in-kernel
> core LISP machine written in >i386 assembly, then we need to port the
> rest of the kernel to run as LISP bytecode on top of that in ring1 (in
> particular the security policies).
>
> Of course, important privileged user-space such as glibc should be
> ported to this highly efficient non-recursive LISP machine too for
> efficiency and run on ring 2 for speed and security.
Errr, no, I don't think so :-).
John.
> It is obvious that what we really need is a hand-optimized in-kernel
> core LISP machine written in >i386 assembly, then we need to port the
> rest of the kernel to run as LISP bytecode on top of that in ring1 (in
> particular the security policies).
..or just pass init=/bin/emacs to your bootloader :-).
John.
Naaah, too obvious, it will never get through ! :)
Regards
--
Emmanuel
I'm not young enough to know everything.
-- Oscar Wilde
On Wed, 2004-04-07 at 17:05, Lars Marowsky-Bree wrote:
> Guys, gals,
>
> you are all missing the point.
>
> It is obvious that what we really need is a hand-optimized in-kernel
> core LISP machine written in >i386 assembly, then we need to port the
> rest of the kernel to run as LISP bytecode on top of that in ring1 (in
> particular the security policies).
>
> Of course, important privileged user-space such as glibc should be
> ported to this highly efficient non-recursive LISP machine too for
> efficiency and run on ring 2 for speed and security.
>
> As a further benefit, this could provide us with a stable kernel binary
> ABI via the LISP interfaces to which we could dynamically translate the
> existing kernel modules on load, for which nvidia and the binary-only
> Inifiband stack seem perfect candidates to secure industry buyin.
this is a good idea, but i doubt that anyone would dare to do that :D
>
> Oh, and of course this project needs to be managed via BitKeeper.
>
>
> Sincerely,
> Lars Marowsky-Br?e <[email protected]>
--
Regards, Redeeman
[email protected]
Lars Marowsky-Bree wrote:
>Guys, gals,
>
>you are all missing the point.
>
>It is obvious that what we really need is a hand-optimized in-kernel
>core LISP machine written in >i386 assembly, then we need to port the
>rest of the kernel to run as LISP bytecode on top of that in ring1 (in
>particular the security policies).
>
>Of course, important privileged user-space such as glibc should be
>ported to this highly efficient non-recursive LISP machine too for
>efficiency and run on ring 2 for speed and security.
>
>
What you are talking about is a LISP machine micro-kernel in Ring0 which
sort of defeats the whole point of Linux being monolithic kernel. Also
couldn't we just run HURD, or for that matter EMACS ;-), as a kernel. I,
personally have come around to Linus point of view on the whole
micro-kernel thing so I don't see much of a advantage to this, as there
are other micro kernel projects ( HURD, Darwin/*BSD?).
-Aaron
On Wed, 07 Apr 2004 09:58:49 EDT, "Richard B. Johnson" said:
> It's called a compiler and we already have several versions, none
> optimum.
However, I do believe that all the currently supported compilers are able
to beat out any programmers over the long run - we can use asm tricks
to hand-tune very small sections of hot-spot code, but nobody can sustain
that level of hand-optimization for 10K or 20K lines of code.
Anybody thinking of this is almost surely better off spending their time
coming up with new and better algorithms.
Mohamed Aslan wrote:
>i wanna to rewrite a version of linux kernel from scratch in assembly for intel 386+ fo speed and a libc also in assembly for speed
>what do u think guys
>
>
I doubt you would be capable of generating assembly that would be any
faster than gcc, and you would inherit all the accidental difficulties
that come with engineering software at a lower-level.
-ryan
On Saturday 10 April 2004 19:59, J. Ryan Earl wrote:
> Mohamed Aslan wrote:
> >i wanna to rewrite a version of linux kernel from scratch in assembly for
> > intel 386+ fo speed and a libc also in assembly for speed what do u think
> > guys
>
> I doubt you would be capable of generating assembly that would be any
> faster than gcc, and you would inherit all the accidental difficulties
> that come with engineering software at a lower-level.
No, writing 'better than gcc' assembly is easy, gcc is far from stellar
in this regard. But it's painfully slow and non-portable.
--
vda
Denis Vlasenko wrote:
>>I doubt you would be capable of generating assembly that would be any
>>faster than gcc, and you would inherit all the accidental difficulties
>>that come with engineering software at a lower-level.
>>
>>
>
>No, writing 'better than gcc' assembly is easy, gcc is far from stellar
>in this regard. But it's painfully slow and non-portable.
>
>
How can "painfully slow and non-portable" be better? You mean faster?
Doesn't change the fact that I doubt he could write faster assembly. By
the time he got done doing it in assembly, gcc 5 would probably be out
generating much faster binaries, not to mention new major stable kernel
revisions.
On Saturday 10 April 2004 22:57, J. Ryan Earl wrote:
> Denis Vlasenko wrote:
> >>I doubt you would be capable of generating assembly that would be any
> >>faster than gcc, and you would inherit all the accidental difficulties
> >>that come with engineering software at a lower-level.
> >
> >No, writing 'better than gcc' assembly is easy, gcc is far from stellar
> >in this regard. But it's painfully slow and non-portable.
>
> How can "painfully slow and non-portable" be better? You mean faster?
*writing* asm code is painfully slow and code is not portable.
That's why no sane person will write kernel in asm.
--
vda
Rob Couto <[email protected]> writes:
> On Wednesday 07 April 2004 08:54 am, you wrote:
> > i wanna to rewrite a version of linux kernel from scratch in assembly for
> > intel 386+ fo speed and a libc also in assembly for speed what do u think
> > guys
>
> maybe you'd have fun with the LinuxBIOS crowd
> http://www.linuxbios.org
Likely just the opposite. We have written a C compiler that does not
implicitly use memory. Having had to reinvent the wheel a feel times
because of where we are working, it is clear that tools are your friend.
There is no shame in rewriting something when what exists does not work
for you and it matters. If your rewrite happens to be significantly faster
than the broken version that is just a plus. :)
Eric