[9fans] speaking of kenc - Plan9

This is a discussion on [9fans] speaking of kenc - Plan9 ; On Thu, 2007-05-03 at 19:12 -0700, Lyndon Nerenberg wrote: > > As far as I can tell C (as in language) has always been a sort of > > a cross-paltform assembler. Its just sometimes you need hooks > > ...

+ Reply to Thread
Page 4 of 7 FirstFirst ... 2 3 4 5 6 ... LastLast
Results 61 to 80 of 121

Thread: [9fans] speaking of kenc

  1. Re: [9fans] speaking of kenc

    On Thu, 2007-05-03 at 19:12 -0700, Lyndon Nerenberg wrote:
    > > As far as I can tell C (as in language) has always been a sort of
    > > a cross-paltform assembler. Its just sometimes you need hooks
    > > to the native one. You might disagree -- but I still do code in
    > > assembly.

    >
    > That's called as(1).


    On any architecture with a non-trivial register allocation, the above
    statement does not apply.
    As far as performance goes you might be better off not using assembler
    to begin with. Compilers (at least the ones I work on) are quite smart
    in how they use precious resource such as registers, and unless you
    can hide everything away on the other side of the 'call' op you'd
    be in trouble mixing your code with what compiler had generated for
    you. GCC style asm inlines play nice with things like register
    allocator and instruction scheduler, where .s files don't.

    > I think 3B2 code deserves its own place in hell. Poring over the
    > ESS#5 code, someone found that there were lots of strcmp(p, "f(")
    > == 0 checks (I may have gotten the exact string wrong but it's
    > close). It took us a while to figure out why. Apparently, location
    > 0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when
    > programs blew up they were pointing to "f(", and the worlds most
    > amazing kludge for detecting nil pointers was born.


    What's 3B3 and ESS#5 ? ;-)

    Thanks,
    Roman.


  2. Re: [9fans] speaking of kenc

    don't get me wrong -- i'm not against assembly.

    i had quite a bit of fun earlier this year getting some stuff
    working on an hc08 (6800 family).

    - erik

    On Thu May 3 22:08:53 EDT 2007, rvs@sun.com wrote:
    > As far as I can tell C (as in language) has always been a sort of
    > a cross-paltform assembler. Its just sometimes you need hooks
    > to the native one. You might disagree -- but I still do code in
    > assembly. May be its a bad habit dating back to ZX80 times, dunno.
    >


  3. Re: [9fans] speaking of kenc

    >> That's called as(1).
    >
    > On any architecture with a non-trivial register allocation, the above
    > statement does not apply.
    > As far as performance goes you might be better off not using assembler
    > to begin with.


    Exactly. If you want asm, you know where to find it. These days, the
    cases where raw assembler really matters are significant enough that a few
    in-lines generally don't accomplish anything. Yes, you can pollute your C
    code with __asm(), but I could also argue for _f77() so that I could
    compile spice (or more importantly, dungeon) with cc. Where does it end?

    > Compilers (at least the ones I work on) are quite smart
    > in how they use precious resource such as registers, and unless you
    > can hide everything away on the other side of the 'call' op you'd
    > be in trouble mixing your code with what compiler had generated for
    > you.


    Sure, the compiler can assist with register allocation, but so can reading
    the ABI documentation. Once upon a time I spent way too much of my life
    optimizing MIPS cycles out of the distributed.net client instead of
    drinking beer. After watching the compilers blow away almost all of the
    machine code optimizations people proposed, I filed great chunks of
    in-lined cruft in the bin. The only asm code that mattered was the
    carefully tuned *long* unrolled loop bit-shifting stuff. And it had an
    execution time that made the call overhead invisible.

    > GCC style asm in-lines play nice with things like register
    > allocator and instruction scheduler, where .s files don't.


    Only in the cases where asm code doesn't provide enough benefit to be
    worthwhile.

    > What's 3B3 and ESS#5 ? ;-)


    A reasonable telephone switch billing system, and the worlds worst
    multi-user UNIX timeshare box. Perhaps not in that order. (Or maybe it
    *is* the right order.)


    --lyndon

    In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe

  4. Re: [9fans] speaking of kenc

    isn't it bleeding obvious by now that asm is dumb.
    a function call into something in a *.s file will do.
    you'll find a few entry points in your fave l.s.

    can i say dumb-asm on this list?

    i saw an attempt of ill-informed cleverness where spl() etc
    were picked up by the compiler and inlined.

    i guess he had nothing else to do with his life.

    maybe a 0.02% speedup.

    brucee

    On 5/4/07, Lyndon Nerenberg wrote:
    > >> That's called as(1).

    > >
    > > On any architecture with a non-trivial register allocation, the above
    > > statement does not apply.
    > > As far as performance goes you might be better off not using assembler
    > > to begin with.

    >
    > Exactly. If you want asm, you know where to find it. These days, the
    > cases where raw assembler really matters are significant enough that a few
    > in-lines generally don't accomplish anything. Yes, you can pollute your C
    > code with __asm(), but I could also argue for _f77() so that I could
    > compile spice (or more importantly, dungeon) with cc. Where does it end?
    >
    > > Compilers (at least the ones I work on) are quite smart
    > > in how they use precious resource such as registers, and unless you
    > > can hide everything away on the other side of the 'call' op you'd
    > > be in trouble mixing your code with what compiler had generated for
    > > you.

    >
    > Sure, the compiler can assist with register allocation, but so can reading
    > the ABI documentation. Once upon a time I spent way too much of my life
    > optimizing MIPS cycles out of the distributed.net client instead of
    > drinking beer. After watching the compilers blow away almost all of the
    > machine code optimizations people proposed, I filed great chunks of
    > in-lined cruft in the bin. The only asm code that mattered was the
    > carefully tuned *long* unrolled loop bit-shifting stuff. And it had an
    > execution time that made the call overhead invisible.
    >
    > > GCC style asm in-lines play nice with things like register
    > > allocator and instruction scheduler, where .s files don't.

    >
    > Only in the cases where asm code doesn't provide enough benefit to be
    > worthwhile.
    >
    > > What's 3B3 and ESS#5 ? ;-)

    >
    > A reasonable telephone switch billing system, and the worlds worst
    > multi-user UNIX timeshare box. Perhaps not in that order. (Or maybe it
    > *is* the right order.)
    >
    >
    > --lyndon
    >
    > In God we Trust -- all others must submit an X.509 certificate.
    > -- Charles Forsythe
    >


  5. Re: [9fans] speaking of kenc

    "Roman Shaposhnick" wrote in message
    news:1178243111.16650.1826.camel@work.sfbay.sun.co m...
    > P.S. Here at Sun I've been putting some of the GCC extensions
    > into Sun Studio, ...


    Here's hoping you require a command-line flag to enable them.
    As someone else noted, one way to check for many instances of
    GCC-dependency in a mass of source code is to use a compiler
    that *doesn't* support for the myriad GCC features. Some of
    the current Linux programmers have no idea when they have
    used GCC-specific features (usually quite unnecessarily).

  6. Re: [9fans] speaking of kenc

    having to code anything in assembler is a significant sign of failure:
    if it's on a general-puprose processor, we have failed to educate processor designers;
    if it's on (say) a DSP, it's a bit of a mixture of that and people thinking that
    language design stopped with C, so the language provides too little scope for a compiler sensibly to do the work.

    as a small example of the first case, there are special device control registers on some
    models of the power pc. these are essential for IO but require special instructions to access
    them (even though the same devices often have memory-mapped IO space
    as well). worse, the register (device) address is part of the instruction,
    not an operand. (it's the same fault as the old SPARC's mmu control instructions.)
    only recently has an instruction been added that allows the device register number
    to be taken from a general-purpose register, but that seems mainly to have been
    added because they'd run out of address space in the instruction.
    stunning (in every sense). i pick on that one because the DCRs were ADDED relatively late
    in the powerpc history. perhaps it was just a form of mid-life crisis.

  7. Re: [9fans] speaking of kenc

    On Fri May 4 05:24:03 EDT 2007, forsyth@vitanuova.com wrote:
    > having to code anything in assembler is a significant sign of failure:
    > if it's on a general-puprose processor, we have failed to educate processor designers;
    > if it's on (say) a DSP, it's a bit of a mixture of that and people thinking that
    > language design stopped with C, so the language provides too little scope for a compiler sensibly to do the work.


    i agree. however, i think there are some exceptions. some
    (often 8 bit) architectures are better suited to assembly.
    i wrote a hc08 disassembler/ simulator earlier this year. it's
    got 256 bytes of ram and one general purpose register.
    c's overhead would eat into that 256 bytes quite quickly.

    before you dismiss it as a silly, old design, note that it is a
    usb-enabled soc and costs less than two bucks. and in
    motorola tradition, all io is mmio.

    also there are some things that are just difficult to do in c.
    c has no notion of cache-coherence. so one needs to reach
    outside the language to do something like [RWM]FENCE
    on out-of-order processors.

    are there any languages that deal with this?

    - erik

  8. Re: [9fans] speaking of kenc

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    On May 4, 2007, at 2:24 AM, C H Forsyth wrote:
    > if it's on (say) a DSP, it's a bit of a mixture of that and people
    > thinking that
    > language design stopped with C, so the language provides too little
    > scope for a compiler sensibly to do the work.


    This is the one that worries me most. Looking at the SPUs on Cell,
    kencc won't let me make decent code for them: the vast space of
    vector instructions requires extensive language extensions to use
    well. The overhead of a function call defeats the careful
    interleaving of those instructions. The Cell architecture
    specification includes considerable language extensions to handle
    this, but it's all implemented in a big GCC module. Ick.

    I write a lot of SPU code in my day job, and although C++'s class
    mechanisms are useless, the vector extensions are incredibly useful,
    and when combined with the C++ template mechanism (Yikes!) generates
    very good code. What this tells me is that C and C++ aren't good
    languages for SPU coding, and I should be thinking of something more
    clever that will make our tasks easier, but getting code done has
    trumped language work.

    This will be increasingly on my mind as my cell port comes online and
    I come to wanting my SPUs to work.

    > stunning (in every sense). i pick on that one because the DCRs
    > were ADDED relatively late
    > in the powerpc history. perhaps it was just a form of mid-life
    > crisis.


    FWIW, the DCRs are gone from Cell.

    Paul

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.3 (Darwin)

    iD8DBQFGO10jpJeHo/Fbu1wRAr9qAKDClCJTLbq/Ti0P1+YzyqBJIv7M8gCfRLdK
    JZw4qdBKIx7LzoVSHFdb2dw=
    =ey27
    -----END PGP SIGNATURE-----

  9. Re: [9fans] speaking of kenc

    > Looking at the SPUs on Cell, kencc won't let me make decent
    > code for them: the vast space of vector instructions requires
    > extensive language extensions to use well. The overhead of a
    > function call defeats the careful interleaving of those
    > instructions.


    I've probably read just enough about this architecture to
    make a fool of myself, but it's Friday afternoon, so here
    goes nothing.

    One possible goal might be a language in which you could
    describe high-level algorithms of a certain class which
    could then be compiled to run well on a Cell (and, to be
    a cool result, on some other thing). This would probably
    handle not just computation but also the necessary DMA
    to get the data ready. As you point out, that language
    probably wouldn't be C, and it may well be the case that
    it doesn't exist yet.

    Failing that, it seems like what people will be doing for
    a while is writing code carefully tuned to run well on
    exactly one or two particular models of Cell, which seems
    to me likely to look like carefully optimized "inner loop"
    stuff wrapped by glue code which matters less. I have to
    wonder whether it would be less painful to learn the hardware
    and write the optimized code in assembly language or to learn
    the hardware *and* learn how to cajole a complicated compiler
    into emitting the assembly language you know it should be
    emitting.

    With respect to kencc, I wonder how far you could get if
    each Cell vector instruction were a C-callable .s function
    of a few instructions and the SPU linker routinely inlined
    all small-instruction-count functions and had an optimizer
    explicitly designed for the SPU.

    Dave Eckhardt

  10. Re: [9fans] speaking of kenc

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    On May 4, 2007, at 2:58 PM, Dave Eckhardt wrote:
    > One possible goal might be a language in which you could
    > describe high-level algorithms of a certain class which
    > could then be compiled to run well on a Cell (and, to be
    > a cool result, on some other thing). This would probably
    > handle not just computation but also the necessary DMA
    > to get the data ready.


    FWIW, the C++ template goop that I use in my SPU code is all about
    masking the data movements - you don't want virtual-function call
    overhead in cache-lookup functions, nor do you want a different
    version of the code for each data type you want to transfer. There
    is a relatively limited number of buffer usage patterns. In
    approximate best to worst performance order these are double-buffered
    input and output, block-random access, struct-sized random access,
    and general pointer-chasing. I can easily wrap a small language
    around these operations (and have in the past - it's just more
    convenient right now to let GCC maintain it for me).

    > Failing that, it seems like what people will be doing for
    > a while is writing code carefully tuned to run well on
    > exactly one or two particular models of Cell, which seems
    > to me likely to look like carefully optimized "inner loop"
    > stuff wrapped by glue code which matters less.


    Only partly true; the SPU architecture defines the latencies and
    stalls of the various instructions fairly well. Given my experience
    optimizing SPU code, the 40:1 to 100:1 improvements from data
    restructuring and selective SIMD conversions are worth doing, while
    the per-cycle stall management isn't - there might be another factor
    of 2, or there might not - it's a difficult space for a small reward.

    > I have to
    > wonder whether it would be less painful to learn the hardware
    > and write the optimized code in assembly language or to learn
    > the hardware *and* learn how to cajole a complicated compiler
    > into emitting the assembly language you know it should be
    > emitting.


    Doing the streaming/caching/DMA code in assembly is a non-starter.
    It's just that increment of too complicated. And fortunately, IBM
    went and defined the C language extensions as part of the SPU
    architecture, which means it's not too hard to learn to use. The
    restrict keyword does gall me though.

    > With respect to kencc, I wonder how far you could get if
    > each Cell vector instruction were a C-callable .s function
    > of a few instructions and the SPU linker routinely inlined
    > all small-instruction-count functions and had an optimizer
    > explicitly designed for the SPU.


    I think this could work quite well; I'm not sure how this interferes
    with register allocation though. I'll give it some thought. The
    harder part will be the data movement operations from my first
    paragraph.

    Paul

    >
    > Dave Eckhardt


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.3 (Darwin)

    iD8DBQFGO7M1pJeHo/Fbu1wRAmFvAKDUlDdofVlXv30Lcf3xYPHN6ubX4QCfclYB
    te5F+PL5KW2BiF+CvXzyuDQ=
    =HTyI
    -----END PGP SIGNATURE-----

  11. Re: [9fans] speaking of kenc

    On Fri, 2007-05-04 at 08:46 +0000, Douglas A. Gwyn wrote:
    > "Roman Shaposhnick" wrote in message
    > news:1178243111.16650.1826.camel@work.sfbay.sun.co m...
    > > P.S. Here at Sun I've been putting some of the GCC extensions
    > > into Sun Studio, ...

    >
    > Here's hoping you require a command-line flag to enable them.


    Of course!

    > As someone else noted, one way to check for many instances of
    > GCC-dependency in a mass of source code is to use a compiler
    > that *doesn't* support for the myriad GCC features. Some of
    > the current Linux programmers have no idea when they have
    > used GCC-specific features (usually quite unnecessarily).


    True.

    Thanks,
    Roman.


  12. Re: [9fans] speaking of kenc

    On Fri, 2007-05-04 at 16:53 +1000, Bruce Ellis wrote:
    > isn't it bleeding obvious by now that asm is dumb.


    I don't think it is obvious, no.

    > a function call into something in a *.s file will do.


    You're not seriously making this statement, are you?

    > you'll find a few entry points in your fave l.s.
    >
    > can i say dumb-asm on this list?
    >
    > i saw an attempt of ill-informed cleverness where spl() etc
    > were picked up by the compiler and inlined.
    >
    > i guess he had nothing else to do with his life.
    >
    > maybe a 0.02% speedup.


    Using asm has nothing to do with hand optimzing the inner
    loops these days. Most use of asm I see happens when C as a language
    just doesn't have adequate semantics to map into underlying
    hardware capabilities.

    Thanks,
    Roman.


  13. Re: [9fans] speaking of kenc

    On Thu, 2007-05-03 at 19:35 -0700, Lyndon Nerenberg wrote:
    > >> That's called as(1).

    > >
    > > On any architecture with a non-trivial register allocation, the above
    > > statement does not apply.
    > > As far as performance goes you might be better off not using assembler
    > > to begin with.

    >
    > Exactly. If you want asm, you know where to find it. These days, the
    > cases where raw assembler really matters are significant enough that a few
    > in-lines generally don't accomplish anything.


    I partially agree with you, but anything in hardware that isn't
    directly represented by C semantics is a fair game for using
    __asm's. In fact, it is the only way to make your software look
    good on a particular platform. I don't know how to fix that with
    C and it seems that the rest of the posters on this thread don't
    really know either. But this is a problem.

    > > Compilers (at least the ones I work on) are quite smart
    > > in how they use precious resource such as registers, and unless you
    > > can hide everything away on the other side of the 'call' op you'd
    > > be in trouble mixing your code with what compiler had generated for
    > > you.

    >
    > Sure, the compiler can assist with register allocation, but so can reading
    > the ABI documentation.


    The problem is not register allocation per se, but how it ties into
    instructions scheduling, piplining and all that jazz. And no, you can't
    beat a smart compiler on architectures as complex as AMD64 and EM64T.

    Thanks,
    Roman.


  14. Re: [9fans] speaking of kenc

    i meant it.

    asm is gone, or should have been many years ago.

    explain a simple case when you need it.

    brucee

    On 5/5/07, Roman Shaposhnick wrote:
    > On Thu, 2007-05-03 at 19:35 -0700, Lyndon Nerenberg wrote:
    > > >> That's called as(1).
    > > >
    > > > On any architecture with a non-trivial register allocation, the above
    > > > statement does not apply.
    > > > As far as performance goes you might be better off not using assembler
    > > > to begin with.

    > >
    > > Exactly. If you want asm, you know where to find it. These days, the
    > > cases where raw assembler really matters are significant enough that a few
    > > in-lines generally don't accomplish anything.

    >
    > I partially agree with you, but anything in hardware that isn't
    > directly represented by C semantics is a fair game for using
    > __asm's. In fact, it is the only way to make your software look
    > good on a particular platform. I don't know how to fix that with
    > C and it seems that the rest of the posters on this thread don't
    > really know either. But this is a problem.
    >
    > > > Compilers (at least the ones I work on) are quite smart
    > > > in how they use precious resource such as registers, and unless you
    > > > can hide everything away on the other side of the 'call' op you'd
    > > > be in trouble mixing your code with what compiler had generated for
    > > > you.

    > >
    > > Sure, the compiler can assist with register allocation, but so can reading
    > > the ABI documentation.

    >
    > The problem is not register allocation per se, but how it ties into
    > instructions scheduling, piplining and all that jazz. And no, you can't
    > beat a smart compiler on architectures as complex as AMD64 and EM64T.
    >
    > Thanks,
    > Roman.
    >
    >


  15. Re: [9fans] speaking of kenc

    > I partially agree with you, but anything in hardware that isn't
    > directly represented by C semantics is a fair game for using
    > __asm's. In fact, it is the only way to make your software look
    > good on a particular platform. I don't know how to fix that with
    > C and it seems that the rest of the posters on this thread don't
    > really know either. But this is a problem.


    Well, of course it's a contradiction (dilemma, I suppose), so, no, you
    can't fix it.

    But one could define a machine-independent mechanism to implement
    machine-dependent extensions to the C language and to a large degree
    that is what inline assembly as well as .s files are all about. I
    imagine that brucee and forsyth, with their intimate knowledge of the
    Plan 9 C development system could easily provide such tools as inlining.

    My limited understanding suggests that the optimisations you refer to:

    > The problem is not register allocation per se, but how it ties into
    > instructions scheduling, piplining and all that jazz. And no, you can't
    > beat a smart compiler on architectures as complex as AMD64 and EM64T.


    are best done by 8l or equivalent, specially when it comes to inlining
    functions in a previously separate source file. But I'm no expert, I
    imagine that the compiler might need to supply a little more detail to
    assist.

    I would like to see such issues addressed, however, as the Plan 9
    development environment seems more robust in this area than the
    unmanageable monstrosity that is GCC. It's really a pity that on this
    list the only people with the spare cycles to deal with this issues
    are those who feel a need to prove that Plan 9 can be as good as, say,
    Linux, to the competing camp instead of concentrating on evolving Plan
    9's own strengths.

    The comparison with dinosaurs and small, furry mammals keeps coming to
    mind: little did the furry ones know that conditions would eventually
    change to favour their fur against the dinosaur's scales, but they
    didn't evolve towards scales and size just because it was the fashion
    of the day.

    ++L


  16. Re: [9fans] speaking of kenc

    On Sat May 5 01:14:24 EDT 2007, bruce.ellis@gmail.com wrote:
    > i meant it.
    >
    > asm is gone, or should have been many years ago.
    >
    > explain a simple case when you need it.
    >
    > brucee


    i'll bite. i think there are at least three places assembler
    is useful and likely required today.

    1. in space-restricted environments like the mbr or pbs.

    2. to deal with stuff outside the scope of higher-level
    languages. for example, [rwm]fence, ia msrs. test-and-set.

    3. small embedded systems.

    - erik

  17. Re: [9fans] speaking of kenc

    > 1. in space-restricted environments like the mbr or pbs.
    >
    > 2. to deal with stuff outside the scope of higher-level
    > languages. for example, [rwm]fence, ia msrs. test-and-set.
    >
    > 3. small embedded systems.


    1 and 3 are not really that different, so you're down to two examples.
    C is OK for newer embedded systems (microcontrollers), older ones are
    what they are and ASM may well be the way to go. But even there, ASM
    is often just the lazy way rather than the more economical way.

    I have a feeling brucee will point out that the gain in efficiency in
    using ASM is insufficient to justify the additional costs in
    complexity and error potential. There certainly are tasks that cannot
    be done in C, like test-and-set and, say, context switches, but such
    specialised tasks should either live in a C-callable library or ought
    to be added to the optimisation pass(es) in a C compiler, rather than
    encourage programmers to drop into assembler at the drop of a hat,
    often merely for the benefit of re-inventing a common operation.

    That said, lack of the ability to "inline" functions may be perceived
    as a drawback of the Plan 9 C compiler. As I mentioned elsewhere, the
    loader may well be the place where "inline" could be put to best use.

    ++L


  18. Re: [9fans] speaking of kenc

    thank you for replying for me. you know my mindset well.
    i'm not enthused by inline either. things were different
    when function calls were expensive but inlines just blow
    your cache for little benefit and incite incivility, bloating binaries.

    perkin-elmer (remember them?) once released a fortran
    compiler that inlined eveything (before fortran had recursion).
    this was very impressive for some benchmarks but for any
    real program you ended up with real fat-ass binaries - they
    added paging of page tables to cope. what a great product.

    brucee

    On 5/6/07, lucio@proxima.alt.za wrote:
    > > 1. in space-restricted environments like the mbr or pbs.
    > >
    > > 2. to deal with stuff outside the scope of higher-level
    > > languages. for example, [rwm]fence, ia msrs. test-and-set.
    > >
    > > 3. small embedded systems.

    >
    > 1 and 3 are not really that different, so you're down to two examples.
    > C is OK for newer embedded systems (microcontrollers), older ones are
    > what they are and ASM may well be the way to go. But even there, ASM
    > is often just the lazy way rather than the more economical way.
    >
    > I have a feeling brucee will point out that the gain in efficiency in
    > using ASM is insufficient to justify the additional costs in
    > complexity and error potential. There certainly are tasks that cannot
    > be done in C, like test-and-set and, say, context switches, but such
    > specialised tasks should either live in a C-callable library or ought
    > to be added to the optimisation pass(es) in a C compiler, rather than
    > encourage programmers to drop into assembler at the drop of a hat,
    > often merely for the benefit of re-inventing a common operation.
    >
    > That said, lack of the ability to "inline" functions may be perceived
    > as a drawback of the Plan 9 C compiler. As I mentioned elsewhere, the
    > loader may well be the place where "inline" could be put to best use.
    >
    > ++L
    >
    >


  19. Re: [9fans] speaking of kenc

    On 5/5/07, Bruce Ellis wrote:
    > i meant it.
    >
    > asm is gone, or should have been many years ago.
    >
    > explain a simple case when you need it.
    >


    seriously?

    compiling c code. can you imagine a c compiler that does not translate
    to asm first? or can you imagine porting a c compiler when you dont
    have an assembler? do you want to be hand coding machine code in a
    compiler's code generator? i think assembler is a good compromise. its
    good for compiler writers.

    or would you rather have the processor and hardware designers build in
    the language support in the hardware? how would you react if the
    hardware designers choice of language is different from yours?

  20. Re: [9fans] speaking of kenc

    On 5/6/07, Bruce Ellis wrote:
    > thank you for replying for me. you know my mindset well.
    > i'm not enthused by inline either. things were different
    > when function calls were expensive but inlines just blow
    > your cache for little benefit and incite incivility, bloating binaries.
    >
    > perkin-elmer (remember them?) once released a fortran
    > compiler that inlined eveything (before fortran had recursion).
    > this was very impressive for some benchmarks but for any
    > real program you ended up with real fat-ass binaries - they
    > added paging of page tables to cope. what a great product.
    >


    inlining functions is necessary for parallelizing or scheduling
    optimizations. specially whole program optimizations. i prefer static
    linked binaries precisely because of this.

+ Reply to Thread
Page 4 of 7 FirstFirst ... 2 3 4 5 6 ... LastLast