[9fans] speaking of kenc

[erik quanstrom]

are these c99 "features" from /sys/src/cmd/cc/c99 really features
or are they "unwanted"?

Not done (yet?):
11. _Complex, _Imaginary, _Bool
18. Notation for universal characters \uXXXX
26. _Bool, float _Complex, double _Complex, long double _Complex

- erik

[David Leimbach]

Those are all real C99 features :-).

Whether anyone really thinks they're worth a damn is another question.

Post by erik quanstrom
are these c99 "features" from /sys/src/cmd/cc/c99 really features
or are they "unwanted"?
11. _Complex, _Imaginary, _Bool
18. Notation for universal characters \uXXXX
26. _Bool, float _Complex, double _Complex, long double _Complex
- erik

[Bruce Ellis]

official C went downhill more than 20 years ago.

fortunately you can still program in what i called "Safe-C"
in some flippant paper.

i was particulalry impressed with VS2005 which has
wchar_t as a fundamental type which can't be assigned
to anything.

shoot me, i did a if(sizeof(wchar_t) == sizeof(Rune)) etc.

it seems that subjective C is more popular than objective C.

brucee

Post by David Leimbach
Those are all real C99 features :-).
Whether anyone really thinks they're worth a damn is another question.

Post by erik quanstrom
are these c99 "features" from /sys/src/cmd/cc/c99 really features
or are they "unwanted"?
11. _Complex, _Imaginary, _Bool
18. Notation for universal characters \uXXXX
26. _Bool, float _Complex, double _Complex, long double _Complex
- erik

--
But let your communication be, Yea, yea; Nay, nay: for whatsoever
is more than these cometh of evil.

[Skip Tavakkolian]

Post by Bruce Ellis
i was particulalry impressed with VS2005 which has
wchar_t as a fundamental type which can't be assigned
to anything.

but you can probably assign '1234' to it; no need for L either, valid
literal in c99. gosh, i sure hope there is a cMMIX in the works.

[Joel C. Salomon]

Post by erik quanstrom
are these c99 "features" from /sys/src/cmd/cc/c99 really features
or are they "unwanted"?
11. _Complex, _Imaginary, _Bool

That'd be a question for the HPC people; ron, do you miss complex types in 9c?

_Bool is a notational convenience, maybe helping document functions
returning only pass/fail status, or for the isalpha(2) family of
functions.

Post by erik quanstrom
18. Notation for universal characters \uXXXX

For the characters in Plan 9's char set, it's unneeded; you can type
the character in as many keystrokes (Alt, X, xxxx). For characters
outside Unicode's BMP, it's not terribly helpful, since Plan 9 doesn't
understand them at all.

That said, these universal characters aren't hard to implement at all.
Come semester's end and I'll submit a patch to add them to the lexer.

[Bruce Ellis]

never understimate trigraphs for something that made it into a standard
but nobody every uses. ever.

brucee.

Post by Joel C. Salomon

Post by erik quanstrom
are these c99 "features" from /sys/src/cmd/cc/c99 really features
or are they "unwanted"?
11. _Complex, _Imaginary, _Bool

That'd be a question for the HPC people; ron, do you miss complex types in 9c?
_Bool is a notational convenience, maybe helping document functions
returning only pass/fail status, or for the isalpha(2) family of
functions.

Post by erik quanstrom
18. Notation for universal characters \uXXXX

For the characters in Plan 9's char set, it's unneeded; you can type
the character in as many keystrokes (Alt, X, xxxx). For characters
outside Unicode's BMP, it's not terribly helpful, since Plan 9 doesn't
understand them at all.
That said, these universal characters aren't hard to implement at all.
Come semester's end and I'll submit a patch to add them to the lexer.

[Charles Forsyth]

Post by Joel C. Salomon
_Bool is a notational convenience, maybe helping document functions
returning only pass/fail status, or for the isalpha(2) family of
functions.

no, since its type is different from that produced by the logical
and equality operators (eg, ! and ==) which are still int!
it's a unsigned integer type with a limited range (0 or 1), a special
conversion rule, and of course a peculiar name (not even _bool!).
pointless tinkering.

[David Leimbach]

Post by Charles Forsyth

Post by Joel C. Salomon
_Bool is a notational convenience, maybe helping document functions
returning only pass/fail status, or for the isalpha(2) family of
functions.

no, since its type is different from that produced by the logical
and equality operators (eg, ! and ==) which are still int!
it's a unsigned integer type with a limited range (0 or 1), a special
conversion rule, and of course a peculiar name (not even _bool!).
pointless tinkering.

Since we're complaining about stuff being standardized to death...
consider the entire tgmath.h header which actually can't be
implemented in legal C99... yet is a part of C99. That one's a real
twister...

[Douglas A. Gwyn]

Post by David Leimbach
Since we're complaining about stuff being standardized to death...
consider the entire tgmath.h header which actually can't be
implemented in legal C99... yet is a part of C99. That one's a real
twister...

There have always been some library features that are not
implementable within the language itself. The real complaint
about <tgmath.h> should be that it mandates some mechanism
that the implementation can exploit, but that mechanism is
not made available to the general programmer.

I will agree that <tgmath.h> is of dubious design and utility.

If you guys really care about this stuff, you should participate
in the process, rather than sit on the sidelines and carp about
what others have done.

[erik quanstrom]

good point. except, dennis was mostly ignored.
why should mortals expect different results?

i also don't understand your defence of _Bool. why
add a type that behaves in a nonstandard manner?
i see two disadvantages with this approach.
1. the compiler must have special rules for a type
with irregular rules.
2. programmers must remember these special rules,
increasing the chance of error.

why would a typedef- or enum-based boolean type
fail to serve this purpose, assuming one is convinced
of the need for a boolean type.

- erik

Post by Douglas A. Gwyn
If you guys really care about this stuff, you should participate
in the process, rather than sit on the sidelines and carp about
what others have done.

[Tim Wiess]

Post by erik quanstrom
good point. except, dennis was mostly ignored.
why should mortals expect different results?

perhaps we just need to speak lounder.

[Uriel]

Or give up and go work for Google on AJAX.

Post by Tim Wiess

Post by erik quanstrom
good point. except, dennis was mostly ignored.
why should mortals expect different results?

perhaps we just need to speak lounder.

[Charles Forsyth]

