On Sat, Jul 16, 2011 at 11:39:50PM -0400, Joel C. Salomon wrote:
> On 07/16/2011 04:02 AM, tlaro...@polynum.com wrote:
> > What is the minimal hints the programmer shall give? At least
> > predicativity. I wonder what minimum set of keywords could be added,
> > say, to C, so that the situation can
On Sat, Jul 16, 2011 at 09:44:02PM -0400, erik quanstrom wrote:
> On Sat Jul 16 18:07:28 EDT 2011, fors...@terzarima.net wrote:
> > > to the actual hardware, then you need to write new compilers and
> > > recompile everything every few years.
> >
> > you do anyway. i don't think i've used a distri
On Sun, 17 Jul 2011 09:38:47 +0200 tlaro...@polynum.com wrote:
>
> Furthermore, I don't know for others, but I prefer correctness over
> speed. I mean, if a program is proved to be correct (and very few are),
> complex acrobatics from the compiler, namely in the "optimization" area,
> able to wre
On Sat, 16 Jul 2011 23:10:24 +0200
simon softnet wrote:
> If it wasn't for this cancerous web applications ordeal, I would be happy
> with OpenBSD & rio,
> and maybe with pure Plan 9 in the future ..
You'd be missing the best of Plan 9. Actually, I really feel we already have
Plan 9 merged into
On Sun, Jul 17, 2011 at 01:44:11AM -0700, Bakul Shah wrote:
> On Sun, 17 Jul 2011 09:38:47 +0200 tlaro...@polynum.com wrote:
> >
> > Furthermore, I don't know for others, but I prefer correctness over
> > speed. I mean, if a program is proved to be correct (and very few are),
> > complex acrobati
On Sat, 16 Jul 2011 22:56:53 +0200
dexen deVries wrote:
> On Saturday 16 July 2011 21:54:33 erik quanstrom wrote:
> > it's interesting you bring this up. risc has largely been removed
> > from architectures. if you tie the instruction set and machine model
> > to the actual hardware, then you n
On Sunday 17 July 2011 12:02:45 tlaro...@polynum.com wrote:
> My woe is more that an optimization can say "this may improve speed (or
> may not, even slow down processing...)": OK. But an optimization
> that can break a program, that is an optimization whose correctness
> is not guaranteed, is some
CLONE_NEWNS?
2011/7/2 Jacob Todd :
> Private namespaces.
>CLONE_NEWNS?
privileged processes only
> Gcc has mutual incompatibilities between different versions of itself,
> caused by its attempts to correctly interpret the heavyweight C
> standards we have today, but I wouldn't say gcc is the big problem.
> Some of the most essential libraries in a Linux system are real
> bugbears to compile, p
On 07/17/2011 03:01 AM, tlaro...@polynum.com wrote:
> On Sat, Jul 16, 2011 at 11:39:50PM -0400, Joel C. Salomon wrote:
>> On 07/16/2011 04:02 AM, tlaro...@polynum.com wrote:
>>>I wonder what minimum set of keywords could be added,
>>> say, to C, so that the situation can be greatly
On Sun Jul 17 04:45:18 EDT 2011, ba...@bitblocks.com wrote:
> Also note that the ISA implementations these days are quite
> complex (perhaps even more than your typical program). We
> don't see this complexty because it is all hidden behind a
> relatively simple ISA. But remember the FOOF bug? U
> BTW, if I understand correctly the purpose of the next C standard, I
> guess there is no urge for kencc to support C99
> since it is already a transitory only partially supported standard.
ken's compiler supports the bits of c99 that people have found
important/useful. see /sys/src/cmd/cc/c99.
On Sun, Jul 17, 2011 at 8:24 AM, erik quanstrom wrote:
> i can't speak for vendors on why errata is sometimes nda,
one no-longer-existing vendor once told me that some errata could
expose them to patent lawsuits. They
were not sure so would not release such info until they had no choice.
> i'v
> > i've yet to see need-to-know
> > errata.
>
> it exists :-(
i'm sure it does. but that's not even the worst case. the
worse case is when there is no errata at all!
- erik
> > i've been able to upgrade my systems here through a number of µarches
> > (intel xeon 5[0456]00, 3[04]00, atom; amd phenom) that weren't around
> > when i first installed my systems, and i'm still using most of the original
> > binaries. the hardware isn't forcing an upgrade.
>
> But that's p
On Jul 17, 2011, at 11:26 AM, erik quanstrom wrote:
>> BTW, if I understand correctly the purpose of the next C standard, I
>> guess there is no urge for kencc to support C99
>> since it is already a transitory only partially supported standard.
>
> ken's compiler supports the bits of c99 that
On Sunday 17 July 2011 17:51:04 erik quanstrom wrote:
> the "real hardware" depends on the cisc layer. a significant amount of
> x86 performance depends on the fact that x86 isa code is very dense and is
> used across much slower links than exist within a core.
((at the risk of sounding very sil
On 03/07/2011 23:08, andrey mirtchovski wrote:
they've changed everything else in unix, why hold so tightly to the clearly
> unhelpful ideas?
because it's a cult. things don't make sense in cults. i encountered
the following quote the other day, which finally convinced me.
OK, maybe this is a
On Sun, Jul 17, 2011 at 11:51:04AM -0400, erik quanstrom wrote:
> [...]
>
> iirc, almost all isa -> µop translations are handled
> by hardware for intel. i shouldn't be so lazy and look this up
> again.
>From what I read, IIRC (for example in Hennessy and Patterson, some
years ago), even the x86
On Sun, 17 Jul 2011 10:50:50 -0400
erik quanstrom wrote:
> why do you think the size or complexity of the code has anything
> to do with it?
Good question. I'm not sure I an give a good answer. I do think systems get
less flexible as they get more complex. I suppose that isn't provable or alway
On Jul 17, 2011, at 8:24 AM, erik quanstrom wrote:
> On Sun Jul 17 04:45:18 EDT 2011, ba...@bitblocks.com wrote:
>
>> Also note that the ISA implementations these days are quite
>> complex (perhaps even more than your typical program). We
>> don't see this complexty because it is all hidden beh
> I am sure (or sure hope) things have changed but in at two cases in
> the past the vendor reps told me that yes the bug was known *after* I
> told them I has logic analyzer traces that showed the bug. One a very
> well known CPU vendor, the a scsi chip manufacturer.
unfortunately some companies
23 matches
Mail list logo
