Re: f-cpu and Debian
On Wed, 9 Oct 2002 00:36, whygee@club-internet.fr wrote:
> 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.
Debian supports Hurd, and support for FreeBSD, NetBSD, and OpenBSD are all
being worked on.
> - 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...)
Debian currently runs on i386, SPARC, Alpha, M68k, PPC, ARM, MIPS, HPPA, IA64,
and S/390. I think that for the majority of software (and all the really
important stuff) the endianness issues and architecture dependencies have
been sorted out.
> - 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)
Why does it need this?
Why not __fcpu__?
> - 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)
Debian runs on SPARC and Alpha, shouldn't be any Debian issues there. Of
course someone has to write a boot loader...
Personally I'd rather see LinuxBIOS support and have the kernel and initrd in
the flash memory.
> - 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 ]
Initially we'll do without that support. Most programs don't need such
things, there's a lot of work to get it basically booting, we can go back and
add F-CPU specific things later.
> [though pointers should not have a size, but be defined
> just as : "up to as wide as a register"]
This sounds difficult.
> 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 ...
Actually most applications don't do anything that requires more than 32bit
math. None of the programs that I am currently working on do it.
64bit and SIMD should be good for SSL, GPG, bzip2, RAID-5, ray tracing, and
DVD/AVI playing. While these are among the greatest CPU hogs they are not
the most common tasks to use a computer for.
> 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...).
What do you mean here by "a simple line in a configuration file"? Are you
referring to configuration for a CPU emulator? If so where can I find a copy
of the FCPU emulator? Can I package it for Debian?
> 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.
Debian developers include people who work on upstream code development for
almost type of Linux software. While the Debian project is not focussed on
upstream development, to fulfil our aim of developing the best possible
packages for Debian we often need to write code for contribution upstream.
> 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).
Apart from the unlikely issue of programs using the macro name FCPU_ name
space (which is easy for an autobuilder to find and for us to fix once we get
things going properly) I don't think that there's anything that needs to be
done. Anything that could be done by static analysis has already been done
(and more) through the other ports.
> 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).
Do you have anything that's ready to be packaged for Debian? It doesn't have
to be fully operational, just to a stage where it can demonstrate the concept
and encourage people to try it out.
If I could package a CPU simulator that can run "hello world" in the FCPU
instruction set then it would excite many people, some of whom would be
likely to have the skill and time to contribute code.
Getting some FCPU related programs in Debian will raise the visibility of your
project a lot!
> 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 ?
I think that the results for all this can already be found in the build daemon
results:
http://buildd.debian.org/
The stats page http://buildd.debian.org/stats/ shows the statistics of how
many packages build on each platform (over 90% for every platform), and
allows querying which packages don't build for each platform.
So I think that almost 90% of the packages will have a chance of building for
FCPU without any modifications being required.
> You are free to copy this message wherever needed.
> You can also post technical questions to the
> english f-cpu mailing list.
Thanks, I have forwarded it to the debian-devel list (which is CC'd on this
reply).
--
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: