[9fans] 9pi + apple keyboard

[9fans] 9pi + apple keyboard

[James Chapman]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

Hi,

I just downloaded http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz and tried it out.

It booted, my logitech mouse worked but my apple keyboard (model A1243) doesn't work.

It produces the following error:

usbotg: ep 5.0 error intr 00000082

Best wishes,

James

[-- Attachment #2: Type: text/html, Size: 605 bytes --]

Re: [9fans] 9pi + apple keyboard

[Richard Miller]

> It booted, my logitech mouse worked but my apple keyboard (model A1243) doesn't work.

Some apple keyboards will work if you connect them via
a powered hub.

Some don't work at all, possibly because they don't implement
the usb HID boot protocol in quite the standard way.

There's a newer 9pi kernel in contrib/miller/9pi which has one more
usb kb+mouse driver correction.  You could try grabbing that and
copying it to the boot partition on the sd card and see if that
helps.

Re: [9fans] 9pi + apple keyboard

[James Chapman]

On Jan 22, 2013, at 12:39 PM, Richard Miller <9fans@hamnavoe.com> wrote:
> Some apple keyboards will work if you connect them via
> a powered hub.

Ok, I might try that.

> Some don't work at all, possibly because they don't implement
> the usb HID boot protocol in quite the standard way.
> 
> There's a newer 9pi kernel in contrib/miller/9pi which has one more
> usb kb+mouse driver correction.  You could try grabbing that and
> copying it to the boot partition on the sd card and see if that
> helps.

I tried the newer kernel. It still doesn't work (without a powered hub).

On linux with the raspberry pi, I have to plug the mouse in separately, if I plug it into the keyboard the pi doesn't boot.

Many thanks,

James

Re: [9fans] 9pi + apple keyboard

[a]

// On linux with the raspberry pi, I have to plug the mouse in
// separately, if I plug it into the keyboard the pi doesn't boot.

I've seen similar things with my apple keyboard on plan9 with
the pi (as well as the failure you noted earlier). the pi is *very*
picky about power. I do use the powered hub, but what made
a bigger difference for me was getting a beefier power supply
(most of the USB things you'll likely find lying around are in the
.5-1 amp range; optimally, the pi wants 1.2 or better).

Anthony

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

> I've seen similar things with my apple keyboard on plan9 with
> the pi (as well as the failure you noted earlier). the pi is *very*
> picky about power. I do use the powered hub, but what made
> a bigger difference for me was getting a beefier power supply
> (most of the USB things you'll likely find lying around are in the
> .5-1 amp range; optimally, the pi wants 1.2 or better).

i started with a big power supply (the apple one) and even so
had trouble with devices that one would have thought would work.

sort of sad when the keyboard uses more power than the computer.

anyway, for me both have been necessary.

- erik

Re: [9fans] 9pi + apple keyboard

[Nicolas Bercher]

On 22/01/2013 18:06, erik quanstrom wrote:
> sort of sad when the keyboard uses more power than the computer.

Sadly funny!

The PI is really power-efficient, this is quite impressive.
Thanks ARM!

I'm currently running two Atom-based servers for Linux and Plan9 (>=40W
each), and it is possible that the computation power I need could fit
in two Pis, except for the disk transfer rate that seems to be limited
by all-being-usb bootleneck when using two USB devices to read and
write data at the same time (backups from ethernet to USB hard drive).
(+ in the end, the limiting 100M-only built-in ethernet controller).

Nicolas

Re: [9fans] 9pi + apple keyboard

[Aram Hăvărneanu]

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=24&t=5830

If you don't want to read all that, here's a summary from Wikipedia:

  Originally the on-board USB ports were designed for USB devices
  using one "unit load" (100 mA) of current. Devices using more than
  100 mA were incompatible with the Raspberry Pi, and for them a
  self-powered USB hub was required. However, due to user feedback,
  the RPF, at the end of August 2012, decided to remove the USB
  polyfuses which largely caused this behaviour. However, the maximum
  current that can be delivered to a USB port on these modified boards
  is still limited by the capabilities of the power supply used, and
  the 1.1 A main polyfuse. Also a disadvantage of the current way the
  modification is done is that its no longer possible to hot-plug USB
  devices directly into the PI, when hotplugging is necessary it can
  be done in a hub.

-- 
Aram Hăvărneanu

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

