Subject: Re: v1.2 Questions
To: None <berg@student.tu-freiberg.de>
From: Mark Brinicombe <amb@physig4.ph.kcl.ac.uk>
List: port-arm32
Date: 08/28/1996 23:04:16
>What are the main improvements in v1.2 againgst v1.1 ?

Ok this is difficult as there have been so many. Kernel changes are not so
significant as the kernels I have put online have been following NetBSD-current
anyway.
but there have been loads of changes system wide ...

The NetBSD CHANGES doc contains all the details (I will not post it here
as it is big).

>Isn't it so that the unstability of the Xarm is based on the 'floating
>point exeptions' errors made by the FPE ?
Nope
99% of Xarm crashes are SEGV's and not FP exceptions. The most common
SEGVS are caused by solid window drags and the cause of the SEGV has been
identified. The solution is being worked on atm

>If this is the case I think nothing will change until there is a new
>FPE (or the communication between FPU and FPE is improved) or a FPA.

The FPE cannot be improved very much as it is ARM Ltd FPE core.

Also changes to the FPE and handling FPE exceptions is probably more kernel
related.
>I've got some (v1.1) binaries which compiled but don't run (on
>v1.1) because of the 'floating point exeption'. Any suggests ???

What is the number of the floating point exeption ?
doing things with NaN's Inf or divide by zero will cause exceptions.
On a number of systems there errors do not cause exceptions and you just
get NaN or Inf results.

One thing that needs to be sorted is the fpsetmask() and associated
functions. These allow the fp expection masks to be changed. This could
be used to allow divide by zeros etc. not to cause an exception.

Part of the problem is that masking FP exceptions is system wide with the
ARM FPA/FPE. To support different exception masks for different processes
would mean FP instructions to save and load the FP control register on every
context switch.
I suppose one solution would be a way of setting the behaviour system wide.

The exception number is the key. In my book divide be zero exceptions etc
are ok as the result is undefined.

>Is it worth the work to install it and have I to install everything
>from scratch ?

If you have a 1.1 instalation it should not be too much work.
You may want to wait for the 1.2 final release though.
Things like the base set should install over the 1.1 base set.
(Don't reinstall etc or you loose your config stuff)

similarly the text and man sets install over the existing versions.

For the comp set you will need to remove the as252 and cc272 sets and can
then install the 1.2 comp set over the existing comp set.

The 1.2 comp set has a number of libc bug fixes in it.

Whether you want to upgrade X is another Q ..

>I think if shared libaries become available I have to reinstall obviosly
>everything new from scratch.
>Can someone tell me the current state of shared libaries ?

Non-existant ....

Ok The stumbling block on shared libraries is -fpic.
To build shared libraries we need position independant code. Currently
GCC/arm does not support the -fpic options so we cannot do this.

Solution: Somebody needs to write PIC support for GCC/arm

In the kernel team it would be either me or Rob who would look at that.
I have the kernel, 1.2 and everything else to do
rob has X11 to do so neither of us has the time.

This means all we can do is waiting until a release of GCC has -fpic for ARM.

I don't know whether anyone (Pete B.?) has any info on if this is likely to
happen soon.

If someone would like to do this great ...

Cheers,
				Mark

-- 
Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716