Post by erik quanstrom
why would a typedef- or enum-based boolean type
fail to serve this purpose, assuming one is convinced
of the need for a boolean type.

that's easy, and that's why one reason i picked on _Bool:
it has a special new conversion rule (added
to `the usual arithmetic conversions') that can't
be done using typedefs or enums, namely that any
non-zero value converts to 1. that is needed to
work with the existing conditional structure.
it's all done to satisfy all earlier right-thinking people,
who thought that languages without a boolean type
were clearly depraved, that this zero/non-zero stuff
was just perverse, and therefore added boolean themselves (differently) using
typedefs and enums; which didn't work correctly.
they couldn't get that right, but they could fill in
the right documents and do the political work to change
the standard.

[Douglas A. Gwyn]

Post by erik quanstrom
good point. except, dennis was mostly ignored.
why should mortals expect different results?

To the extent that Dennis provided input to the C standards effort,
he was certainly not ignored! Indeed, sizeof(char)==1 and
restrict instead of noalias were both direct responses to his input.

Post by erik quanstrom
i also don't understand your defence of _Bool. why
add a type that behaves in a nonstandard manner?

It is just an arithmetic type with width at least 1, and
conversion rules aimed at maximizing its Boolean nature.

It is a pity that the result of relational expressions (for
example) cannot be Boolean, for reasons of historical
compatibility, but that's not the fault of _Bool (or plain
"bool" as it is meant to be used via <stdbool.h>).

Post by erik quanstrom
why would a typedef- or enum-based boolean type
fail to serve this purpose, assuming one is convinced
of the need for a boolean type.

There are a number of possible solutions. _Bool and
<stdbool.h> were selected as the best proposal under
the existing constraints (don't break all the existing code
already using typedef int bool, allow C++ compatibility,
etc.).

[Uriel]

Post by Douglas A. Gwyn
There are a number of possible solutions. _Bool and
<stdbool.h> were selected as the best proposal under
the existing constraints (don't break all the existing code
already using typedef int bool, allow C++ compatibility,
etc.).

What about the "don't add any more junk to the standard" solution? Or
what about finding out if there is any problem that needs 'fixing'
before looking for a solution?

% grep 'Brian Reid' /sys/games/lib/fortunes
Geez, you'd think standards were a continental disease or something. -
Brian Reid

To me they look like an 'incontinental' disease.

uriel

[erik quanstrom]

Post by Douglas A. Gwyn
It is just an arithmetic type with width at least 1, and
conversion rules aimed at maximizing its Boolean nature.
It is a pity that the result of relational expressions (for
example) cannot be Boolean, for reasons of historical
compatibility, but that's not the fault of _Bool (or plain
"bool" as it is meant to be used via <stdbool.h>).

this is different from how c has traditionally done types.
c types mapped to what the hardware provides. unless
you're working on a hc6508 or similar, you probablly don't
have bit-wide memory access.

it's more in the spirit of oberon, or pascal which have
had more formally defined and machine independent
types.

- erik

[Douglas A. Gwyn]

Post by erik quanstrom
this is different from how c has traditionally done types.
c types mapped to what the hardware provides. unless
you're working on a hc6508 or similar, you probablly don't
have bit-wide memory access.
[bool]'s more in the spirit of oberon, or pascal which have
had more formally defined and machine independent
types.

C has a long tradition of not mapping precisely into the
native types, not even on the PDP-11, where "long"
was word-swapped from the native format. bool can
easily be implemented in one of the native integer types.
Its properties are appropriate for its use.

[erik quanstrom]

Post by Douglas A. Gwyn

Post by erik quanstrom
this is different from how c has traditionally done types.
c types mapped to what the hardware provides. unless
you're working on a hc6508 or similar, you probablly don't
have bit-wide memory access.
[bool]'s more in the spirit of oberon, or pascal which have
had more formally defined and machine independent
types.

C has a long tradition of not mapping precisely into the
native types, not even on the PDP-11, where "long"
was word-swapped from the native format. bool can
easily be implemented in one of the native integer types.
Its properties are appropriate for its use.

i assume you mean that the word order was different than
what the dec compilers generated, not that the unix c compiler
generated code to word swap longs after the operation. if that's
true, this case isn't analogous.

in the case of _Bool assignment the compiler needs to generate
magic fixup code on each assignment to overcome the machine.

i would assume (since i don't have the code), the pdp-11 compiler
needed to do the same dance we do these days for vlong. (or
one does for short on an 8-bit machine). while this isn't pretty,
a bigger integer than the hardware provides can be needed and
difficult to manufacture efficiently in c without access to the
carry bit or extended MUL result.

- erik

[Jon Snader]

Post by erik quanstrom
it's more in the spirit of oberon, or pascal which have
had more formally defined and machine independent
types.

Indeed. This (_Bool) does seem to be a solution in search of a
problem. Is there anyone (other than a few refugees from Pascal)
who believes that C suffers from its lack of a formal boolean
type?

jcs

[Devon H. O'Dell]

Post by Jon Snader

Post by erik quanstrom
it's more in the spirit of oberon, or pascal which have
had more formally defined and machine independent
types.

Indeed. This (_Bool) does seem to be a solution in search of a
problem. Is there anyone (other than a few refugees from Pascal)
who believes that C suffers from its lack of a formal boolean
type?

I've seen more than my fair share of tf = !!value; out there, which is
just awful to read. It is very useful to have a defined way of
determining the binary success or failure of an operation without
having to understand whether -1, 1, 0, 38, or -129125 is success,
failure, or indication of an error condition.

Post by Jon Snader
jcs

--dho

[erik quanstrom]

Post by Devon H. O'Dell
I've seen more than my fair share of tf = !!value; out there, which is
just awful to read. It is very useful to have a defined way of
determining the binary success or failure of an operation without
having to understand whether -1, 1, 0, 38, or -129125 is success,
failure, or indication of an error condition.

i'm not sure why a boolean type fixes this problem. using _Bool
in this case shoves some implicit magic into '=' that wasn't there
before and doesn't map at all to how the machine really works.

what's wrong with this?

if(tf != 0)
return 0;
return -1;

- erik

[Devon H. O'Dell]

Post by erik quanstrom

Post by Devon H. O'Dell
I've seen more than my fair share of tf = !!value; out there, which is
just awful to read. It is very useful to have a defined way of
determining the binary success or failure of an operation without
having to understand whether -1, 1, 0, 38, or -129125 is success,
failure, or indication of an error condition.

i'm not sure why a boolean type fixes this problem. using _Bool
in this case shoves some implicit magic into '=' that wasn't there
before and doesn't map at all to how the machine really works.
what's wrong with this?
if(tf != 0)
return 0;
return -1;

Nothing is wrong with that, but the point is that it isn't always that
simple. UNIX in general has different meanings in different places.
This isn't C's fault, but not having a boolean type has contributed to
this (ab)use of the meaning of magic integers. Sometimes non-zero is
true and zero is false. Sometimes 0 is true and non-zero is false.
Sometimes 0 is true and non-zero indicate differing levels of
falseness.

It doesn't fix these problems but it discourages them from happening
in the future.

Anyway, indeed, this is a C language discussion, so to not be
completely off topic, what I typically do in Plan 9 is:

enum {
true,
false,
};

(Yes, I know this still has nothing to do with Plan 9, but I tried :))

Post by erik quanstrom
- erik

I'll digress from this thread, because I'm certainly not the best
person to determine what parts of C are good nor bad. Just to bitch
about my own use. I think boolean types are a good thing. But I won't
pollute this list further (and sorry for the current level of
pollution) :(

--dho

[Anthony Sorace]

Post by Jon Snader
Is there anyone (other than a few refugees from Pascal)
who believes that C suffers from its lack of a formal boolean
type?

i think that's the wrong question. i know plenty of people who believe
C suffers from its lack of a formal boolean type, but the correct
question for folks like standards bodies (and the peanut gallery here,
for whatever we matter) is whether adding it (in any particular form)
justifies the cost (in terms of added complexity, architectural
mismatch, monetary cost of implementation, or whatever criteria one
chooses) of adding it to the standard.

personally, i think any advantages of _Bool over the plethora of
ad-hoc implementations are not worth the oddities and discongruity
that go with this implementation. as i'm not a C compiler implementor
and don't generally miss boolean types myself, i'm not going to
complain too much.

[Douglas A. Gwyn]

Post by Anthony Sorace
i think that's the wrong question. i know plenty of people who believe
C suffers from its lack of a formal boolean type, but the correct
question for folks like standards bodies (and the peanut gallery here,
for whatever we matter) is whether adding it (in any particular form)
justifies the cost (in terms of added complexity, architectural
mismatch, monetary cost of implementation, or whatever criteria one
chooses) of adding it to the standard.

How hard would it be to add the following to the directory where standard
headers are kept?

/* stdbool.h -- almost conforming implementation for pre-C99 environments */
#ifndef __bool_true_false_are_defined
#define __bool_true_false_are_defined 1
/* program is allowed to contain its own definitions, so ... */
#undef bool
#undef true
#undef false
#define bool int
#define true 1
#define false 0
#endif /* !defined(__bool_true_false_are_defined) */

This provides 99% of the Boolean functionality that is actually used by
C99-based applications without having to implement _Bool at all.

[Steve Simon]

Ok,

As we are on the perenial subject of standards, my biggest gripe
when porting C (which is the problem we are trying to solve
here right?) is Configure/autoconf, rather than the C language itself.

How we can sidestep autohell?

I once had the idea that we (plan9) could parse the autoconf
definition files from which autoconf generates its Configure script,
(apologies if my terminology is a bit off, I am no expert), and
generate a makefile from that.

It gets a bit nasty as these definition files can contain snippets
of shell script to test unusal features of your OS/compile environment
but I guess those could be passed to ape/sh.

Anyone thought about this, have any ideas, etc? or are we still stuck
with "unpack the tar on linux, run Configure, copy the hierarchy to
Plan9, edit the makefile" ☹.

-Steve

[David Arnold]

-->"Steve" == Steve Simon <***@quintile.net> writes:

Steve> How we can sidestep autohell?

autohell is now a 3-headed beast: automake, autoconf and libtool, where
some of those are actually multiple components.

automake is PERL thing that takes a "simplified" Makefile.am, and emits
a Makefile.in. its added value is understanding how to drive libtool,
and the creation of Makefiles with standard targets.

autoconf is a Bourne-ish Shell script and a suite of m4 macros. it
processes various m4 *.in files to produce (at minimum) a Bourne Shell
configure script, and a set of Makefiles. its added value is two-fold:
a series of HAVE_FOO macros used to compile different code fragments,
and various other variables substituted into the Makefiles to actually
compile and link different files.

libtool is another Bourne-ish Shell script that encodes knowledge of how
shared libraries are built using different linker and runtime-linker
variants.

i suspect that they probably require bash, GNU m4 and GNU sed. automake
needs PERL.


those porting Python, etc, must have dealt with this somehow?




d

[Adrian Tritschler]

Post by David Arnold
Steve> How we can sidestep autohell?
autohell is now a 3-headed beast: automake, autoconf and libtool,
where some of those are actually multiple components.

Does any of this really *help* with the business of getting arbitrary
software to compile? The few times I've ever looked into the mess of
(what seems to me) endlessly circular dependencies of tools and scripts
and configuration files it seems that most of the config. stuff is busy
fighting *against* auto-blah and trying to simply tell a Makefile where
to find something.

Post by David Arnold
automake is PERL thing that takes a "simplified" Makefile.am, and
emits a Makefile.in. its added value is understanding how to drive
libtool, and the creation of Makefiles with standard targets.
autoconf is a Bourne-ish Shell script and a suite of m4 macros. it
processes various m4 *.in files to produce (at minimum) a Bourne Shell
configure script, and a set of Makefiles. its added value is
two-fold: a series of HAVE_FOO macros used to compile different code
fragments, and various other variables substituted into the Makefiles
to actually compile and link different files.
libtool is another Bourne-ish Shell script that encodes knowledge of
how shared libraries are built using different linker and
runtime-linker variants.
i suspect that they probably require bash, GNU m4 and GNU sed.
automake needs PERL.

...each one of which probably needs autoconf, automake and libtool to
build.

Post by David Arnold
those porting Python, etc, must have dealt with this somehow?

Whiskey?

Post by David Arnold
d

Adrian

[Paul Lalonde]

Autohell is caused by an underlying, much more dangerous problem that
needs to be addressed: the belief that the myriad POSIX derivatives
are somehow "different" systems. The superficial incompatibilities
between the lot of them are addressed by auto*, but simple text
substitution is insufficient to get around the deeper semantic
differences when using non-POSIX. And until a case is made for
supporting non-POSIX systems, autohell will continue to thrive, one
kludge at a time.

I used to be a fan of POSIX standardization, but now see the error of
my ways.

I know of no way evangelism can succeed against such a firmly
entrenched standard, no matter how flawed. The best I think we can
do as a community is to keep looking for the killer ap; sadly, I
don't think it's in the user space.

OBP9: Cell mmu.c is nearly done. IBM's systemsim is a godsend. I'm
glad I don't have to implement mmap ;-)

Paul

Post by Adrian Tritschler

Post by David Arnold
Steve> How we can sidestep autohell?
autohell is now a 3-headed beast: automake, autoconf and libtool,
where some of those are actually multiple components.

Does any of this really *help* with the business of getting arbitrary
software to compile? The few times I've ever looked into the mess of
(what seems to me) endlessly circular dependencies of tools and scripts
and configuration files it seems that most of the config. stuff is busy
fighting *against* auto-blah and trying to simply tell a Makefile where
to find something.

Post by David Arnold
automake is PERL thing that takes a "simplified" Makefile.am, and
emits a Makefile.in. its added value is understanding how to drive
libtool, and the creation of Makefiles with standard targets.
autoconf is a Bourne-ish Shell script and a suite of m4 macros. it
processes various m4 *.in files to produce (at minimum) a Bourne Shell
configure script, and a set of Makefiles. its added value is
two-fold: a series of HAVE_FOO macros used to compile different code
fragments, and various other variables substituted into the Makefiles
to actually compile and link different files.
libtool is another Bourne-ish Shell script that encodes knowledge of
how shared libraries are built using different linker and
runtime-linker variants.
i suspect that they probably require bash, GNU m4 and GNU sed.
automake needs PERL.

...each one of which probably needs autoconf, automake and libtool to
build.

Post by David Arnold
those porting Python, etc, must have dealt with this somehow?

Whiskey?

Post by David Arnold
d

Adrian

[Federico Benavento]

hola,

atohell is crap, we all know it. You'll find how I bypass it in my other post.
but the bigest problem is the lack of the gcc family.

"You are not using a supported compiler. We do not have the time to make sure
everything works with compilers other than the ones we use. Use either the
same compiler as we do, or use --disable-gcc-check but DO *NOT* REPORT BUGS
unless you can reproduce them after recompiling with a 2.95.x or 3/4.x version!"

that's the msg I got when running MPlayer's configure.

enough ranting ;)

Post by Paul Lalonde
OBP9: Cell mmu.c is nearly done. IBM's systemsim is a godsend. I'm
glad I don't have to implement mmap ;-)

congrats!

[Anthony Sorace]

Post by Federico Benavento
"You are not using a supported compiler. We do not have the time to make sure
everything works with compilers other than the ones we use. Use either the
same compiler as we do, or use --disable-gcc-check but DO *NOT* REPORT BUGS
unless you can reproduce them after recompiling with a 2.95.x or 3/4.x version!"

note the best part here: the implicit assumption that there is only
one compiler. by "same compiler as we [use]", they mean the same
*version*. using an actual different compiler (we needn't even get as
"exotic" as kencc; lcc will do nicely) is so far outside the realm of
possibility they don't even need to tell you not to do it.

[LiteStar numnums]

I'm a unix admin at work, and was building a copy of php for a dev. I'd sure
hate to miss one of those libraries to include; luckily libtool finally
gave:
-lcrypt -lcrypt -liconv -liconv -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lxml2
-lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -o
sapi/cli/php
Now if I could only write the Department of Redundancy Department at FSF
we'll be all set...

Post by Federico Benavento
hola,
atohell is crap, we all know it. You'll find how I bypass it in my other post.
but the bigest problem is the lack of the gcc family.
"You are not using a supported compiler. We do not have the time to make sure
everything works with compilers other than the ones we use. Use either the
same compiler as we do, or use --disable-gcc-check but DO *NOT* REPORT BUGS
unless you can reproduce them after recompiling with a 2.95.x or 3/4.x version!"
that's the msg I got when running MPlayer's configure.
enough ranting ;)

Post by Paul Lalonde
OBP9: Cell mmu.c is nearly done. IBM's systemsim is a godsend. I'm
glad I don't have to implement mmap ;-)

congrats!
--
Federico G. Benavento

[Roman Shaposhnick]

Post by Federico Benavento
hola,
atohell is crap, we all know it. You'll find how I bypass it in my other post.
but the bigest problem is the lack of the gcc family.
"You are not using a supported compiler. We do not have the time to make sure
everything works with compilers other than the ones we use. Use either the
same compiler as we do, or use --disable-gcc-check but DO *NOT* REPORT BUGS
unless you can reproduce them after recompiling with a 2.95.x or 3/4.x version!"
that's the msg I got when running MPlayer's configure.

To be completely honest -- that's not their fault actually. Its just
that GCC is so broken when it comes to compatibility that you wouldn't
believe it.

Thanks,
Roman.

P.S. Here at Sun I've been putting some of the GCC extensions
into Sun Studio, and even though I usually feel disgusted about most
of them -- things like asm inlines are actually quite useful. And
that's what kenc has no way of providing.

[Lyndon Nerenberg]

Post by Roman Shaposhnick
P.S. Here at Sun I've been putting some of the GCC extensions
into Sun Studio, and even though I usually feel disgusted about most
of them

Oh God please NO! I've been using the Sun Studio compiler as a reference
compiler to weed out all this GNU bullshit. You guys already ship gcc in
/usr/sfw. Please don't fuck the rest of the world up with this nonsense.


--lyndon

I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again.

[erik quanstrom]

Post by Roman Shaposhnick
of them -- things like asm inlines are actually quite useful. And
that's what kenc has no way of providing.

the more you see, the more you come to love ken's compiler
for the features it does not have.

- erik

[Roman Shaposhnick]

Post by erik quanstrom

Post by Roman Shaposhnick
of them -- things like asm inlines are actually quite useful. And
that's what kenc has no way of providing.

the more you see, the more you come to love ken's compiler
for the features it does not have.

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.

Thanks,
Roman.

[Lyndon Nerenberg]

Post by Roman Shaposhnick
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).


--lyndon

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.

-- Dave Presotto

[Roman Shaposhnick]

Post by Lyndon Nerenberg

Post by Roman Shaposhnick
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.

Post by Lyndon Nerenberg
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.

[Lyndon Nerenberg]

Post by Roman Shaposhnick

Post by Lyndon Nerenberg
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?

Post by Roman Shaposhnick
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.

Post by Roman Shaposhnick
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.

Post by Roman Shaposhnick
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

[Bruce Ellis]

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

Post by Lyndon Nerenberg

Post by Roman Shaposhnick

Post by Lyndon Nerenberg
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?

Post by Roman Shaposhnick
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.

Post by Roman Shaposhnick
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.

Post by Roman Shaposhnick
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

[Roman Shaposhnick]

Post by Bruce Ellis
isn't it bleeding obvious by now that asm is dumb.

I don't think it is obvious, no.

Post by Bruce Ellis
a function call into something in a *.s file will do.

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

Post by Bruce Ellis
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.

[Roman Shaposhnick]

Post by Lyndon Nerenberg

Post by Roman Shaposhnick

Post by Lyndon Nerenberg
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.

Post by Lyndon Nerenberg

Post by Roman Shaposhnick
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.

[Bruce Ellis]

i meant it.

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

explain a simple case when you need it.

brucee

Post by Roman Shaposhnick

Post by Lyndon Nerenberg

Post by Roman Shaposhnick

Post by Lyndon Nerenberg
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.

Post by Lyndon Nerenberg

Post by Roman Shaposhnick
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.

[erik quanstrom]

Post by Bruce Ellis
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

[l***@proxima.alt.za]

Post by erik quanstrom
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

[Bruce Ellis]

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

Post by l***@proxima.alt.za

Post by erik quanstrom
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

[Rogelio Serrano]

Post by Bruce Ellis
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.

[erik quanstrom]

Post by l***@proxima.alt.za
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.

Post by l***@proxima.alt.za
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

[W B Hacker]

Post by erik quanstrom

Post by l***@proxima.alt.za
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

Post by erik quanstrom

Post by l***@proxima.alt.za
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'.

Post by erik quanstrom
also, could you explain why this is "lazy"? or why assembly is more
complicated?

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

;-)

Post by erik quanstrom
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....

Post by erik quanstrom
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]

Post by erik quanstrom
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.

[Rogelio Serrano]

Post by Rogelio Serrano

Post by erik quanstrom
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.

[l***@proxima.alt.za]

Post by Rogelio Serrano
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

[Bruce Ellis]

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

Post by l***@proxima.alt.za

Post by Rogelio Serrano
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

[l***@proxima.alt.za]

Post by Rogelio Serrano
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

[W B Hacker]

Post by erik quanstrom

Post by l***@proxima.alt.za
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

Post by erik quanstrom

Post by l***@proxima.alt.za
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'.

Post by erik quanstrom
also, could you explain why this is "lazy"? or why assembly is more
complicated?

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

;-)

Post by erik quanstrom
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....

Post by erik quanstrom
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

[l***@proxima.alt.za]

Post by erik quanstrom

Post by l***@proxima.alt.za
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.

Post by erik quanstrom
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.

Post by erik quanstrom

Post by l***@proxima.alt.za
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.

Post by erik quanstrom
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.

Post by erik quanstrom
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

[W B Hacker]

Post by Rogelio Serrano

Post by erik quanstrom
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

[Rogelio Serrano]

Post by Bruce Ellis
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?

[erik quanstrom]

Post by Rogelio Serrano
compiling c code. can you imagine a c compiler that does not translate
to asm first?

like ken's c compiler?

- erik

[Rogelio Serrano]

Post by erik quanstrom

Post by Rogelio Serrano
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.

[l***@proxima.alt.za]

Post by Rogelio Serrano
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.

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.

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.

++L

PS: I keep thinking that this is not 9fans, but rather
alt.folklore.computers. Does anyone out there have a copy of
Hollingdale and Toothill (Digital Computers, was it?) that they would
be willing to part with for a moderate amount of money?

[Bruce Ellis]

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

Post by Rogelio Serrano

Post by Bruce Ellis
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?

[l***@proxima.alt.za]

Post by Roman Shaposhnick
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.

Post by Roman Shaposhnick
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

[erik quanstrom]

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

Post by Roman Shaposhnick
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.

[C H Forsyth]

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.

[erik quanstrom]

Post by C H Forsyth
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

[Paul Lalonde]

Post by C H Forsyth
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.

Post by C H Forsyth
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

[davide+ (Dave Eckhardt)]

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

[Paul Lalonde]

Post by davide+ (Dave Eckhardt)
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).

Post by davide+ (Dave Eckhardt)
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.

Post by davide+ (Dave Eckhardt)
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.

Post by davide+ (Dave Eckhardt)
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

Post by davide+ (Dave Eckhardt)
Dave Eckhardt

[W B Hacker]

Post by Rogelio Serrano

Post by Bruce Ellis
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.

Post by Rogelio Serrano
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.

Post by Rogelio Serrano
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

[Douglas A. Gwyn]

Post by Roman Shaposhnick
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).

[Roman Shaposhnick]

Post by Douglas A. Gwyn

Post by Roman Shaposhnick
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!

Post by Douglas A. Gwyn
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.

[Douglas A. Gwyn]

Post by Jon Snader
Indeed. This (_Bool) does seem to be a solution in search of a
problem. Is there anyone (other than a few refugees from Pascal)
who believes that C suffers from its lack of a formal boolean
type?

Obviously there were.

Numerous C programmers have created their own Boolean support,
e.g.:
typedef int bool;
#define false 0
#define true 1
The fact that so many have done so argued that there was value
in a standardardized facility along those lines.

As to why the programmers thought it was worth doing, perhaps
they like for data types to match their function, so the source
code becomes more self-documenting and easier to understand;
"int" conveys nothing about a Boolean nature, and actually
suggests some sort of integral measurement of some property.

[Jon Snader]

Post by Douglas A. Gwyn
Obviously there were.
Numerous C programmers have created their own Boolean support,
typedef int bool;
#define false 0
#define true 1

Which is exactly why a formal boolean type is *not* needed.
To paraphrase Dennis, ``If you want Pascal, you know where to
find it.''

jcs

[Jon Snader]

Post by Devon H. O'Dell
I've seen more than my fair share of tf = !!value; out there, which is
just awful to read.

Yes it is, but in the 25 years that I have been programming in C,
I've seen many atrocities. What I haven't seen is a compelling
need for a boolean type. As Brian and Dennis say in the preface
to K&R, C is a small language. That smallness makes it possible
for me to maintain a mental model of what machine code the
compiler will generate for a given C statement and to keep
essentially the whole language in my head. This, in turn, allows
me to write better code. Notice how one can't make similar
statements about, say, C++ (at least I can't). The last thing C
needs is a bunch of cruft to satisfy language purists or to save
the incompetent from themselves.

jcs

P.S. Sorry Russ. I'll stop now.

[Derek Fawcus]

Post by Devon H. O'Dell
I've seen more than my fair share of tf = !!value; out there, which is
just awful to read.

eye of the beholder? Admittedly it is striking the first few times one reads it.

But I see it as just another of those idioms which one gets used to.

Inherently no worse than 'if (!ptr)' or 'if (ptr && ptr->field)'.

I know some people who get really upset whenever they read the above
two. Complaining that 'pointers are not booleans!', and demanding
that comparisions with 'NULL' be added.

DF

[Charles Forsyth]

Post by Derek Fawcus
Inherently no worse than 'if (!ptr)' or 'if (ptr && ptr->field)'.

to tug this back to plan 9, and to encourage new code to resemble old:
typically plan 9 code would have
if(ptr == nil)
if(ptr != nil && ptr->field)
[depending on what `field' was, there might even be a != 0].

we're far too stupid for clever tricks like !!x. we'd probably just write
tf = (x != 0);
assuming that's the correct translation (it's pre-espresso here), but it is hardly ever needed anyway.
!! was probably introduced by people determined to show their perfect grasp
of the language (if not the science). in fact, in the linux kernel !! seems to
be used as an operator much less than it is used in excited comments and exciting messages for the console.
DBG_PRINT(ERR_DBG,"%s:Dont know, can't say!!\n"
to my surprise there are several instances of that in the plan 9 kernel!! but fortunately
none of them is serious, and all were added later!!!

[Douglas A. Gwyn]

Post by Charles Forsyth

Post by Joel C. Salomon
_Bool is a notational convenience, maybe helping document functions
returning only pass/fail status, or for the isalpha(2) family of
functions.

no, since its type is different from that produced by the logical
and equality operators (eg, ! and ==) which are still int!
it's a unsigned integer type with a limited range (0 or 1), a special
conversion rule, and of course a peculiar name (not even _bool!).
pointless tinkering.

Actually we expect that _Bool will be used only via the typedef
"bool" in <stdbool.h>. The reason for the spelling was to use
an identifier that was within the namespace already reserved
for C implementors, so as not to impact any existing code.
Similarly for the complex type(s).

Note also that _Imaginary is not required by C99. There was
considerable debate about the utility (or not) of a purely
imaginary type, in the end deciding that there was insufficient
utility to require it.

There are reasons behind all of the C standards committee's
decisions. Often they reflect practical constraints such as
wanting not to conflict with existing strictly-conforming code.

If VS2005's wchar_t is truly not assignable then it doesn't
conform to the C standard.

[Charles Forsyth]

Post by Joel C. Salomon
_Bool is a notational convenience, maybe helping document functions
returning only pass/fail status, or for the isalpha(2) family of
functions.

oh: and isalpha etc are defined to return int, as are all the other
(conventionally) boolean operations and functions of the standard,
although perhaps i overlooked some.

as a convenience it's mainly a suitable target for micturating.

[erik quanstrom]

Post by Joel C. Salomon
That said, these universal characters aren't hard to implement at all.
Come semester's end and I'll submit a patch to add them to the lexer.

i'm having trouble imagining under what circumstances this could be useful.
can you help me out?

i have yet to see \uxxxx in any code that wasn't part of the c99 spec.

- erik

[Joel C. Salomon]

Post by erik quanstrom

Post by Joel C. Salomon
That said, these universal characters aren't hard to implement at all.

i'm having trouble imagining under what circumstances this could be useful.
can you help me out?

They'd only be useful on systems that don't support Unicode in source
files, the way digraphs and trigraphs are only useful if you have a
broken keyboard without braces. But they're part of the spec, add
maybe 20 lines of code, and don't slow anything down unless they're
used. Maybe in the Unix port of kencc they'll be wanted.

Besides, the handful of minor patches I've submitted have all been
accepted; it's high time I try something that gets

[erik quanstrom]

Post by Joel C. Salomon
They'd only be useful on systems that don't support Unicode in source
files, the way digraphs and trigraphs are only useful if you have a
broken keyboard without braces. But they're part of the spec, add
maybe 20 lines of code, and don't slow anything down unless they're
used. Maybe in the Unix port of kencc they'll be wanted.

one problem. kenc runs on plan 9. plan 9 supports unicode.

have you ever used a di/trigraph? reading one in the spec does not count.

- erik

[Rob Pike]

\u doesn't add anything useful to the plan 9 c compiler because of the
way its input language is defined. it is useful in c99, because of the
way its input language is defined.

in plan 9, each escape sequence in a string constant represents a
unicode code point. "\x1234" represents a string with a single
character with value 0x1234. but in c99, that is an erroneous
string because each escape sequence represents a byte. thus
to represent a unicode value, one is expected to write out the
utf-8 byte sequence. plan 9's "\x1234" becomes, in c99,
"\xe1\x88\xb4". the \u escapes were created to give plan 9's
functionality without breaking compatibility with the existing
implicit meaning of the \x escapes.

this subject is quite long and involved - where does utf-8 fit in?
how does source encoding interact with internal representation?
output encoding? etc. etc. - but the key point about \u is that
it makes sense in a utf-8 world with standard c and c++.

plan 9's c is very non-standard in this regard. i prefer its design
but i don't find \u to be a bad solution. there are a number of
related notations in the standards pipeline to deal with some of
the other issues, such as forcing utf-8 byte sequences. the
notation is going to get pretty ugly.

-rob

[Joel C. Salomon]

Post by erik quanstrom

Post by Joel C. Salomon
Maybe in the Unix port of kencc they'll be wanted.

one problem. kenc runs on plan 9. plan 9 supports unicode.

http://code.google.com/soc/p9/appinfo.html?csaid=79263BFBBBDEAE1B

--Joel

[erik quanstrom]

Post by Joel C. Salomon
http://code.google.com/soc/p9/appinfo.html?csaid=79263BFBBBDEAE1B

i should have said "utf-8", not unicode. in any event, i've used
utf-8 with sam on solaris, irix, aix and linux since 1991 or 1992.

which is to say, there's nothing about unix per se that has ever
prevented utf-8.

one might need to mangle names for the system linker. i haven't
tried.

- erik

[C H Forsyth]

Post by Joel C. Salomon

Post by erik quanstrom

Post by Joel C. Salomon
Maybe in the Unix port of kencc they'll be wanted.

one problem. kenc runs on plan 9. plan 9 supports unicode.

http://code.google.com/soc/p9/appinfo.html?csaid=79263BFBBBDEAE1B

the compilers already run on unix (and windows) and because their input
language handles utf-8 values and escapes in strings, the c99 construction has
not been needed (or i'd have added it). it might be needed for some unix programs
(but there are so many other things those expect that it's probably the least of your
worries)

[ron minnich]

Post by Joel C. Salomon
That'd be a question for the HPC people; ron, do you miss complex types in 9c?

No, but you're not going to like the reason. AFAIK nobody misses it,
because there may not be a single HPC app in widespread use that could
be run on Plan 9 today. We've been looking. Roman knows more than I do
on this issue.

But the apps I've found to date need Fortran, Python, C++, and,
occasionally C; and, on top of that, need a library or two. Oh, and
did I mention, OpenMP, and of course you need an MPI.

This one is instructive:
http://www.llnl.gov/asc/computing_resources/purple/rfp/benchmarks/limited/umt/umt1.2.readme.bm.html

Hence my concerns re Python, but that one is on the way to being solved.

We're trying to work this one :-)

ron

[Charles Forsyth]

This discussion made me curious whether good high-level languages are being developed for scientific computing.

[Rodrigo Miranda]

There's Fortress being developed by Guy Steele at Sun, and others (IBM
has one as well).

http://fortress.sunsource.net/

Its certainly interesting. Whether it's good or not remains to be seen.

[]'s

Rodrigo

Post by Charles Forsyth
This discussion made me curious whether good high-level languages are being developed for scientific computing.

[Eric Van Hensbergen]

Post by Rodrigo Miranda
There's Fortress being developed by Guy Steele at Sun, and others (IBM
has one as well).
http://fortress.sunsource.net/

IBM's is X10 (http://domino.research.ibm.com/comm/research_projects.nsf/pages/x10.index.html)
-- but like Fortress, its so new that there isn't much of an existing
install base and it remains to be seen if there ever will be.

Cray also has been working on a new langauge called Chapel
(http://chapel.cs.washington.edu/)

All three (Chapel, Fortress and X10) were developed for the DARPA HPCS program.

-eric

[Roman Shaposhnik]

Post by Eric Van Hensbergen

Post by Rodrigo Miranda
There's Fortress being developed by Guy Steele at Sun, and others (IBM
has one as well).
http://fortress.sunsource.net/

IBM's is X10 (http://domino.research.ibm.com/comm/research_projects.nsf/pages/x10.index.html)
-- but like Fortress, its so new that there isn't much of an existing
install base and it remains to be seen if there ever will be.
Cray also has been working on a new langauge called Chapel
(http://chapel.cs.washington.edu/)
All three (Chapel, Fortress and X10) were developed for the DARPA HPCS program.

And the biggest issue all these languages will have to address would
be -- scalability. How do you make it easier for compiler to generate
code for 128+ core CPUs and 1000+ nodes cluster. That's a [multi]million
dollar question, not how assignments and such are encoded in the source
file.

Thanks,
Roman.

[Joel C. Salomon]

Post by Charles Forsyth
This discussion made me curious whether good high-level languages are being developed for scientific computing.

On the D newsgroups, there was some discussion of their (super
powerful but also incredibly easy -- and buzzword compliant!) template
mechanism being used to generate near optimal x87 code for linear
algebra stuff.

--Joel

[erik quanstrom]

isn't mmx much faster tha x87 instructions these days?
iirc, the latest intel chips can execute an mmx
instruction in a single clock.

- erik

Post by Joel C. Salomon

Post by Charles Forsyth
This discussion made me curious whether good high-level languages are being developed for scientific computing.

On the D newsgroups, there was some discussion of their (super
powerful but also incredibly easy -- and buzzword compliant!) template
mechanism being used to generate near optimal x87 code for linear
algebra stuff.
--Joel

[Joel C. Salomon]

Post by erik quanstrom

Post by Charles Forsyth
This discussion made me curious whether good high-level languages are being
developed for scientific computing.

On the D newsgroups, there was some discussion of their template
mechanism being used to generate near optimal x87 code for linear
algebra stuff.

isn't mmx much faster tha x87 instructions these days?

It was a proof-of-concept of the power of D's template and macro
system; see <http://www.dsource.org/projects/mathextra/browser/trunk/blade/BladeArticle.txt>.

--Joel

[Lluís Batlle i Rossell]

I'm working a bit on scalpl.
I think it's a very nice idea. But there is almost no implementation.
I'm working on a simple one... but I mostly have test code now.

I wrote a list of links nice to read on it. Mainly for my own notes, but it may
interest someone.
http://vicerveza.homeunix.net/vicerwiki/index.php/ScalPL_linker

(Mostly, I want to write some kind of scheduler, even if not too fast, for
running ScalPL plans)

Post by Charles Forsyth
This discussion made me curious whether good high-level languages are being developed for scientific computing.

[Roman Shaposhnik]

Post by ron minnich

Post by Joel C. Salomon
That'd be a question for the HPC people; ron, do you miss complex types in 9c?

No, but you're not going to like the reason. AFAIK nobody misses it,
because there may not be a single HPC app in widespread use that could
be run on Plan 9 today. We've been looking. Roman knows more than I do
on this issue.

True. Although HPC seems to be changing these days. Ron, I'm just
curious -- what's your definition of an HPC application, or even
HPC market?

Thanks,
Roman.

[Eric Van Hensbergen]

Post by ron minnich
No, but you're not going to like the reason. AFAIK nobody misses it,
because there may not be a single HPC app in widespread use that could
be run on Plan 9 today. We've been looking. Roman knows more than I do
on this issue.

But the question would be whether those applications do use complex
types and thus adding them to KenCC would bring them closer to porting
to Plan 9. At least, that seems a legitimate question.

What Ron is saying is that the problem with making most HPC apps work
on Plan 9 are not C language features -- its the lack of support for
popular languages for doing HPC work. Fortran is the 1000 lbs gorilla
here, although there are quite a few C++ codes as well. The second
problem is the lack of support for certain libraries -- like OpenMP
and MPI -- which are heavily reliant on POSIX features that are the
least compatible with Plan 9 (posix threads, BSD sockets, signals,
mmap, etc.)

Or are you saying that no HPC app comes even remotely close to being
portable?

There are multiple degrees of portability. Most of the world
considers POSIX the portability layer (and APE won't cut it on our end
for the reasons stated above). But even then, HPC apps are large and
complex beasts -- most take a few weeks to a month to figure out how
to compile and tune even on a "standard" system. The problem is there
is increasingly less diversity on the UNIX OS space, so the "standard"
is rapidly moving from POSIX to Linux/X11.

-eric

[LiteStar numnums]

Post by Eric Van Hensbergen
Fortran is the 1000 lbs gorilla

I've often been curious about this. I did some F90 programming, & it wasn't
too bad, but with F77, I could just feel the dust creeping in around the
keyboard (python gives me the same feeling with all those spaces). Is the
Fortran that's used in HPC something more modern like F95/03 (or even F--)?

The rest of the letter is great; I was going to write a response, but your's
hit every point I was going to make better.

Post by Eric Van Hensbergen

Post by ron minnich
No, but you're not going to like the reason. AFAIK nobody misses it,
because there may not be a single HPC app in widespread use that could
be run on Plan 9 today. We've been looking. Roman knows more than I do
on this issue.

But the question would be whether those applications do use complex
types and thus adding them to KenCC would bring them closer to porting
to Plan 9. At least, that seems a legitimate question.

What Ron is saying is that the problem with making most HPC apps work
on Plan 9 are not C language features -- its the lack of support for
popular languages for doing HPC work. Fortran is the 1000 lbs gorilla
here, although there are quite a few C++ codes as well. The second
problem is the lack of support for certain libraries -- like OpenMP
and MPI -- which are heavily reliant on POSIX features that are the
least compatible with Plan 9 (posix threads, BSD sockets, signals,
mmap, etc.)

Or are you saying that no HPC app comes even remotely close to being
portable?

There are multiple degrees of portability. Most of the world
considers POSIX the portability layer (and APE won't cut it on our end
for the reasons stated above). But even then, HPC apps are large and
complex beasts -- most take a few weeks to a month to figure out how
to compile and tune even on a "standard" system. The problem is there
is increasingly less diversity on the UNIX OS space, so the "standard"
is rapidly moving from POSIX to Linux/X11.
-eric

[Roman Shaposhnik]

Post by Eric Van Hensbergen

Or are you saying that no HPC app comes even remotely close to being
portable?

There are multiple degrees of portability. Most of the world
considers POSIX the portability layer (and APE won't cut it on our end
for the reasons stated above). But even then, HPC apps are large and
complex beasts -- most take a few weeks to a month to figure out how
to compile and tune even on a "standard" system. The problem is there
is increasingly less diversity on the UNIX OS space, so the "standard"
is rapidly moving from POSIX to Linux/X11.

Being part of Sun's HPC community I've come to the conclusion that
HPC market is really unique and different from the corporate/enteprise
market in a couple of key areas. The HPC guys seem to be much more
about in-house software development than enterprise guys. And this
actually means that if you can offer them a real differentiator
(even at the level of new programming languages) you have way better
chance of winning them over than you would have with an enterprise
account.

I also see that computing in general is now on the brink of a new
era where we would have to start exploiting parallelism and adapt
our languages and models for that. And no, exploiting parallelism
doesn't mean better OpenMP or better MPI. It means rethinking the
way we do computing. And that, IMHO, means that Plan9 might just
have another chance of entering mainstream computing. Mark my words,
in 5-7 years -- POSIX threads and MPI are going to be as important
as punch cards and COBOL are now.

Just my 2c.

Thanks,
Roman.

[ron minnich]

Post by Roman Shaposhnik
I also see that computing in general is now on the brink of a new
era where we would have to start exploiting parallelism and adapt
our languages and models for that. And no, exploiting parallelism
doesn't mean better OpenMP or better MPI. It means rethinking the
way we do computing. And that, IMHO, means that Plan9 might just
have another chance of entering mainstream computing. Mark my words,
in 5-7 years -- POSIX threads and MPI are going to be as important
as punch cards and COBOL are now.

I'd like to hope this is true. I wish I had not been hearing this
prediction for 10 years :-)

True story: I once had a chance to speed up someone's runtime by a
factor of 50, yes 50, and all they had to do was change one line in a
shell script -- actually, one COMMAND in one LINE. No good -- I had to
do it myself. HPC can be a frustrating business.

But, let's hope it's true that we get to get rid of our old software
baggage. I think it is criminal that people can get away with calling
MPI a "programming model".

Roman, let's plan to get together at a bar in 8 years -- 2015 -- and
drink a toast to the demise of MPI, OpenMP, POSIX threads, and all the
crazy stuff we do now :-)

Actually, not a bar: I'll host the party at my house I just bought :-)

BTW, just to whet appetites here -- assuming Usenix accepts our
poster, we're going to have a pretty cool "Plan 9 and HPC" display at
Usenix. You heard it here first. Hmm, I think I just joined the
marketing dept.

ron

[Steve Simon]

For what its worth, my own brushes with HPC over the years have been
Weather simulations written it C++ and MPI, tens of Mb of F77 Finite
element alanysis run on mainframes (this occured twice), and video processing
software consisting of tools connected by pipes - though nearly all the tools
ran single threaded so parallelsim stops at the length of the pipe, say
20 modules.

Unfortunately none of these would have been applicable to plan9.

I still live in hope though.

-Steve