> I'm currently running two Atom-based servers for Linux and Plan9 (>=40W
> each), and it is possible that the computation power I need could fit

the rpi is only half as fast as a sheeva plug.

- erik

Re: [9fans] 9pi + apple keyboard

[Lyndon Nerenberg]

On 2013-01-22, at 10:50 AM, Aram Hăvărneanu wrote:

> If you don't want to read all that, here's a summary from Wikipedia:

Summary: 2 + 2 != 5

Bugger.

Re: [9fans] 9pi + apple keyboard

[Harri Haataja]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

On 22 January 2013 19:06, erik quanstrom <quanstro@quanstro.net> wrote:

> > I've seen similar things with my apple keyboard on plan9 with
> > the pi (as well as the failure you noted earlier). the pi is *very*
> > picky about power.
>

USB power management is pretty smart in its way, but can do odd things. And
what different devices do seems to vary. I've tested a wireless dongle that
works in a hub (no extra power) connected to the pi, but won't even detect
when plugged in directly.

sort of sad when the keyboard uses more power than the computer.
>
>
Coming from the embedded side of things, it seems natural to me that the
electromechanical bits tend to eat most of the power budget. I have several
things where a burning indicator LED would more than double the overall
power consumption. On the other hand, good old raw LCD's basically take
nothing. You can run a pocket calculator on a thumbprint's worth of old
solar panel in room light. I always found that kind of amazing.

A desktop keyboard shouldn't be that demanding, though. Saving power just
probably hasn't been a priority in the design.

--
I appear to be temporarily using gmail's horrible interface. I apologise
for any failure in my part in trying to make it do the right thing with
post formatting.

