> 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

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

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

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

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

> 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

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.

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