Re: [9fans] speaking of kenc - Plan9

This is a discussion on Re: [9fans] speaking of kenc - Plan9 ; On 5/6/07, lucio@proxima.alt.za wrote: > > You may not have noticed, as it is no longer a popular approach, that > earlier Unixes provided innumerable tools to generate C code. So much > so that the "goto" was retained more ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Re: [9fans] speaking of kenc

  1. Re: [9fans] speaking of kenc

    On 5/6/07, lucio@proxima.alt.za wrote:

    >
    > You may not have noticed, as it is no longer a popular approach, that
    > earlier Unixes provided innumerable tools to generate C code. So much
    > so that the "goto" was retained more to make such code generation
    > easier than to please a handful of spoiled programmers.
    >


    your point?

    > The idea, unless I got things badly wrong by not being aware of that
    > history as it occurred, was that C would be the target language of
    > choice. It is sad that engineers prefer to design at a lower level
    > than that, and that a middle ground is no longer even being sought.
    > Forsyth may be able to tell you a bit about the Transputer and Occam,
    > just to show that history does not have to repeat itself.
    >


    i dont know about the transputer and occam but im aware that some
    systems dont need assembly for writing system software. if only we
    have a choice.

    you want to start tinkering with fpgas?

    actually its not hard to create a processor that is generic enough
    that it does not need assembly and is not locked to any target
    language.

  2. Re: [9fans] speaking of kenc

    > On 5/6/07, lucio@proxima.alt.za wrote:
    >
    >>
    >> You may not have noticed, as it is no longer a popular approach, that
    >> earlier Unixes provided innumerable tools to generate C code. So much
    >> so that the "goto" was retained more to make such code generation
    >> easier than to please a handful of spoiled programmers.
    >>

    >
    > your point?
    >

    That C and not assembler ought to be the target language, no matter
    the application. That assembler is deprecated in favour of C.

    ++L


  3. Re: [9fans] speaking of kenc

    lucio@proxima.alt.za wrote:
    >> On 5/6/07, lucio@proxima.alt.za wrote:
    >>
    >>> You may not have noticed, as it is no longer a popular approach, that
    >>> earlier Unixes provided innumerable tools to generate C code. So much
    >>> so that the "goto" was retained more to make such code generation
    >>> easier than to please a handful of spoiled programmers.
    >>>

    >> your point?
    >>

    > That C and not assembler ought to be the target language, no matter
    > the application. That assembler is deprecated in favour of C.
    >
    > ++L
    >
    >


    If that ever comes to pass, I'm going back to a wire-wrap tool.

    There *can be no* one-size fits-all final answers unless and until all progress
    is to be called off and stagnation and decline to the death are mandated from
    on-high.

    Not even for biologicals with billion+ year history.

    'adapt or die' may have long cycle, but it is an unforgiving one.

    Bill



  4. Re: [9fans] speaking of kenc

    On 5/6/07, W B Hacker wrote:
    > lucio@proxima.alt.za wrote:


    > >>

    > > That C and not assembler ought to be the target language, no matter
    > > the application. That assembler is deprecated in favour of C.
    > >


    and make it harder for the pascal boys? if you hard code the procedure
    calling convention of c then you just wrote off 95 percent of your
    customers.

    c assumes a stack. how do you setup the initial stack? how do you
    setup the other stacks?

    another is the memory allocator. you want to hardcode malloc too? or
    do you hardcode object allocation and garbage collection?

    im talking from the kernel writer point of view. and im most familiar
    with the x86. c assumes there is a system already running. and most
    probably that system is brought up using assembly coded initialization
    code.

    the biggest problem with adding high level language support in a
    processor is that it will more or less be biased to a certain os
    design. it will not be flexible enough for everybody. how would you
    feel if it is biased towards unix? fine grained paging, pid tagged
    user and kernel stacks malloc and free. no garbage collection.

    can anybody show me how the assembly less systems do it?

    > > ++L
    > >
    > >

    >
    > If that ever comes to pass, I'm going back to a wire-wrap tool.


    no kidding! wire wrap is still a nice technology for protoyping! try
    developing a 6 layer backplane pcb.

    >
    > There *can be no* one-size fits-all final answers unless and until all progress
    > is to be called off and stagnation and decline to the death are mandated from
    > on-high.
    >


    of course. thats why we have lowest common denominator economics.

    > Not even for biologicals with billion+ year history.
    >
    > 'adapt or die' may have long cycle, but it is an unforgiving one.
    >
    > Bill
    >
    >
    >


  5. Re: [9fans] speaking of kenc

    Rogelio Serrano wrote:
    > On 5/6/07, W B Hacker wrote:


    *snip*

    >>
    >> If that ever comes to pass, I'm going back to a wire-wrap tool.

    >
    > no kidding! wire wrap is still a nice technology for protoyping! try
    > developing a 6 layer backplane pcb.


    Thanks - I stopped at 8 layers, "Manhattan Geometry" and I haven't even shaken
    hands in nearly 30 years.

    But embedding on-die what used to be separate IC's if not transistors (or, for
    me vacuum tubes - M33 analog & AN/FSQ-7 digital) has reduced the layer count -
    in growth rate as well as absolute terms - and very dramatically so.

    Shouldn't be too far-off that a CPU ships with a few dozen LEDs around the
    package periphery and a mating optical socket instead of half a thousand BGA bumps.

    Can only wish it were also so with libs....

    ;-)

    Bill

  6. Re: [9fans] speaking of kenc

    >> That C and not assembler ought to be the target language, no matter
    >> the application. That assembler is deprecated in favour of C.

    >
    > If that ever comes to pass, I'm going back to a wire-wrap tool.
    >

    I don't see why. I did post the sum-total of assembler coding in the
    Plan 9 source directory, libraries and kernel code excluded. Has that
    sent you back to the wire-wrap tool yet?

    Nobody said that C had to be the highest common denominator, only that
    it should be the lowest, instead of asm.

    > There *can be no* one-size fits-all final answers unless and until all progress
    > is to be called off and stagnation and decline to the death are mandated from
    > on-high.
    >

    That is a view from an uncommon position. It so happens that our
    brain can "evolve" much more rapidly than any other organism, with
    mutations occurring on a very small timescale. But that perspective
    is unique to that particular condition. And one can philosophise on
    how useful this continuous mutation really is.

    > Not even for biologicals with billion+ year history.
    >

    Ever wondered how old the nearest amoeba is? From his point of view,
    we're just a passing phase :-)

    > 'adapt or die' may have long cycle, but it is an unforgiving one.


    As you go higher in evolutionary complexity, this becomes more
    important, but it's an artifact, not a natural principle. It stems
    from organic complexity that is more dependent on active conditions.
    The ability to deal with environmental change without need to mutate
    seems to me to be more powerful than the ability to mutate at the
    slightest whim.

    C is one such paradigm. Consider that early versions of Windows (up
    to 3.1, perhaps) were written in Pascal; at the time that was
    Microsoft's bet for the future. C took over from Pascal and only
    Microsoft can document the pain and gain of moving to it. That C is
    still around today, one dares say _despite_ interference from various
    well-meaning committees, speaks volume to the genius of its inventors.
    I don't think it was blind luck, I think it was genius. That
    something may eventually supersede C is unarguable, but I think it
    will take a very large paradigm shift to make that possible or
    necessary.

    ++L


  7. Re: [9fans] speaking of kenc

    > im talking from the kernel writer point of view. and im most familiar
    > with the x86. c assumes there is a system already running. and most
    > probably that system is brought up using assembly coded initialization
    > code.


    No one said that assembler is obsolete, only deprecated. Like many
    "we have always done it this way" paradigms, it dies hard and it is
    difficult to persuade "aficionados" that they would be better off
    programming at a higher level and reserve their skills for those rare
    occasions where they are ahead of the compilers or, as you rightly
    point out, where there are no alternatives, such as in setting up the
    stack or posting a kernel trap.

    Also note that subjectivity tends to creep into this argument. It is
    easier to believe that one can write extremely efficient assembler
    code, where common wisdom is that good compiler optimisation
    techniques exceed the skills of the most sophisticated assembler
    programmers. At a visceral level even I have trouble believeing it,
    but experience shows it to be true. And the GCC developers certainly
    put a lot of effort into proving it true.

    Still, like in Fortran, assembler programming is challenging and
    rewarding in the product rather than its functionality. If we could
    reduce this macho appeal, perhaps we could also convince engineers to
    design processors with higher level instruction sets.

    ++L


  8. Re: [9fans] speaking of kenc

    On 5/6/07, lucio@proxima.alt.za wrote:
    > > im talking from the kernel writer point of view. and im most familiar
    > > with the x86. c assumes there is a system already running. and most
    > > probably that system is brought up using assembly coded initialization
    > > code.

    >
    > No one said that assembler is obsolete, only deprecated. Like many
    > "we have always done it this way" paradigms, it dies hard and it is
    > difficult to persuade "aficionados" that they would be better off
    > programming at a higher level and reserve their skills for those rare
    > occasions where they are ahead of the compilers or, as you rightly
    > point out, where there are no alternatives, such as in setting up the
    > stack or posting a kernel trap.
    >


    i see.

    i understand now that this thread is about putting asm in the system
    library or not.

    of course not. its a bitch to optimize.

    compiler technology has advanced by leaps and bounds. nowadays
    compilers are even made to schedule the machine instructions and do
    branch prediction. some massively parallel processors cant even be
    optimally hand programmed by assembler anymore.

  9. Re: [9fans] speaking of kenc

    lucio@proxima.alt.za wrote:
    >>> That C and not assembler ought to be the target language, no matter
    >>> the application. That assembler is deprecated in favour of C.

    >> If that ever comes to pass, I'm going back to a wire-wrap tool.
    >>

    > I don't see why. I did post the sum-total of assembler coding in the
    > Plan 9 source directory, libraries and kernel code excluded. Has that
    > sent you back to the wire-wrap tool yet?


    No - I am not advocating 'shedding' C - just opposed to mandating it or
    'settling' for it to the exclusion of other tools.

    Absent machine code or asm, there are things that would *have to* be done
    physically in mask, wire-bonding, or conductor paths.

    >
    > Nobody said that C had to be the highest common denominator, only that
    > it should be the lowest, instead of asm.
    >


    Ok - let's say if not C as-we-know-it, then something so close in 'span' as to
    be functionally the same. 'D' is close, few others are (check the speed alone).

    A frustration is that the very things that most need a bullet-proof
    implemntation - kernel and device drivers - are the hardest to get right at any
    usable speed in anything OTHER THAN C.

    Yet - despite long-available tools anto prevent it we are still seeing 'buffer
    overrun...' security holes - and in new code, not just overlooked legacy code.

    'D' - whatever else is good or bad about it - at least closes that one off a bit
    better.

    >> There *can be no* one-size fits-all final answers unless and until all progress
    >> is to be called off and stagnation and decline to the death are mandated from
    >> on-high.
    >>

    > That is a view from an uncommon position. It so happens that our
    > brain can "evolve" much more rapidly than any other organism, with
    > mutations occurring on a very small timescale. But that perspective
    > is unique to that particular condition. And one can philosophise on
    > how useful this continuous mutation really is.
    >
    >> Not even for biologicals with billion+ year history.
    >>

    > Ever wondered how old the nearest amoeba is? From his point of view,
    > we're just a passing phase :-)


    LOL! But that amoeba is not the same as his remotest ancestor, either, if only
    w/r salinity, temperature, mineral and dissolved gas level adaptation.

    >
    >> 'adapt or die' may have long cycle, but it is an unforgiving one.

    >
    > As you go higher in evolutionary complexity, this becomes more
    > important, but it's an artifact, not a natural principle. It stems
    > from organic complexity that is more dependent on active conditions.
    > The ability to deal with environmental change without need to mutate
    > seems to me to be more powerful than the ability to mutate at the
    > slightest whim.
    >


    Point. Though radiodurens is far older than we are, and better traveled it seems..

    > C is one such paradigm. Consider that early versions of Windows (up
    > to 3.1, perhaps) were written in Pascal; at the time that was
    > Microsoft's bet for the future. C took over from Pascal and only
    > Microsoft can document the pain and gain of moving to it.


    Well - if we have to start talking trash, let's pick a better-grade of trash
    than WinWOES. That's the software equivalent of the feces of common housefly -
    found nearly everywhere, but not welcome in MY coffee cup!

    ;-)

    > That C is
    > still around today, one dares say _despite_ interference from various
    > well-meaning committees, speaks volume to the genius of its inventors.


    Partially, yes. But google a bit and find those inventors have publically
    expressed mixed feelings about that measure of 'success' at one time or another.

    The huge code base can be as stifling to improvement as it is useful.

    Inertia cuts both ways.

    > I don't think it was blind luck, I think it was genius. That
    > something may eventually supersede C is unarguable, but I think it
    > will take a very large paradigm shift to make that possible or
    > necessary.
    >
    > ++L
    >
    >


    ACK. It is already 'necessary' in my view, or at the least 'worth attempting'
    with greater effort.

    And that if only to reduce debug labor - and time spent on it.

    Look at Boeing's rationale for insisting on Ada - and mind - I have no great
    love for Ada - but the numbers - and the short Sunstrand retraining cycle are
    eye openers.

    When a language becomes as ubiquitous as C has, you have to take cognizance of
    the fact that this means a lot more less-skilled coders have come on board, then
    either modify the language so they are less likely to screw it up - or change
    the toolset altogether and restrict 'C use to the very best coders or at least
    the closest scrutiny.

    The *bucks* involved in debugging - or even managing - large team efforts in 'C'
    are getting very serious - especially on projects where time is of the essence.

    'Too soon we forget' that C as used in Unix/Linux/Plan9 has had a *very* long
    and oft painful devel cycle to get here. And we are still fixing old work.

    So 'genius'?

    At the time, perhaps.

    By by now, perhaps as much a product of widely available libs and examples,
    dogged determination and 'many eyes, many hands'. Not to mention LESSER
    availability of alternatives.

    To an extent that is akin to WinWOES pushing out other options merely by
    displacement.

    C is not going to 'go away' any time soon - but neither is it necessarily as
    good a tool for the next 10-20 years as it was the last.

    Bill


+ Reply to Thread