[-- Attachment #2: Type: text/html, Size: 1944 bytes --]

Re: [9fans] 9pi + apple keyboard

[Richard Miller]

> the rpi is only half as fast as a sheeva plug.

... half as fast at doing what?

Re: [9fans] 9pi + apple keyboard

[Richard Miller]

> USB power management is pretty smart in its way

Only if the OS helps.

Re: [9fans] 9pi + apple keyboard

[Lluís Batlle i Rossell]

On Wed, Jan 23, 2013 at 10:36:52AM +0000, Richard Miller wrote:
> > the rpi is only half as fast as a sheeva plug.
>
> ... half as fast at doing what?

I support that it's only half as fast as a sheevaplug *compiling code*.
But of course the pi has a FPU, GPU, ...

Re: [9fans] 9pi + apple keyboard

[James Chapman]

Success!

On Jan 22, 2013, at 12:58 PM, James Chapman <james@cs.ioc.ee> wrote:
> On Jan 22, 2013, at 12:39 PM, Richard Miller <9fans@hamnavoe.com> wrote:
>> Some apple keyboards will work if you connect them via
>> a powered hub.
> 
> Ok, I might try that.

I changed the power supply to one that claims to provide 1.2A. This didn't appear to change anything.

My apple keyboard works with a powered hub, including with the mouse plugged into the keyboard.

The powered hub is, incidentally, a 23" Apple Cinema HD display (from approx. 2003) which works perfectly with 9pi at 1900x1200.

Many thanks Richard Miller!

Cheers,

James

Re: [9fans] 9pi + apple keyboard

[Richard Miller]

> But of course the pi has a FPU, GPU, ...

Indeed.

term% for (i in dh61 atom pi3 plug) {
	cpu -h $i -c 'cat /dev/cputype
	time factor 281476419553081 >/dev/null'
	}
Core i7 2293
0.07u 0.00s 0.07r 	 factor 281476419553081
Atom 1601
0.64u 0.00s 0.64r 	 factor 281476419553081
ARM11 700
1.18u 0.02s 1.20r 	 factor 281476419553081
ARM Marvell 88F6281 A0; arm926ej-s arch v5te rev 2.1 part 131 1200
90.31u 0.00s 90.39r 	 factor 281476419553081

Re: [9fans] 9pi + apple keyboard

[Nicolas Bercher]

On 23/01/2013 13:11, Richard Miller wrote:
>> But of course the pi has a FPU, GPU, ...
>
> Indeed.
>
> term% for (i in dh61 atom pi3 plug) {
> 	cpu -h $i -c 'cat /dev/cputype
> 	time factor 281476419553081>/dev/null'
> 	}
> Core i7 2293
> 0.07u 0.00s 0.07r 	 factor 281476419553081
> Atom 1601
> 0.64u 0.00s 0.64r 	 factor 281476419553081
> ARM11 700
> 1.18u 0.02s 1.20r 	 factor 281476419553081
> ARM Marvell 88F6281 A0; arm926ej-s arch v5te rev 2.1 part 131 1200
> 90.31u 0.00s 90.39r 	 factor 281476419553081

Interesting results, thank you!
The difference between the Pi and the Sheeva is quite huge,
I wasn't excepting such difference.  This seems to confirm my
initial thoughts regarding the Atom perfs.

Nicolas

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

> Interesting results, thank you!
> The difference between the Pi and the Sheeva is quite huge,
> I wasn't excepting such difference.  This seems to confirm my
> initial thoughts regarding the Atom perfs.

that's just for floating point, which the sheeva doesn't have.
the newer model from the same line does have floating point:

http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx

- erik

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

On Wed Jan 23 10:49:47 EST 2013, quanstro@quanstro.net wrote:
> > Interesting results, thank you!
> > The difference between the Pi and the Sheeva is quite huge,
> > I wasn't excepting such difference.  This seems to confirm my
> > initial thoughts regarding the Atom perfs.
>
> that's just for floating point, which the sheeva doesn't have.
> the newer model from the same line does have floating point:
>
> http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx

richard, thanks for the floating point.  this is good stuff.
this is better than 100x faster:

	; >/dev/null time factor 281476419553081
	146.60u 0.01s 148.24r 	 factor 281476419553081
	; >/dev/null time /sys/src/cmd/5.factor 281476419553081
	1.20u 0.01s 1.22r 	 /sys/src/cmd/5.factor 281476419553081

has anyone been able to recompile gs and then view man pages?
gs dies with a good old-fashioned stack smash.

do there need to be changes to /sys/src/libc/arm?

when i say the pi is slow, i mostly ment in integer performance,
and i/o.

		tcptest		"burncycles"
pi		   5.5MB/s	915.66u 0.02s 924.50r
kw		 15.8		463.26u 0.00s 463.34r
		(using old tcp)
atom		 55.9		457.58u 0.00s 457.68r (8259 eth)
i7 2539		118.0		78.24u 0.00s 78.30r
Xeon X5650	256.0 (10g)	8.79u 0.00s 8.83r
Xeon E31220	112.0		5.64u 0.00s 5.68r

(burncycles calculates the digits of pi using a taylor series
expansion.  it uses all the tricks in the book to generate as
few bits of the result per cycle possible, without being verbose,
obtuse, or off task.  obviously, it was an accident.
the very fast machines have the advantage of non-emulated
vlongs, running amd64 kernels)

- erik

Re: [9fans] 9pi + apple keyboard

[Richard Miller]

> has anyone been able to recompile gs and then view man pages?
> gs dies with a good old-fashioned stack smash.
>
> do there need to be changes to /sys/src/libc/arm?

Well, I see there's a getfcr.vfp.s but I think it would cause trouble
if you used it.  The default is carefully set to avoid floating point
exceptions, because armv6 needs software assistance to handle these
(which hasn't been written).

I have run gs successfully (once) with vfp - any particular man page
I should try?

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

On Wed Jan 23 17:21:41 EST 2013, 9fans@hamnavoe.com wrote:
> > has anyone been able to recompile gs and then view man pages?
> > gs dies with a good old-fashioned stack smash.
> >
> > do there need to be changes to /sys/src/libc/arm?
>
> Well, I see there's a getfcr.vfp.s but I think it would cause trouble
> if you used it.  The default is carefully set to avoid floating point
> exceptions, because armv6 needs software assistance to handle these
> (which hasn't been written).
>
> I have run gs successfully (once) with vfp - any particular man page
> I should try?

man -P 1 cat

- erik

Re: [9fans] 9pi + apple keyboard

[Richard Miller]

> man -P 1 cat

Works for me.  Have you updated your bcm kernel?  I fixed a vfp
context-switching error today.

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

everything's up to date & it looks unrelated to fp.

acid; new()
3346: SVC/SWI Exception	_main	MOVW.W	R14,#-0x14(R13)
3346: Prefetch Abort/Data Abort	main+0x4	MOVW	R0,argc+0(FP)
acid; step()
3346: Prefetch Abort/Data Abort	main+0x8	MOVW	$#0x0,R0
acid; step()
3346: Prefetch Abort/Data Abort	main+0xc	BL	gs_malloc_init
acid; next()
3346: Prefetch Abort/Data Abort	gs_malloc_init	MOVW.W	R14,#-0x14(R13)
no source for /tmp/gs/src/gsmalloc.c:496
3346: Prefetch Abort/Data Abort	gs_malloc_init+0x4	MOVW	R0,parent+0(FP)
3346: Prefetch Abort/Data Abort	gs_malloc_init+0x8	BL	gs_malloc_memory_init
3346: Prefetch Abort/Data Abort	gs_malloc_memory_init	MOVW.W	R14,#-0xc(R13)
3346: Prefetch Abort/Data Abort	gs_malloc_memory_init+0x4	MOVW	$#0x7c,R0
3346: Prefetch Abort/Data Abort	gs_malloc_memory_init+0x8	BL	malloc
3346: Prefetch Abort/Data Abort	malloc	MOVW.W	R14,#-0x1c(R13)
3346: Prefetch Abort/Data Abort	malloc+0x4	MOVW	R0,R7
3346: Prefetch Abort/Data Abort	malloc+0x8	MOVW	$#0x1,R6
3346: Prefetch Abort/Data Abort	malloc+0xc	CMP.S	$#0x20,R6
3346: Prefetch Abort/Data Abort	malloc+0x10	B.GE	malloc+0x160
3346: Prefetch Abort/Data Abort	malloc+0x14	MOVW	$#0x1,R3
3346: Prefetch Abort/Data Abort	malloc+0x18	MOVW	(R3<<R6),R3
3346: Prefetch Abort/Data Abort	malloc+0x1c	CMP.S	R3,R7
3346: Prefetch Abort/Data Abort	malloc+0x20	B.LS	malloc+0x2c
3346: Prefetch Abort/Data Abort	malloc+0x2c	MOVW	$arena,R3
3346: Prefetch Abort/Data Abort	malloc+0x30	MOVW	(R6<<2)(R3),R7
3346: Prefetch Abort/Data Abort	malloc+0x34	MOVW.S	R7,R4
3346: Prefetch Abort/Data Abort	malloc+0x38	B.EQ	malloc+0x6c
3346: Prefetch Abort/Data Abort	malloc+0x6c	MOVW	$#0x1,R5
3346: Prefetch Abort/Data Abort	malloc+0x70	MOVW	R6,R2
3346: Prefetch Abort/Data Abort	malloc+0x74	MOVW	(R5<<R6),R5
3346: Prefetch Abort/Data Abort	malloc+0x78	ADD	$#0x14,R5,R5
3346: Prefetch Abort/Data Abort	malloc+0x7c	ADD	$#0x7,R5,R5
3346: Prefetch Abort/Data Abort	malloc+0x80	MVN	$#0x7,R11
3346: Prefetch Abort/Data Abort	malloc+0x84	AND	R11,R5,R7
3346: Prefetch Abort/Data Abort	malloc+0x88	MOVW	R6,R1
3346: Prefetch Abort/Data Abort	malloc+0x8c	MOVW	R6,pow-8(SP)
3346: Prefetch Abort/Data Abort	malloc+0x90	CMP.S	$#0xc,R6
3346: Prefetch Abort/Data Abort	malloc+0x94	B.GE	malloc+0x140
3346: Prefetch Abort/Data Abort	malloc+0x98	RSB	$#0xe,R6,R3
3346: Prefetch Abort/Data Abort	malloc+0x9c	MOVW	R7,R0
3346: Prefetch Abort/Data Abort	malloc+0xa0	MOVW	R7,size+0(FP)
3346: Prefetch Abort/Data Abort	malloc+0xa4	MOVW	R3,R6
3346: Prefetch Abort/Data Abort	malloc+0xa8	MOVW	R3,n-12(SP)
3346: Prefetch Abort/Data Abort	malloc+0xac	MUL	R0,R3,R0
3346: Prefetch Abort/Data Abort	malloc+0xb0	BL	sbrk
3346: Prefetch Abort/Data Abort	sbrk	MOVW.W	R14,#-0x8(R13)
3346: Prefetch Abort/Data Abort	sbrk+0x4	MOVW	$bloc-SB,R11
3346: Prefetch Abort/Data Abort	sbrk+0x8	MOVW	(R11<<0)(R12),R7
3346: Prefetch Abort/Data Abort	sbrk+0xc	ADD	$#0x3,R0,R1
3346: Prefetch Abort/Data Abort	sbrk+0x10	MVN	$#0x3,R11
3346: Prefetch Abort/Data Abort	sbrk+0x14	AND	R11,R1,R4
3346: Prefetch Abort/Data Abort	sbrk+0x18	MOVW	R4,n+0(FP)
3346: Prefetch Abort/Data Abort	sbrk+0x1c	ADD	R4,R7,R0
3346: Prefetch Abort/Data Abort	sbrk+0x20	BL	_BRK_
3346: Prefetch Abort/Data Abort	_BRK_	MOVW	R0,#0x4(R13)
3346: Prefetch Abort/Data Abort	_BRK_+0x4	MOVW	$#0x18,R0
3346: Prefetch Abort/Data Abort	_BRK_+0x8	CDP	#0x0, #0x0, C(0), C(0), C(0), #0x0
3346: Prefetch Abort/Data Abort	_BRK_+0xc	RET
3346: Prefetch Abort/Data Abort	sbrk+0x24	MOVW	$bloc-SB,R11
3346: Prefetch Abort/Data Abort	sbrk+0x28	MOVW	(R11<<0)(R12),R6
3346: Prefetch Abort/Data Abort	sbrk+0x2c	MOVW	n+0(FP),R7
3346: Prefetch Abort/Data Abort	sbrk+0x30	CMP.S	$#0x0,R0
3346: Prefetch Abort/Data Abort	sbrk+0x34	MOVW.LT	$#0x17,R2
3346: Prefetch Abort/Data Abort	sbrk+0x38	MOVW.LT	$errno-SB,R11
3346: Prefetch Abort/Data Abort	sbrk+0x3c	MOVW.LT	R2,(R11<<0)(R12)
3346: Prefetch Abort/Data Abort	sbrk+0x40	MVN.LT	$#0x0,R0
3346: Prefetch Abort/Data Abort	sbrk+0x44	RET.LT.P	#0x8(R13)
3346: Prefetch Abort/Data Abort	sbrk+0x48	ADD	R7,R6,R0
3346: Prefetch Abort/Data Abort	sbrk+0x4c	MOVW	$bloc-SB,R11
3346: Prefetch Abort/Data Abort	sbrk+0x50	MOVW	R0,(R11<<0)(R12)
3346: Prefetch Abort/Data Abort	sbrk+0x54	SUB	R7,R0,R0
3346: Prefetch Abort/Data Abort	sbrk+0x58	RET.P	#0x8(R13)
3346: Prefetch Abort/Data Abort	malloc+0xb4	MOVW	n-12(SP),R7
3346: Prefetch Abort/Data Abort	malloc+0xb8	MOVW	R0,bp-16(SP)
3346: Prefetch Abort/Data Abort	malloc+0xbc	MOVW	bp-16(SP),R1
3346: Prefetch Abort/Data Abort	malloc+0xc0	CMN.S	$#0x1,R1
3346: Prefetch Abort/Data Abort	0x300000	no instruction
Notes pending:
	sys: trap: fault read va=0x300000
<stdin>:7: (error) follow(addr): can't read instruction: can't read address 0x300000: bad arg in system call

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

it appears that i shot myself in the foot with version skew with
the amd64-version of 5l.

i can't really explain how that happened, but a recompile has
sorted things out.

- erik

Re: [9fans] 9pi + apple keyboard

[Phineas Pett]

Hi,

I noticed I have this same problem with man -P on the Raspberry Pi
(though I remember that it worked initially).  What exactly did you
recompile?  The Raspberry Pi kernel?

Thanks,
Phin

On 1/23/13, erik quanstrom <quanstro@quanstro.net> wrote:
> it appears that i shot myself in the foot with version skew with
> the amd64-version of 5l.
>
> i can't really explain how that happened, but a recompile has
> sorted things out.
>
> - erik
>
>

Re: [9fans] 9pi + apple keyboard

[lucio]

> I noticed I have this same problem with man -P on the Raspberry Pi
> (though I remember that it worked initially).  What exactly did you
> recompile?  The Raspberry Pi kernel?

I just tried man -P cat on my sheevaplug, after rebuilding libraries
and binaries and found that aux/tr2post wasn't there.  I found it in
postscript/tr2post, now the command works.

++L

Re: [9fans] 9pi + apple keyboard

[Phineas Pett]

On 1/24/13, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
>> I noticed I have this same problem with man -P on the Raspberry Pi
>> (though I remember that it worked initially).  What exactly did you
>> recompile?  The Raspberry Pi kernel?
>
> I just tried man -P cat on my sheevaplug, after rebuilding libraries
> and binaries and found that aux/tr2post wasn't there.  I found it in
> postscript/tr2post, now the command works.
>

man -P cat works now.  Much thanks!  I verified that tr2post was missing
 from aux from my system as well.  Running:

mk install

in

/sys/src/cmd/postscript/tr2post

did the trick.

--
Phin

Re: [9fans] 9pi + apple keyboard

[lucio]

> mk install
>
> in
>
> /sys/src/cmd/postscript/tr2post

Ought to be part of mk install in /sys/src/cmd, I wonder if a patch to
the mkfile is warranted?

++L

Re: [9fans] 9pi + apple keyboard

[Richard Miller]

>> /sys/src/cmd/postscript/tr2post
>
> Ought to be part of mk install in /sys/src/cmd, I wonder if a patch to
> the mkfile is warranted?

It's been deliberately excluded -- /sys/src/cmd/mkfile:11

I wonder if anyone remembers why?

Re: [9fans] 9pi + apple keyboard

[lucio]

>>> /sys/src/cmd/postscript/tr2post
>>
>> Ought to be part of mk install in /sys/src/cmd, I wonder if a patch to
>> the mkfile is warranted?
>
> It's been deliberately excluded -- /sys/src/cmd/mkfile:11
>
> I wonder if anyone remembers why?

If we submit a patch, either somebody will remember why it was done or
it will be applied and then we can wait for the fallout.

++L

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

On Thu Jan 24 05:30:18 EST 2013, phineas.pett@gmail.com wrote:
> Hi,
>
> I noticed I have this same problem with man -P on the Raspberry Pi
> (though I remember that it worked initially).  What exactly did you
> recompile?  The Raspberry Pi kernel?
>
> Thanks,
> Phin
>
> On 1/23/13, erik quanstrom <quanstro@quanstro.net> wrote:
> > it appears that i shot myself in the foot with version skew with
> > the amd64-version of 5l.
> >
> > i can't really explain how that happened, but a recompile has
> > sorted things out.

i doubt this is the same thing.  it was a problem that was
entirely on the amd64 machine.  gs was aborting early in malloc.
this is what i did to fix it.

	; echo $objtype
	amd64
	; rm /sys/src/cmd/cc/*.a?
	; cd /sys/src/cmd;
	; for(i in 5[cl])@{cd $i; mk install;mk clean}
	; @{cd gs; objtype=arm mk install;mk clean}

i imagine that i simply left some junk around from before
the transition to 2mb pages.

i did have tr2post installed.

- erik

Re: [9fans] 9pi + apple keyboard

[Steve Simon]

hugo% history -D -d sourcesdump /n/sources/plan9/sys/src/cmd/mkfile
...
Feb 15 14:05:48 GMT 2005 /n/sourcesdump/2006/0321/plan9/sys/src/cmd/mkfile 2414 [jmk]
11c11
< BUGGERED=gc|lmlvideo|dwb|unix|perl|celp|mosml|ovac|vfs|aviation|tex
---
> BUGGERED=gc|lmlvideo|dwb|unix|perl|celp|mosml|ovac|vfs|aviation|_vnc|postscript

Re: [9fans] 9pi + apple keyboard

[Lluís Batlle i Rossell]

On Wed, Jan 23, 2013 at 04:10:48PM -0500, erik quanstrom wrote:
> On Wed Jan 23 10:49:47 EST 2013, quanstro@quanstro.net wrote:
> > > Interesting results, thank you!
> > > The difference between the Pi and the Sheeva is quite huge,
> > > I wasn't excepting such difference.  This seems to confirm my
> > > initial thoughts regarding the Atom perfs.
> > 
> > that's just for floating point, which the sheeva doesn't have.
> > the newer model from the same line does have floating point:
> > 
> > http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx
> 
> richard, thanks for the floating point.  this is good stuff.
> this is better than 100x faster:
> 
> 	; >/dev/null time factor 281476419553081
> 	146.60u 0.01s 148.24r 	 factor 281476419553081
> 	; >/dev/null time /sys/src/cmd/5.factor 281476419553081
> 	1.20u 0.01s 1.22r 	 /sys/src/cmd/5.factor 281476419553081

Umh how does 'factor' relate to a FPU?
I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in
a raspberrypi, and 0.05s in a sheevaplug, here.

> (burncycles calculates the digits of pi using a taylor series
> expansion.  it uses all the tricks in the book to generate as
> few bits of the result per cycle possible, without being verbose,
> obtuse, or off task.  obviously, it was an accident.
> the very fast machines have the advantage of non-emulated
> vlongs, running amd64 kernels)

What are these emulated vlongs? Would that mean an atom computer would run
relevantly faster i686 code over x86_64 code?

Regards,
Lluís.

Re: [9fans] 9pi + apple keyboard

[erik quanstrom]

> > 	; >/dev/null time factor 281476419553081
> > 	146.60u 0.01s 148.24r 	 factor 281476419553081
> > 	; >/dev/null time /sys/src/cmd/5.factor 281476419553081
> > 	1.20u 0.01s 1.22r 	 /sys/src/cmd/5.factor 281476419553081
>
> Umh how does 'factor' relate to a FPU?
> I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in
> a raspberrypi, and 0.05s in a sheevaplug, here.

factor on plan 9 uses floating point heavily.  rpi has floating point
hardware, and the sheeva plug does not.  (at least according to
the nda docs on the processor i read.)

> > (burncycles calculates the digits of pi using a taylor series
> > expansion.  it uses all the tricks in the book to generate as
> > few bits of the result per cycle possible, without being verbose,
> > obtuse, or off task.  obviously, it was an accident.
> > the very fast machines have the advantage of non-emulated
> > vlongs, running amd64 kernels)
>
> What are these emulated vlongs? Would that mean an atom computer would run
> relevantly faster i686 code over x86_64 code?

i think i said the opposite.  amd64 code heavily running vlongs
would run faster in long (64-bit) mode.  this is because since the registers
are 64-bit wide, normal 64-bit arithmatic can be computed directly
with machine instructions.  with a 32-bit machine, the compiler needs
to emulate a 64-bit operation since the registers available are not wide
enough.

(iirc, there were no atoms in 64-bit mode in the list.)

- erik

Re: [9fans] 9pi + apple keyboard

[Lluís Batlle i Rossell]

On Sat, Jan 26, 2013 at 07:12:50AM -0500, erik quanstrom wrote:
> > > 	; >/dev/null time factor 281476419553081
> > > 	146.60u 0.01s 148.24r 	 factor 281476419553081
> > > 	; >/dev/null time /sys/src/cmd/5.factor 281476419553081
> > > 	1.20u 0.01s 1.22r 	 /sys/src/cmd/5.factor 281476419553081
> > 
> > Umh how does 'factor' relate to a FPU?
> > I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in
> > a raspberrypi, and 0.05s in a sheevaplug, here.
> 
> factor on plan 9 uses floating point heavily.  rpi has floating point
> hardware, and the sheeva plug does not.  (at least according to
> the nda docs on the processor i read.)

Ah, all clear. Thank you!
I just thought of some discrepancy that can happen around linux/gnu, that could
be applied in your example. On a processor without FPU, these two situations can
happen with code that uses floating point operations:
- run code with FPU instructions, emulated by the kernel through exceptions
- run code compiled without FPU instructions, with floating point as non-FPU
  code.
The former runs quite slower than the latter.

> > > (burncycles calculates the digits of pi using a taylor series
> > > expansion.  it uses all the tricks in the book to generate as
> > > few bits of the result per cycle possible, without being verbose,
> > > obtuse, or off task.  obviously, it was an accident.
> > > the very fast machines have the advantage of non-emulated
> > > vlongs, running amd64 kernels)
> > 
> > What are these emulated vlongs? Would that mean an atom computer would run
> > relevantly faster i686 code over x86_64 code?
> 
> i think i said the opposite.  amd64 code heavily running vlongs
> would run faster in long (64-bit) mode.  this is because since the registers
> are 64-bit wide, normal 64-bit arithmatic can be computed directly
> with machine instructions.  with a 32-bit machine, the compiler needs
> to emulate a 64-bit operation since the registers available are not wide
> enough.
> 
> (iirc, there were no atoms in 64-bit mode in the list.)

Ok, thank you very much! I understood as if you had listed a 64-bit mode atom,
and these having some peculiar implementation of 64-bit operations (as too slow
microcode or something like that.

Best regards,
Lluís.