along the way...

along the way...

[ori]

I realized that the ape-erik patch was only available as a
diff on 9legacy.org, and was missing inttypes.h for arm,
so I fixed that omission, and imported it as something
that you can get with patch/apply:

	patch/apply ape-erik

I also ran into an issue with bad assembly in ape causing
crashes with any code that called getfcr(). There was a
variant of the code that implemented getfcr() uising VFP
sitting in /sys/src/libc/getfcr.vfp.s, so I replaced the
implementations in both libc and ape with it. It seems to
work, and matches what we have on 9front. It's certainly
no more wrong than what was there, but an extra pair of
arm-familiar eyes would be appreciated on that patch.

	patch/apply rpi-getfcr-vfp

Talking with miller off-list, making the default arm
floating point use vfp seems like a good idea, which
would probably make this patch the right choice.

I couldn't figure out how to delete files with patch/create,
so there will probably be a bit of junk left laying around
from the ape-erik patch application.

Re: [9fans] along the way...

[hiro]

is it worth using vfp when neon is around?
just curious...

Re: [9fans] along the way...

[Richard Miller]

> is it worth using vfp when neon is around?

Plan 9 arm source uses "vfp" as a generic term to mean modern
hardware floating point instruction set (as opposed to the old
arm7500 instruction set, which I suspect has always been purely
emulated since processors implementing this set were quite rare).
No use has been made in Plan 9 (as far as I know) of the vector
extensions which are the "v" part of vfp.

I think the neon instruction set is a superset of the vfp set
which 5l generates, so using vfp doesn't preclude something
like a vector library with neon support.

Re: [9fans] along the way...

[hiro]

yeah, that's what i mean. i was worried it wouldn't be a subset of
neon: i.e. that they might keep neon and get rid of vfp at some
point...