Fwd: Re: f-cpu and Debian
Following from previous discussions on "political" issues sparked by the
BitKeeper discussion I sent a message to a developer in the Freedom CPU
project asking what I as a Debian developer can do to assist the f-cpu
project.
---------- Forwarded Message ----------
Subject: Re: f-cpu and Debian
Date: Tue, 8 Oct 2002 19:36:22 CEST
From: whygee@club-internet.fr
To: russell@coker.com.au
hello,
----Message d'origine----
>De: Russell Coker <russell@coker.com.au>
>A: whygee@f-cpu.org
>Sujet: f-cpu and Debian
>Date: Tue, 8 Oct 2002 10:48:31 +0200
>
>I am a developer of Debian GNU/Linux. I like what your project is doing,
>while I can't commit any great amounts of time I would like to help out in a
>minor way if I can.
>
>Please tell me what can be added to Debian to make it a better platform for
>your f-cpu development work (and hopefully encourage Debian users to join
>your project).
>
>Anything that's not to difficult is something that I'll do myself. Anything
>that requires more time than I can spare I will post to the debian-devel
> list and hopefully someone else will be interested.
I have used Debian (1 year ago) and respect the
work of this great project. Now i use LFS on my own system
(whenever i can) and i download all the sources for
additional SW at the Debian repository. I am using and
developping a fork of LFS3.3 and I find anything i need
on debian.org :-)
I have also seen that the Hurd kernel has been ported
on Debian (or the contrary, who knows) and a FreeBSD
support team started working on using this other kernel.
This is a very good sign because F-CPU is probably
underused under Linux and some parts of a kernel
or another might need some changes.
Debian seems to have undertaken a huge work to :
- make a stable and reliable software base for linux
- "ported" this base to the Hurd and other architecture
So it is the most open, most portable and largest
resource of Free software that i know and the F-CPU
team members are often in contact with these
communities so this is not a wonder for me that Debian
is one of the preferred ways to go (even though
it will not be easy all the time and i'll certainly
use a LFS derivated system for my first runs).
When using a different architecture, there are a lot
of things to consider, particularly for such a
large software base as Debian :
- verify all the endianness problems in all packages
(F-CPU is little endian but can work with big endian
data : this might be a bit complex for network codes
that are used to single-endian CPUs)
- verify all the dependencies against architectural
specific code (inlines, PCI stuffs, hardcoded addresses...)
- verify that F-CPU idioms don't collide with existing ones
(for example, the "FCPU_*" name space should be unused
in all preprocessing directives and C/++ libraries)
- examine all the bootstrap-related problems (F-CPU
has no BIOS, but rather something that looks like
the monitors of the SPARC or ALPHA computers)
- create and verify new data types that are adapted to the
F-CPU principles : UMAX, SMAX, FPTR ...
(A certain F-CPU implementation instanciates a small
part of the F-CPU specification, which states that
the registers have a "default" width of 64 bits at
program startup, but the hardware can be larger ...)
[ read the F-CPU manual for more explanations ]
Integer numbers can give rise to troubles if
not used carefully, though it supports at least
8, 16, 32 and 64-bit wide data, and 64-bit pointers
[though pointers should not have a size, but be defined
just as : "up to as wide as a register"]
A lot of these problems are linked to the compiler
and we have not ported GCC decently yet. The other parts
come from the way developers program .... And this is
where the Debian project is of critical usefulness.
Any company or structure could simply use GCC to recompile
the existing applications and port their SW base to F-CPU.
However F-CPU will be underused, particularly because most
computers now are 32-bit ...
F-CPU has more registers, much wider registers, more adressing
range, and SIMD capabilities since the beginning, compared to
a SPARC, MIPS-32 or x86 computer. Maybe most of the work can
reuse MIPS-64 or ALPHA-specific code. But this will not be
enough to exploit the SIMD operators and the potentially larger
registers (a simple line in a configuration file is enough
to make a 128-bit wide computer, or 256-bit, or any other power
of two...). Recompilation is not enough to speed things up,
some critical algorithms and coding practices must be reviewed.
For example, glibc, mpeg and jpeg libraries, X (though i'd
rather stick with DirectFB and XDirectFB...), network, etc.
The kernel side will be a whole other project on its own
and AFAIK it's not the main subject of concern for Debian.
So if Debian can do something, the first is to inspect all
the existing packages for conflicts or problems, in order
to make a "F-CPU white list". To do this, there should be
a coding advice list, but the above gives you an good idea.
I am here if you need more help (though my paid job doesn't
leave much time).
When the "white list" is ready, the remaining packages
can be examined and then modified more or less deeply,
on a case by case basis. But this work will require that
a working GCC port and a whole F-CPU simulator is ready
(not yet, it's still going to take a long while).
So the first thing to do is know which packages
do not need modifications :-) i presume that it is going
to take a while, asking all the package maintainers
which of their package comply to some rules. Maybe we must
write a survey and send it to all the maintainers ?
You are free to copy this message wherever needed.
You can also post technical questions to the
english f-cpu mailing list.
Best regards,
>Russell Coker
YG
-------------------------------------------------------
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: