[9fans] speaking of kenc - Plan9

This is a discussion on [9fans] speaking of kenc - Plan9 ; Rogelio Serrano wrote: > 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? > ...

+ Reply to Thread
Page 5 of 7 FirstFirst ... 3 4 5 6 7 LastLast
Results 81 to 100 of 121

Thread: [9fans] speaking of kenc

  1. Re: [9fans] speaking of kenc

    Rogelio Serrano wrote:
    > 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?


    All those have been done, and more than a few times.
    But it doesn't make any of 'em 'optimal'. Nor easy.

    > i think assembler is a good compromise. its
    > good for compiler writers.
    >


    Cheaper and faster to create or update a few symbols for new silicon & added
    features in asm than elsewhere.

    > 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?
    >


    That very thing was done with at least two fairly 'high level' (or high-level
    capable) languages.. forth and pascal. There have been others.

    The world did not exactly beat a commercial path to the door of any of these.
    Too specialized, too limited in application. Too slow.

    As an alternative to diode plug boards, wire-wrap tools, and solder, asm is the
    most flexible yet of compromises, so not likely to go away until the 'puter
    becomes self-aware and self-replicating.

    Not necessarily a day to look forward to, that one...

    '...you can *negotiate* with a terrorist..'

    :-(

    Bill




  2. Re: [9fans] speaking of kenc

    > 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.


    perhaps you haven't programmed many microcontrollers. usually the
    volumes are high and the per unit cost is very important so you end up
    with very simple parts with very little ram/flash. the one i worked on
    earlier this year had low speed usb interface, 2 gp registers, 256 bytes of ram
    and 4k of flash.

    i found it easy enough to program in assembly, but i don't think you'd
    get very far with c. i just don't think you could fit things into memory.

    > 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.


    i don't understand the assumption that the only reason to use assembly is
    cycle efficiency.

    also, could you explain why this is "lazy"? or why assembly is more
    complicated?

    clearly, an assembly is more difficult to wield than c. but you don't
    use them for the same thing.

    this absolutist argument that c is teh bomb. asm suks is silly. it's like
    arguing bicycles and ferraris. which one you need (and which one gets
    you there faster) depends on what you're doing.

    - erik

  3. Re: [9fans] speaking of kenc

    On Sat May 5 21:13:56 EDT 2007, rogelio.serrano@gmail.com wrote:
    > compiling c code. can you imagine a c compiler that does not translate
    > to asm first?


    like ken's c compiler?

    - erik

  4. Re: [9fans] speaking of kenc

    erik quanstrom wrote:
    >> 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.

    >
    > perhaps you haven't programmed many microcontrollers. usually the
    > volumes are high and the per unit cost is very important so you end up
    > with very simple parts with very little ram/flash. the one i worked on
    > earlier this year had low speed usb interface, 2 gp registers, 256 bytes of ram
    > and 4k of flash.
    >
    > i found it easy enough to program in assembly, but i don't think you'd
    > get very far with c. i just don't think you could fit things into memory.


    Well 'C compiler hosted on a larger machine, and with that one as a binary
    target' will no doubt come back from someone. And that isn't wrong.

    But unless it has to be done over and over in may ways, such a setup can take
    longer to set up, test, and option for a given run than to JFDI the app in
    machine code.

    Less than 5K bytes total fits on a page or two of A4 in hex, or one modern LCD
    display.

    How 'lost' can you get in a teacup?

    And how many op codes will you actually need to use from what must be a rather
    small set anyway?

    Bill


    >
    >> 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.

    >
    > i don't understand the assumption that the only reason to use assembly is
    > cycle efficiency.


    Actually it often has *less* of that efficiency than a highly optimizing 'C' (or
    'D') compiler. Especially if the coder is not well and truly au fait with a
    specific CISC machine's op codes, architecture, cycle 'cost'.

    >
    > also, could you explain why this is "lazy"? or why assembly is more
    > complicated?
    >


    "Tedious" might be more accurate than "complicated".

    ;-)

    > clearly, an assembly is more difficult to wield than c. but you don't
    > use them for the same thing.
    >


    Some of us try hard not to use either of them at all....

    > this absolutist argument that c is teh bomb. asm suks is silly. it's like
    > arguing bicycles and ferraris. which one you need (and which one gets
    > you there faster) depends on what you're doing.
    >
    > - erik
    >


    ACK. Hong Kongs 100+ year-old tram system beats the modern underground on cost,
    the undergrond beats a taxi on speed at rush hour, but not otherwise, buses have
    a wider route choice than either, and the taxi *always* rules on assuredly
    getting a place to sit down. IF you can get the taxi in the first place - which
    is NOT assured.

    'puters are not so different.

    Glad to have choices, and we can never stop making them without giving up
    *something* of value.

    Bill

  5. Re: [9fans] speaking of kenc

    On 5/6/07, erik quanstrom wrote:
    > On Sat May 5 21:13:56 EDT 2007, rogelio.serrano@gmail.com wrote:
    > > compiling c code. can you imagine a c compiler that does not translate
    > > to asm first?

    >
    > like ken's c compiler?
    >
    > - erik
    >


    really? i though it had an "internal" assembler.

    i certainly would create an assembler first. even for testing purposes
    only. i remember debugging a pl/0 compiler in compiler class and it is
    really mind numbingly hard to work with pentium machine code directly.

    can we write plan 9 without using assembler? maybe for some archs. but not x86.

    of course if i am creating my own processor i would make sure i dont
    need to use assembly at all. but then other programmers would want
    their favorite language to be supported as well and they will likely
    end up creating their own processor. not a good situation.

    --
    the thing i like with my linux pc is that i can sum up my complaints in 5 items

  6. Re: [9fans] speaking of kenc

    On 5/6/07, erik quanstrom wrote:

    >
    > this absolutist argument that c is teh bomb. asm suks is silly. it's like
    > arguing bicycles and ferraris. which one you need (and which one gets
    > you there faster) depends on what you're doing.
    >


    exactly.

    assembler is there because it is needed. if you are writing or porting
    a compiler and you dont have an assembler you will end up writing one
    anyway.

  7. Re: [9fans] speaking of kenc

    On 5/6/07, Rogelio Serrano wrote:
    > On 5/6/07, erik quanstrom wrote:
    >
    > >
    > > this absolutist argument that c is teh bomb. asm suks is silly. it's like
    > > arguing bicycles and ferraris. which one you need (and which one gets
    > > you there faster) depends on what you're doing.
    > >

    >
    > exactly.
    >
    > assembler is there because it is needed. if you are writing or porting
    > a compiler and you dont have an assembler you will end up writing one
    > anyway.
    >


    besides, its so easy to write one.
    provided you have the instruction set manuals.

    --
    the thing i like with my linux pc is that i can sum up my complaints in 5 items

  8. Re: [9fans] speaking of kenc

    erik quanstrom wrote:
    >> 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.

    >
    > perhaps you haven't programmed many microcontrollers. usually the
    > volumes are high and the per unit cost is very important so you end up
    > with very simple parts with very little ram/flash. the one i worked on
    > earlier this year had low speed usb interface, 2 gp registers, 256 bytes of ram
    > and 4k of flash.
    >
    > i found it easy enough to program in assembly, but i don't think you'd
    > get very far with c. i just don't think you could fit things into memory.


    Well 'C compiler hosted on a larger machine, and with that one as a binary
    target' will no doubt come back from someone. And that isn't wrong.

    But unless it has to be done over and over in may ways, such a setup can take
    longer to set up, test, and option for a given run than to JFDI the app in
    machine code.

    Less than 5K bytes total fits on a page or two of A4 in hex, or one modern LCD
    display.

    How 'lost' can you get in a teacup?

    And how many op codes will you actually need to use from what must be a rather
    small set anyway?

    Bill


    >
    >> 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.

    >
    > i don't understand the assumption that the only reason to use assembly is
    > cycle efficiency.


    Actually it often has *less* of that efficiency than a highly optimizing 'C' (or
    'D') compiler. Especially if the coder is not well and truly au fait with a
    specific CISC machine's op codes, architecture, cycle 'cost'.

    >
    > also, could you explain why this is "lazy"? or why assembly is more
    > complicated?
    >


    "Tedious" might be more accurate than "complicated".

    ;-)

    > clearly, an assembly is more difficult to wield than c. but you don't
    > use them for the same thing.
    >


    Some of us try hard not to use either of them at all....

    > this absolutist argument that c is teh bomb. asm suks is silly. it's like
    > arguing bicycles and ferraris. which one you need (and which one gets
    > you there faster) depends on what you're doing.
    >
    > - erik
    >


    ACK. Hong Kongs 100+ year-old tram system beats the modern underground on cost,
    the undergrond beats a taxi on speed at rush hour, but not otherwise, buses have
    a wider route choice than either, and the taxi *always* rules on assuredly
    getting a place to sit down. IF you can get the taxi in the first place - which
    is NOT assured.

    'puters are not so different.

    Glad to have choices, and we can never stop making them without giving up
    *something* of value.

    Bill


  9. Re: [9fans] speaking of kenc

    Rogelio Serrano wrote:
    > On 5/6/07, erik quanstrom wrote:
    >
    >>
    >> this absolutist argument that c is teh bomb. asm suks is silly. it's
    >> like
    >> arguing bicycles and ferraris. which one you need (and which one gets
    >> you there faster) depends on what you're doing.
    >>

    >
    > exactly.
    >
    > assembler is there because it is needed. if you are writing or porting
    > a compiler and you dont have an assembler you will end up writing one
    > anyway.
    >

    ... OR machine-coding the 'primitives' for your own virtual-machine to obviate
    the need for having to worry about it at all.

    Forth directly on hardware 'then'.

    Inferno and limbo on underlying whatever-OS-is-available 'now'.

    That cycle of choice and alternatives continues also, and these are by no means
    alone.

    Nature of mankind, if not of our inventions...

    Apreciating, seeking, even creating 'choice', I mean.

    That's why the kids don't all look alike...

    ;-)


    (sorry, all - about that last post being dup'ed, BTW - fat fingers)

    Bill



  10. Re: [9fans] speaking of kenc

    yes i don't need imagination. all plan9 C compilers do NOT
    translate to asm. check it it out and learn something.

    ken is cleverer than that path.

    brucee

    On 5/6/07, Rogelio Serrano wrote:
    > 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?


  11. Re: [9fans] speaking of kenc

    > assembler is there because it is needed. if you are writing or porting
    > a compiler and you dont have an assembler you will end up writing one
    > anyway.


    Assembler is there because the designers _make_ it necessary. The
    transputer had no assembly. The fact that it is no longer in common
    use (are TI still using it in graphic engines?) does not detract from
    its value. Popular/successful is not the same as "good".

    ++L


  12. Re: [9fans] speaking of kenc

    > besides, its so easy to write one.
    > provided you have the instruction set manuals.


    Oh, yeah? For the Intel x86 series? Across all its instruction sets,
    emulation modes and addressing modes? How long do you think it will
    take you? And what language would you write in? On what platform?

    ++L


  13. Re: [9fans] speaking of kenc

    >> 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.

    >
    > perhaps you haven't programmed many microcontrollers. usually the
    > volumes are high and the per unit cost is very important so you end up
    > with very simple parts with very little ram/flash. the one i worked on
    > earlier this year had low speed usb interface, 2 gp registers, 256 bytes of ram
    > and 4k of flash.
    >

    Well, I look at the AVR and all I see is a form of "bloat" I could
    have sold my mother-in-law (had I had one) for a few years back. It
    may not be the paragon of design forsyth would beg for, but it sure is
    cheap and vast. How much more it would cost than what you chose
    instead is difficult to determine. To me, it seems PIC users are the
    masochists.

    > i found it easy enough to program in assembly, but i don't think you'd
    > get very far with c. i just don't think you could fit things into memory.
    >

    Oh, well, I recall a C compiler for the 8051... Are you sure you
    could drive a USB port in assembler? It sounds ridiculously difficult
    in C, to my mind. And, for the record, I do enjoy the challenge of
    tight assembler coding, but more like I enjoy running a middle
    distance than as a means to an end.

    >> 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.

    >
    > i don't understand the assumption that the only reason to use assembly is
    > cycle efficiency.
    >
    > also, could you explain why this is "lazy"? or why assembly is more
    > complicated?
    >

    Because it's very thin. You have thousands of instructions to keep
    track of, some of which are not exactly the ones you ought to have
    used. Because inverting a test is sometimes not as obvious as you
    think (not everyone knows the instruction set backwards) and, most
    importantly, because all the "clever" optimisations you added are
    utterly incomprehensible to the poor sod that comes along to debug or
    alter your code. I was tought a long time ago that the most important
    feature of good programming is readability and assembler certainly has
    none of that built into it.

    > clearly, an assembly is more difficult to wield than c. but you don't
    > use them for the same thing.
    >

    Well, many would disagree. It has been stated with good cause that C
    is a portable assembly language. If you believe as I do that Unix's
    great step forward was coding the kernel in C almost entirely (I
    learnt assembler on the Univac 1100 series, the OS was entirely
    written in assembler and so were the few compilers it came with), then
    the role assembly plays is bound to be restricted to the few features
    that cannot be expressed directly in C.

    > this absolutist argument that c is teh bomb. asm suks is silly. it's like
    > arguing bicycles and ferraris. which one you need (and which one gets
    > you there faster) depends on what you're doing.
    >

    Nah, you read us all wrong. Assembler is what the engineers chose for
    us to use. I found the Intel x86 assembler totally frustrating
    because I had cut my teeth on the Univac. I eventually became
    familiar with it (thank you IBM for publishing the BIOS code for the
    PX/XT), but there's no way I could have or would have followed Intel
    into the i386 and later instructions set. I do know that what Plan 9
    does in splitting the compiler and loader differently from the
    "obvious" boundary of C code and assembly code is very sensible and
    far better suited to a programmer. Certainly, the loader now needs to
    contain a lot of savvy about the target architecture (curse those
    engineers once again!), but it's a specialised location for it and
    only a few boffins need to get involved in it.

    What we are all talking across each other about is that our benchmarks
    have grown bloated, specially software in common use. GCC leading the
    pack, we have enormous "packages" to perform tasks that would be
    better done with a handful of minute tools instead. But the obsession
    with combining and controlling everything within one place is blinding
    us to the fact that we are creating complexity purely out of habit.
    That's the "lazy" I mentioned earlier, it is easier to do it with that
    tiny, sharp scalpel, than to sharpen the chisel first that would save
    you effort in innumerable future operations. When the scalpel is an
    existing assembler and the chisel is GCC, I sympathise entirely, but
    that does not make assembly code superior to C.

    Etc. I could go on and perhaps I ought to, but it's too easy for me
    to get lost in a topic.

    ++L


  14. Re: [9fans] speaking of kenc

    it would really disapoint me if someone tried to implemnent
    asm in kenc. call it unkenc. can you imagine something
    as dumb as gcc asm thrown in there or something even simpler.

    gee, no need for asms in /sys/src ... just a small (very) of
    assembler in each library. kick me.

    brucee

    On 5/6/07, lucio@proxima.alt.za wrote:
    > > besides, its so easy to write one.
    > > provided you have the instruction set manuals.

    >
    > Oh, yeah? For the Intel x86 series? Across all its instruction sets,
    > emulation modes and addressing modes? How long do you think it will
    > take you? And what language would you write in? On what platform?
    >
    > ++L
    >
    >


  15. Re: [9fans] speaking of kenc

    >> i found it easy enough to program in assembly, but i don't think you'd
    >> get very far with c. i just don't think you could fit things into memory.

    >
    > Well 'C compiler hosted on a larger machine, and with that one as a binary
    > target' will no doubt come back from someone. And that isn't wrong.


    This makes as much sense now as it did in the 1950s. The assembler
    was then just a mnemonic translator and that is just about what Erik
    must have been doing. With greater familiarity, you can probably code
    the damn thing in binary.

    But is that where we're all going?

    The point Brucee made and I tried to corroborate is that a good C
    compiler, not GCC, nor ANSI's C99 with their need to please more the
    designers than the audience, could provide most, if not all the
    optimisations one actually needs without making the language a burden
    to learn. And without slipping into low-level programming.

    In my long experience as a programming language hobbyist, I have yet
    to encounter a programming language more suited to this particular
    environment. It bothers me that the trend is away from here, towards
    extending the C language, where other languages may be better suited
    to the newer, larger, more complex applications.

    In other words, C covers a wide enough scope, from near as damn the
    bare-bone machine to sizeable applications. Once you exceed a certain
    level, it makes more sense to look elsewhere. I wonder if the GCC
    developers have evne considered redeveloping GCC in a language other
    than C?

    ++L

    PS: Doug Gwyn may well claim that the ANSI committee is trying to
    standardise best common practices, but I have a feeling that the
    committee is unqualified to do this because they represent the wrong
    interests, as I said above, not the users, but the feature designers.


  16. Re: [9fans] speaking of kenc

    i think this has gone off track. i read brucee's original post as an
    argument against polluting c with asm()/__asm{}. obviously there is
    asm in the plan9 distro; try du -a /sys/src| grep '\.s$' . for which
    it uses /sys/doc/asm.ps

    alas, in a world where "a computer" is windows on a x86, you can use
    assembler for everything and not worry about portability. every cycle
    you save is one more for vista. knock yourselves out:
    http://en.wikipedia.org/wiki/RosAsm

    for microcontrollers, there are choices like forth.

    > On 5/6/07, Rogelio Serrano wrote:
    >> On 5/6/07, erik quanstrom wrote:
    >>
    >> >
    >> > this absolutist argument that c is teh bomb. asm suks is silly. it's like
    >> > arguing bicycles and ferraris. which one you need (and which one gets
    >> > you there faster) depends on what you're doing.
    >> >

    >>
    >> exactly.
    >>
    >> assembler is there because it is needed. if you are writing or porting
    >> a compiler and you dont have an assembler you will end up writing one
    >> anyway.
    >>

    >
    > besides, its so easy to write one.
    > provided you have the instruction set manuals.
    >
    > --
    > the thing i like with my linux pc is that i can sum up my complaints in 5 items



  17. Re: [9fans] speaking of kenc

    On 5/6/07, lucio@proxima.alt.za wrote:
    > >> i found it easy enough to program in assembly, but i don't think you'd
    > >> get very far with c. i just don't think you could fit things into memory.

    > >
    > > Well 'C compiler hosted on a larger machine, and with that one as a binary
    > > target' will no doubt come back from someone. And that isn't wrong.

    >


    cross compilation is more important than ever.

    > This makes as much sense now as it did in the 1950s. The assembler
    > was then just a mnemonic translator and that is just about what Erik
    > must have been doing. With greater familiarity, you can probably code
    > the damn thing in binary.
    >
    > But is that where we're all going?
    >


    i dont think we want to regress.

    > The point Brucee made and I tried to corroborate is that a good C
    > compiler, not GCC, nor ANSI's C99 with their need to please more the
    > designers than the audience, could provide most, if not all the
    > optimisations one actually needs without making the language a burden
    > to learn. And without slipping into low-level programming.
    >


    i agree up to a point.

    > In my long experience as a programming language hobbyist, I have yet
    > to encounter a programming language more suited to this particular
    > environment. It bothers me that the trend is away from here, towards
    > extending the C language, where other languages may be better suited
    > to the newer, larger, more complex applications.
    >


    i agree.

    > In other words, C covers a wide enough scope, from near as damn the
    > bare-bone machine to sizeable applications. Once you exceed a certain
    > level, it makes more sense to look elsewhere. I wonder if the GCC
    > developers have evne considered redeveloping GCC in a language other
    > than C?
    >


    some people actually wanted to write gcc in c++. God forbid. i dont
    want to be writing system routines with STL. the gcc steering
    committee have a majority of c++ programmers and they resisted it.

  18. Re: [9fans] speaking of kenc

    lucio@proxima.alt.za wrote:

    *snip*

    > ..... It bothers me that the trend is away from here, towards
    > extending the C language, where other languages may be better suited
    > to the newer, larger, more complex applications.
    >
    > In other words, C covers a wide enough scope, from near as damn the
    > bare-bone machine to sizeable applications. Once you exceed a certain
    > level, it makes more sense to look elsewhere. I wonder if the GCC
    > developers have evne considered redeveloping GCC in a language other
    > than C?
    >
    > ++L
    >
    > PS: Doug Gwyn may well claim that the ANSI committee is trying to
    > standardise best common practices, but I have a feeling that the
    > committee is unqualified to do this because they represent the wrong
    > interests, as I said above, not the users, but the feature designers.
    >
    >


    I personally think 'D' is reachng a level of maturity to take on much of that
    'C' strength in a saner way, and with near-zero 'speed' penalty - the bane of
    most other alternatives.

    A compromise, of course - but a very sensible one, given needs that will not go
    away.

    OTOH, 'D' has not had several decades of 'committees' bending the original
    goals... Not yet anyway..

    Bill

  19. Re: [9fans] speaking of kenc

    Rogelio Serrano wrote:

    *snip*

    >
    > some people actually wanted to write gcc in c++. God forbid. i dont
    > want to be writing system routines with STL. the gcc steering
    > committee have a majority of c++ programmers and


    ^even^

    > they resisted it.


    And well they should!

    C++ is a towering example of what happens when good theoretical intentions with
    too little inertia meet conflicting needs. Java is another.

    We don't need cures that are worse than the disease. If it even *is* a 'disease'.

    By contrast, though I don't expect Ada will ever get much faster, let alone
    'best choice' for all work, it is at least finally delivering enough reduction
    in debugging time to make economic sense to firms with serious needs and serious
    funding. Boeing, for example.

    We need to learn *something* useful from that. And apply it.

    Bill





  20. Re: [9fans] speaking of kenc

    On 5/6/07, lucio@proxima.alt.za wrote:
    > > besides, its so easy to write one.
    > > provided you have the instruction set manuals.

    >
    > Oh, yeah? For the Intel x86 series? Across all its instruction sets,
    > emulation modes and addressing modes? How long do you think it will
    > take you? And what language would you write in? On what platform?
    >
    > ++L
    >
    >


    yes. and is it easier if you build it into the code generator? the
    designers actually dont give you a choice.

    i wrote an assembler as a testing tool for the code generator. in the
    end i just refactored the assembler into the code generator. i just
    coded for a small subset that is needed.

    the root of all this evil is the designer of the processor. can we
    make them change their ways? not until we start designing our own.

    oh right i could just buy a non-x86 non-pc system. like i can find any
    within 1k km where i live.

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