> 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

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

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

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

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.

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

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

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

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?

> 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

> 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

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

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

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

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

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.

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

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

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.