On Wed, 25 Apr 2012 08:40:58 GMT
Brian Vito wrote:
> I've put together a rudimentary chart of acme chords -- if anyone has
> any suggestions, revisions, corrections, etc., they would be greatly
> appreciated. Eventually the chart will form part of an introduction to
> acme for non-programmers.
>
On Wed, 25 Apr 2012 23:38:01 -0400
Russ Cox wrote:
> On Wed, Apr 25, 2012 at 4:13 PM, Strake wrote:
> > What the hell? This is a waste and a fault. long at least ought to be
> > at least a machine word.
>
> Use vlong. Why does it matter what it's called?
>
> > The main one is this: I have a 6
On Wednesday 25 of April 2012 15:32:06 erik quanstrom wrote:
> also, in case you missed it sizeof(int)==sizeof(long)==4 on both 32
> and 64 bit plan 9, so recompiled programs won't get bigger integers
> just for the recompiling.
pardon silly question, but... why, on 64bit machine, P9 uses 32bit i
> my impression is, int was supposed to match machine's preferred (best
> performance etc.) integeral datatype, and long was supposed to be enough to
> hold a pointer? (i.e., sizeof(long) >= sizeof(void*))
No, long is always 32-bit on Plan 9. uintptr is big enough to hold a pointer.
--
David du
> pardon silly question, but... why, on 64bit machine, P9 uses 32bit ints and
> longs?
>
> my impression is, int was supposed to match machine's preferred (best
> performance etc.) integeral datatype, and long was supposed to be enough to
> hold a pointer? (i.e., sizeof(long) >= sizeof(void*))
many existing C programs (and not just on Plan 9) think long is 32 bits, or
don't care.
those that do care don't work. for those that don't care, it doesn't matter.
it's quite difficult to decide automatically (eg, in a compiler) into which
category a program falls.
a compiler can't easily detect t
On Saturday 05 of May 2012 18:48:37 Charles Forsyth wrote:
> many existing C programs (and not just on Plan 9) think long is 32 bits, or
> don't care.
> those that do care don't work. for those that don't care, it doesn't matter.
> it's quite difficult to decide automatically (eg, in a compiler) in
On Sat, May 5, 2012 at 11:33 AM, dexen deVries wrote:
> On Wednesday 25 of April 2012 15:32:06 erik quanstrom wrote:
> > also, in case you missed it sizeof(int)==sizeof(long)==4 on both 32
> > and 64 bit plan 9, so recompiled programs won't get bigger integers
> > just for the recompiling.
>
>
> p
On Sat, May 5, 2012 at 1:48 PM, Charles Forsyth
wrote:
> if it's performance you're worried about, for programs that don't care
> about width, i'd expect 32 bits at least
> to match performance with 64 bits (if there's a measurable difference).
> for one thing, cache lines will contain
> more valu
> /mnt/view is used for that.
> open in olive will use it when in a
> terminal.
I tried this, but fails.
In /usr/octopus/port/lib/view.b, it issues plumb command
on Plan 9 terminal or gnome-open on Linux terminal.
It also says it cooperate with spooler of /usr/octopus/port/spooler.b
where it sa
On 05/05/2012 05:06 PM, Comeau At9Fans wrote:
> On Sat, May 5, 2012 at 1:48 PM, Charles Forsyth wrote:
>
> if it's performance you're worried about, for programs that don't
> care about width, i'd expect 32 bits at least
> to match performance with 64 bits (if there's a measurable
>
the consensus at the sunshine club is that to take advantage of the
wasted bits in a 64 bit pointer you should RENT THEM OUT!
brucee
--
Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)
12 matches
Mail list logo
