[9fans] speaking of kenc

[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

Re: [9fans] speaking of kenc

[David Leimbach]

Those are all real C99 features :-).

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

On 4/26/07, erik quanstrom <quanstro@coraid.com> wrote:
> 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
>


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

Re: [9fans] speaking of kenc

[Joel C. Salomon]

On 4/26/07, erik quanstrom <quanstro@coraid.com> wrote:
> 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.

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

Re: [9fans] speaking of kenc

[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

On 4/27/07, David Leimbach <leimy2k@gmail.com> wrote:
> Those are all real C99 features :-).
>
> Whether anyone really thinks they're worth a damn is another question.
>
> On 4/26/07, erik quanstrom <quanstro@coraid.com> wrote:
> > 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
> >
>
>
> --
> - Passage Matthew 5:37:
>   But let your communication be, Yea, yea; Nay, nay: for whatsoever
> is more than these cometh of evil.
>

Re: [9fans] speaking of kenc

[Bruce Ellis]

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

brucee.

On 4/27/07, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
> On 4/26/07, erik quanstrom <quanstro@coraid.com> wrote:
> > 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.
>
> > 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.
>

Re: [9fans] speaking of kenc

[Skip Tavakkolian]

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

Re: [9fans] speaking of kenc

[Charles Forsyth]

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

Re: [9fans] speaking of kenc

[Charles Forsyth]

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

Re: [9fans] speaking of kenc

[erik quanstrom]

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

Re: [9fans] speaking of kenc

[David Leimbach]

On 4/27/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> >_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...

Re: [9fans] speaking of kenc

[Joel C. Salomon]

On 4/27/07, erik quanstrom <quanstro@coraid.com> wrote:
> > 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 rejected.  ☺

--Joel

Re: [9fans] speaking of kenc

[erik quanstrom]

> 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

Re: [9fans] speaking of kenc

[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

Re: [9fans] speaking of kenc

[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

Re: [9fans] speaking of kenc

[erik quanstrom]

> 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

Re: [9fans] speaking of kenc

[C H Forsyth]

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

Re: [9fans] speaking of kenc

[Douglas A. Gwyn]

> >_Bool is a notational convenience, maybe helping document functions
> >returning only pass/fail status, or for the isalpha(2) family of
> >functions.
Charles Forsyth wrote:
> 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.

Re: [9fans] speaking of kenc

[Douglas A. Gwyn]

David Leimbach wrote:
> 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.

Re: [9fans] speaking of kenc

[ron minnich]

On 4/26/07, Joel C. Salomon <joelcsalomon@gmail.com> wrote:

> 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

Re: [9fans] speaking of kenc

[Lucio De Re]

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

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

++L

Re: [9fans] speaking of kenc

[Eric Van Hensbergen]

On 4/28/07, Lucio De Re <lucio@proxima.alt.za> wrote:
> > 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

Re: [9fans] speaking of kenc

[Lucio De Re]

> The problem is there
> is increasingly less diversity on the UNIX OS space, so the "standard"
> is rapidly moving from POSIX to Linux/X11.

Thank you, that clarifies Ron's statement perfectly.

++L

Re: [9fans] speaking of kenc

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

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

On 4/28/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>
> On 4/28/07, Lucio De Re <lucio@proxima.alt.za> wrote:
> > > 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
>



-- 
"No stranger to me is this wanderer: many years ago passed he by.
Zarathustra he was called; but he hath altered.
  Then thou carriedst thine ashes into the mountains: wilt thou now
carry thy fire into the valleys? Fearest thou not the incendiary's
doom?
  Yea, I recognize Zarathustra. Pure is his eye, and no loathing
lurketh about his mouth. Goeth he not along like a dancer?"
-- The Saint, Also Sprach Zarathustra

[-- Attachment #2: Type: text/html, Size: 3281 bytes --]

Re: [9fans] speaking of kenc

[Charles Forsyth]

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

Re: [9fans] speaking of kenc

[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

On 4/28/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> This discussion made me curious whether good high-level languages are being developed for scientific computing.
>

Re: [9fans] speaking of kenc

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

Je la Sat, Apr 28, 2007 at 04:45:56PM +0100, Charles Forsyth skribis:
> This discussion made me curious whether good high-level languages are being developed for scientific computing.

Re: [9fans] speaking of kenc

[Eric Van Hensbergen]

On 4/28/07, Rodrigo Miranda <rodrigo.c.miranda@gmail.com> wrote:
> 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

Re: [9fans] speaking of kenc

[Roman Shaposhnik]

On Sat, 2007-04-28 at 15:12 -0500, Eric Van Hensbergen wrote:
> On 4/28/07, Rodrigo Miranda <rodrigo.c.miranda@gmail.com> wrote:
> > 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.

Re: [9fans] speaking of kenc

[Roman Shaposhnik]

On Sat, 2007-04-28 at 08:48 -0500, Eric Van Hensbergen wrote:
> > 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.

Re: [9fans] speaking of kenc

[Roman Shaposhnik]

On Sat, 2007-04-28 at 02:09 -0700, ron minnich wrote:
> On 4/26/07, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
> 
> > 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.

Re: [9fans] speaking of kenc

[ron minnich]

On 4/28/07, Roman Shaposhnik <rvs@sun.com> wrote:

>   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

Re: [9fans] speaking of kenc

[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

Re: [9fans] speaking of kenc

[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

On Fri Apr 27 12:23:36 EDT 2007, DAGwyn@null.net wrote:
> 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.

Re: [9fans] speaking of kenc

[Joel C. Salomon]

On 4/28/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> 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

Re: [9fans] speaking of kenc

[Tim Wiess]

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

    perhaps we just need to speak lounder.

Re: [9fans] speaking of kenc

[Uriel]

Or give up and go work for Google on AJAX.

On 4/29/07, Tim Wiess <tim@nop.cx> wrote:
> > good point.  except, dennis was mostly ignored.
> > why should mortals expect different results?
>
>     perhaps we just need to speak lounder.
>
>

Re: [9fans] speaking of kenc

[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

On Sat Apr 28 22:39:30 EDT 2007, joelcsalomon@gmail.com wrote:
> On 4/28/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > 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

Re: [9fans] speaking of kenc

[Joel C. Salomon]

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

-- 
It reverses the normal flow of conversation.
> What's wrong with top-posting?
> > Top-posting.
> > > What's the biggest scourge on plain text email discussions?

Re: [9fans] speaking of kenc

[Charles Forsyth]

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

Re: [9fans] speaking of kenc

[Douglas A. Gwyn]

"erik quanstrom" <quanstro@coraid.com> wrote in message 
news:9ce51c75b076ab51a54e2c0352417143@coraid.com...
> 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.

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

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

Re: [9fans] speaking of kenc

[Uriel]

> 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

Re: [9fans] speaking of kenc

[erik quanstrom]

> 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

Re: [9fans] speaking of kenc

[Jon Snader]

On Mon, Apr 30, 2007 at 08:22:56PM -0400, erik quanstrom wrote:
> 
> 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

Re: [9fans] speaking of kenc

[Devon H. O'Dell]

2007/5/1, Jon Snader <jsnader@ix.netcom.com>:
> On Mon, Apr 30, 2007 at 08:22:56PM -0400, erik quanstrom wrote:
> >
> > 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.

> jcs

--dho

Re: [9fans] speaking of kenc

[erik quanstrom]

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

Re: [9fans] speaking of kenc

[Devon H. O'Dell]

2007/5/1, erik quanstrom <quanstro@coraid.com>:
> >
> > 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 :))

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

Re: [9fans] speaking of kenc

[Anthony Sorace]

On 5/1/07, Jon Snader <jsnader@ix.netcom.com> wrote:

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

Re: [9fans] speaking of kenc

[Jon Snader]

On Tue, May 01, 2007 at 10:56:34AM -0400, Devon H. O'Dell wrote:
> 
> 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.

Re: [9fans] speaking of kenc

[Derek Fawcus]

On Tue, May 01, 2007 at 10:56:34AM -0400, Devon H. O'Dell wrote:
> 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

Re: [9fans] speaking of kenc

[Douglas A. Gwyn]

Anthony Sorace wrote:
> 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.

Re: [9fans] speaking of kenc

[Douglas A. Gwyn]

Jon Snader wrote:
> 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.

Re: [9fans] speaking of kenc

[Douglas A. Gwyn]

"erik quanstrom" <quanstro@coraid.com> wrote...
> 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.

Re: [9fans] speaking of kenc

[Charles Forsyth]

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

Re: [9fans] speaking of kenc

[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

Re: [9fans] speaking of kenc

[Jon Snader]

On Wed, May 02, 2007 at 08:33:08AM +0000, Douglas A. Gwyn wrote:
> 
> Obviously there were.
> 
> Numerous C programmers have created their own Boolean support,
> e.g.:
> 	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

Re: [9fans] speaking of kenc

[erik quanstrom]

> "erik quanstrom" <quanstro@coraid.com> wrote...
> > 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

Re: [9fans] speaking of kenc

[David Arnold]

-->"Steve" == Steve Simon <steve@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

Re: [9fans] speaking of kenc

[Adrian Tritschler]

David Arnold <davida@pobox.com> writes:

> -->"Steve" == Steve Simon <steve@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.

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.

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

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

Whiskey?

> d
  Adrian

Re: [9fans] speaking of kenc

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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


On 2-May-07, at 8:39 PM, Adrian Tritschler wrote:

> David Arnold <davida@pobox.com> writes:
>
>> -->"Steve" == Steve Simon <steve@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.
>
> 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.
>
>> 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.
>
>> those porting Python, etc, must have dealt with this somehow?
>
> Whiskey?
>
>> d
>   Adrian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGOV23pJeHo/Fbu1wRAn0mAJ9V3dOplh1hy3KwDXS6O3nP9LRfHgCdFzhQ
ekwfjc8+XSHmTRy/AaHSEOQ=
=NaA3
-----END PGP SIGNATURE-----

Re: [9fans] speaking of kenc

[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 ;)

> 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

Re: [9fans] speaking of kenc

[Anthony Sorace]

On 5/3/07, Federico Benavento <benavento@gmail.com> wrote:

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

Re: [9fans] speaking of kenc

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]

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

On 5/3/07, Federico Benavento <benavento@gmail.com> wrote:
>
> 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 ;)
>
> > 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
>



-- 
"No stranger to me is this wanderer: many years ago passed he by.
Zarathustra he was called; but he hath altered.
  Then thou carriedst thine ashes into the mountains: wilt thou now
carry thy fire into the valleys? Fearest thou not the incendiary's
doom?
  Yea, I recognize Zarathustra. Pure is his eye, and no loathing
lurketh about his mouth. Goeth he not along like a dancer?"
-- The Saint, Also Sprach Zarathustra

[-- Attachment #2: Type: text/html, Size: 2105 bytes --]

Re: [9fans] speaking of kenc

[Roman Shaposhnick]

On Thu, 2007-05-03 at 06:11 +0200, Federico Benavento wrote:
> 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.

Re: [9fans] speaking of kenc

[Lyndon Nerenberg]

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

Re: [9fans] speaking of kenc

[erik quanstrom]

> 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

Re: [9fans] speaking of kenc

[Roman Shaposhnick]

On Thu, 2007-05-03 at 22:00 -0400, erik quanstrom wrote:
> > 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.

Re: [9fans] speaking of kenc

[Lyndon Nerenberg]

>  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

Re: [9fans] speaking of kenc

[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

On Thu May  3 22:08:53 EDT 2007, rvs@sun.com wrote:
>   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.
> 

Re: [9fans] speaking of kenc

[Roman Shaposhnick]

On Thu, 2007-05-03 at 19:12 -0700, Lyndon Nerenberg wrote:
> >  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.

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

Re: [9fans] speaking of kenc

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

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

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

>  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

Re: [9fans] speaking of kenc

[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

On 5/4/07, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> >> 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?
>
> > 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.
>
> > 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.
>
> >  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
>

Re: [9fans] speaking of kenc

[Douglas A. Gwyn]

"Roman Shaposhnick" <rvs@sun.com> wrote in message 
news:1178243111.16650.1826.camel@work.sfbay.sun.com...
> 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).

Re: [9fans] speaking of kenc

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

Re: [9fans] speaking of kenc

[erik quanstrom]

On Fri May  4 05:24:03 EDT 2007, forsyth@vitanuova.com wrote:
> 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.

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

Re: [9fans] speaking of kenc

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On May 4, 2007, at 2:24 AM, C H Forsyth wrote:
> 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.

> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFGO10jpJeHo/Fbu1wRAr9qAKDClCJTLbq/Ti0P1+YzyqBJIv7M8gCfRLdK
JZw4qdBKIx7LzoVSHFdb2dw=
=ey27
-----END PGP SIGNATURE-----

Re: [9fans] speaking of kenc

[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

Re: [9fans] speaking of kenc

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On May 4, 2007, at 2:58 PM, Dave Eckhardt wrote:
> 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).

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

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

> 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

>
> Dave Eckhardt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFGO7M1pJeHo/Fbu1wRAmFvAKDUlDdofVlXv30Lcf3xYPHN6ubX4QCfclYB
te5F+PL5KW2BiF+CvXzyuDQ=
=HTyI
-----END PGP SIGNATURE-----

Re: [9fans] speaking of kenc

[Roman Shaposhnick]

On Fri, 2007-05-04 at 08:46 +0000, Douglas A. Gwyn wrote:
> "Roman Shaposhnick" <rvs@sun.com> wrote in message 
> news:1178243111.16650.1826.camel@work.sfbay.sun.com...
> > 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!

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

Re: [9fans] speaking of kenc

[Roman Shaposhnick]

On Fri, 2007-05-04 at 16:53 +1000, Bruce Ellis wrote:
> isn't it bleeding obvious by now that asm is dumb.

  I don't think it is obvious, no. 

> a function call into something in a *.s file will do.

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

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

Re: [9fans] speaking of kenc

[Roman Shaposhnick]

On Thu, 2007-05-03 at 19:35 -0700, Lyndon Nerenberg wrote:
> >> 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.

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

Re: [9fans] speaking of kenc

[Bruce Ellis]

i meant it.

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

explain a simple case when you need it.

brucee

On 5/5/07, Roman Shaposhnick <rvs@sun.com> wrote:
> On Thu, 2007-05-03 at 19:35 -0700, Lyndon Nerenberg wrote:
> > >> 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.
>
> > > 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.
>
>

Re: [9fans] speaking of kenc

[lucio]

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

My limited understanding suggests that the optimisations you refer to:

>   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

Re: [9fans] speaking of kenc

[erik quanstrom]

On Sat May  5 01:14:24 EDT 2007, bruce.ellis@gmail.com wrote:
> 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

Re: [9fans] speaking of kenc

[lucio]

> 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

Re: [9fans] speaking of kenc

[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

On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > 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
>
>

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/5/07, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> i meant it.
>
> asm is gone, or should have been many years ago.
>
> explain a simple case when you need it.
>

seriously?

compiling c code. can you imagine a c compiler that does not translate
to asm first? or can you imagine porting a c compiler when you dont
have an assembler? do you want to be hand coding machine code in a
compiler's code generator? 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?

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> 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.

Re: [9fans] speaking of kenc

[W B Hacker]

Rogelio Serrano wrote:
> On 5/5/07, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> i meant it.
>>
>> asm is gone, or should have been many years ago.
>>
>> explain a simple case when you need it.
>>
> 
> seriously?
> 
> compiling c code. can you imagine a c compiler that does not translate
> to asm first? or can you imagine porting a c compiler when you dont
> have an assembler? do you want to be hand coding machine code in a
> compiler's code generator?

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

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

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

> or would you rather have the processor and hardware designers build in
> the language support in the hardware? how would you react if the
> hardware designers choice of language is different from yours?
> 

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

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

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

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

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

:-(

Bill

Re: [9fans] speaking of kenc

[erik quanstrom]

> 1 and 3 are not really that different, so you're down to two examples.
> C is OK for newer embedded systems (microcontrollers), older ones are
> what they are and ASM may well be the way to go.  But even there, ASM
> is often just the lazy way rather than the more economical way.

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

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

> I have a feeling brucee will point out that the gain in efficiency in
> using ASM is insufficient to justify the additional costs in
> complexity and error potential.

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

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

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

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

- erik

Re: [9fans] speaking of kenc

[erik quanstrom]

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

like ken's c compiler?

- erik

Re: [9fans] speaking of kenc

[W B Hacker]

erik quanstrom wrote:
>> 1 and 3 are not really that different, so you're down to two examples.
>> C is OK for newer embedded systems (microcontrollers), older ones are
>> what they are and ASM may well be the way to go.  But even there, ASM
>> is often just the lazy way rather than the more economical way.
> 
> perhaps you haven't programmed many microcontrollers.  usually the
> volumes are high and the per unit cost is very important so you end up
> with very simple parts with very little ram/flash.  the one i worked on
> earlier this year had low speed usb interface, 2 gp registers, 256 bytes of ram 
> and 4k of flash.
> 
> i found it easy enough to program in assembly, but i don't think you'd
> get very far with c.  i just don't think you could fit things into memory.

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

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

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

How 'lost' can you get in a teacup?

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

Bill


> 
>> I have a feeling brucee will point out that the gain in efficiency in
>> using ASM is insufficient to justify the additional costs in
>> complexity and error potential.
> 
> i don't understand the assumption that the only reason to use assembly is
> cycle efficiency. 

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

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

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

;-)

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

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

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

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

'puters are not so different.

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

Bill

Re: [9fans] speaking of kenc

[Rogelio Serrano]

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

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

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

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

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

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

Re: [9fans] speaking of kenc

[lucio]

>> 1 and 3 are not really that different, so you're down to two examples.
>> C is OK for newer embedded systems (microcontrollers), older ones are
>> what they are and ASM may well be the way to go.  But even there, ASM
>> is often just the lazy way rather than the more economical way.
> 
> perhaps you haven't programmed many microcontrollers.  usually the
> volumes are high and the per unit cost is very important so you end up
> with very simple parts with very little ram/flash.  the one i worked on
> earlier this year had low speed usb interface, 2 gp registers, 256 bytes of ram 
> and 4k of flash.
> 
Well, I look at the AVR and all I see is a form of "bloat" I could
have sold my mother-in-law (had I had one) for a few years back.  It
may not be the paragon of design forsyth would beg for, but it sure is
cheap and vast.  How much more it would cost than what you chose
instead is difficult to determine.  To me, it seems PIC users are the
masochists.

> i found it easy enough to program in assembly, but i don't think you'd
> get very far with c.  i just don't think you could fit things into memory.
> 
Oh, well, I recall a C compiler for the 8051...  Are you sure you
could drive a USB port in assembler?  It sounds ridiculously difficult
in C, to my mind.  And, for the record, I do enjoy the challenge of
tight assembler coding, but more like I enjoy running a middle
distance than as a means to an end.

>> I have a feeling brucee will point out that the gain in efficiency in
>> using ASM is insufficient to justify the additional costs in
>> complexity and error potential.
> 
> i don't understand the assumption that the only reason to use assembly is
> cycle efficiency. 
> 
> also, could you explain why this is "lazy"? or why assembly is more
> complicated?
> 
Because it's very thin.  You have thousands of instructions to keep
track of, some of which are not exactly the ones you ought to have
used.  Because inverting a test is sometimes not as obvious as you
think (not everyone knows the instruction set backwards) and, most
importantly, because all the "clever" optimisations you added are
utterly incomprehensible to the poor sod that comes along to debug or
alter your code.  I was tought a long time ago that the most important
feature of good programming is readability and assembler certainly has
none of that built into it.

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

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

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

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

++L

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, erik quanstrom <quanstro@coraid.com> wrote:

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

exactly.

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

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, Rogelio Serrano <rogelio.serrano@gmail.com> wrote:
> On 5/6/07, erik quanstrom <quanstro@coraid.com> wrote:
>
> >
> > this absolutist argument that c is teh bomb. asm suks is silly.  it's like
> > arguing bicycles and ferraris.  which one you need (and which one gets
> > you there faster) depends on what you're doing.
> >
>
> exactly.
>
> assembler is there because it is needed. if you are writing or porting
> a compiler and you dont have an assembler you will end up writing one
> anyway.
>

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

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

Re: [9fans] speaking of kenc

[W B Hacker]

erik quanstrom wrote:
>> 1 and 3 are not really that different, so you're down to two examples.
>> C is OK for newer embedded systems (microcontrollers), older ones are
>> what they are and ASM may well be the way to go.  But even there, ASM
>> is often just the lazy way rather than the more economical way.
> 
> perhaps you haven't programmed many microcontrollers.  usually the
> volumes are high and the per unit cost is very important so you end up
> with very simple parts with very little ram/flash.  the one i worked on
> earlier this year had low speed usb interface, 2 gp registers, 256 bytes of ram 
> and 4k of flash.
> 
> i found it easy enough to program in assembly, but i don't think you'd
> get very far with c.  i just don't think you could fit things into memory.

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

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

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

How 'lost' can you get in a teacup?

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

Bill


> 
>> I have a feeling brucee will point out that the gain in efficiency in
>> using ASM is insufficient to justify the additional costs in
>> complexity and error potential.
> 
> i don't understand the assumption that the only reason to use assembly is
> cycle efficiency. 

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

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

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

;-)

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

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

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

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

'puters are not so different.

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

Bill

Re: [9fans] speaking of kenc

[lucio]

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

Re: [9fans] speaking of kenc

[lucio]

> 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

Re: [9fans] speaking of kenc

[lucio]

> 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

Re: [9fans] speaking of kenc

[W B Hacker]

Rogelio Serrano wrote:
> On 5/6/07, erik quanstrom <quanstro@coraid.com> wrote:
> 
>>
>> this absolutist argument that c is teh bomb. asm suks is silly.  it's 
>> like
>> arguing bicycles and ferraris.  which one you need (and which one gets
>> you there faster) depends on what you're doing.
>>
> 
> exactly.
> 
> assembler is there because it is needed. if you are writing or porting
> a compiler and you dont have an assembler you will end up writing one
> anyway.
> 
  ... OR machine-coding the 'primitives' for your own virtual-machine to obviate
the need for having to worry about it at all.

Forth directly on hardware 'then'.

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

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

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

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

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

;-)


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

Bill

Re: [9fans] speaking of kenc

[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

On 5/6/07, Rogelio Serrano <rogelio.serrano@gmail.com> wrote:
> On 5/5/07, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> > i meant it.
> >
> > asm is gone, or should have been many years ago.
> >
> > explain a simple case when you need it.
> >
>
> seriously?
>
> compiling c code. can you imagine a c compiler that does not translate
> to asm first?

Re: [9fans] speaking of kenc

[lucio]

>> i found it easy enough to program in assembly, but i don't think you'd
>> get very far with c.  i just don't think you could fit things into memory.
> 
> Well 'C compiler hosted on a larger machine, and with that one as a binary
> target' will no doubt come back from someone. And that isn't wrong.

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

But is that where we're all going?

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

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

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

++L

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

Re: [9fans] speaking of kenc

[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

On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > besides, its so easy to write one.
> > provided you have the instruction set manuals.
>
> Oh, yeah?  For the Intel x86 series?  Across all its instruction sets,
> emulation modes and addressing modes?  How long do you think it will
> take you?  And what language would you write in?  On what platform?
>
> ++L
>
>

Re: [9fans] speaking of kenc

[Skip Tavakkolian]

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

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

for microcontrollers, there are choices like forth.

> On 5/6/07, Rogelio Serrano <rogelio.serrano@gmail.com> wrote:
>> On 5/6/07, erik quanstrom <quanstro@coraid.com> wrote:
>>
>> >
>> > this absolutist argument that c is teh bomb. asm suks is silly.  it's like
>> > arguing bicycles and ferraris.  which one you need (and which one gets
>> > you there faster) depends on what you're doing.
>> >
>>
>> exactly.
>>
>> assembler is there because it is needed. if you are writing or porting
>> a compiler and you dont have an assembler you will end up writing one
>> anyway.
>>
> 
> besides, its so easy to write one.
> provided you have the instruction set manuals.
> 
> -- 
> the thing i like with my linux pc is that i can sum up my complaints in 5 items

Re: [9fans] speaking of kenc

[W B Hacker]

lucio@proxima.alt.za wrote:

*snip*

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

Well...

'C' *has* had an inordinately long run, and that has not always pleased even its 
creators. No tool remains 'good enough' forever, let alone 'best and only'.

Similarly, Plan9 itself seems to have gone from bleeding edge to minor sideshow 
without much time on stage in between.

Speaking of respect, admiration, use as a source of inspiration, partial 
emulation - not of 'popularity', per se. A Loonix 'distro' it is not.

UTF-8 - for which I am very grateful, seems to be the most visible and enduring 
contribution, and few who depedn on it are even aware that it was Plan9 related.

Maybe it is again time to do something new and shed another round of baggage - 
even if it is not HP Maxim's '.. whole nine yards'.

Available CPU power is astonishing nowadays. More than we can actually put to 
work on personal task if not 'servicing' (as in animal husbandry) MS Orifice and 
their parasites.


How about a voice-driven, speaker-independent human-machine interface?

Demonstrated, and quite well, even with Mandarin, by IBM on a mainframe no more 
powerful THEN than commodity CPU and aoofrdable RAM are NOW.

A natural for remote 'plumbing' over a 'net.  Speech bandwidth need is really 
small compared to VNC or large file transfer for local manipulation when all ou 
want is the *answer* the human PA we can no longer afford to emply coudl have 
gotten for you.

Hands free, and surely beats hell out of those itty-bitty keypads... could even 
make acme/rio paging model finally make sense...

Computer voice:  <selectable size chunk of speach output>.

user's voice: ['more' | 'repeat' | 'end' | 'next' | 'new'| 'snarf']

;-)

.. hmm  .. or was Plan9 involved in AT&T automated attendant / directory service 
interfaces in the first place?

... seems a natural fit to the networking model.

Bill

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> >> i found it easy enough to program in assembly, but i don't think you'd
> >> get very far with c.  i just don't think you could fit things into memory.
> >
> > Well 'C compiler hosted on a larger machine, and with that one as a binary
> > target' will no doubt come back from someone. And that isn't wrong.
>

cross compilation is more important than ever.

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

i dont think we want to regress.

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

i agree up to a point.

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

i agree.

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

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

Re: [9fans] speaking of kenc

[W B Hacker]

lucio@proxima.alt.za wrote:

*snip*

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

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

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

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

Bill

Re: [9fans] speaking of kenc

[W B Hacker]

Rogelio Serrano wrote:

*snip*

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

^even^

> they resisted it.

And well they should!

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

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

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

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

Bill

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > besides, its so easy to write one.
> > provided you have the instruction set manuals.
>
> Oh, yeah?  For the Intel x86 series?  Across all its instruction sets,
> emulation modes and addressing modes?  How long do you think it will
> take you?  And what language would you write in?  On what platform?
>
> ++L
>
>

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

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

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

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

Re: [9fans] speaking of kenc

[Rogelio Serrano]

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

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

your point?

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

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

you want to start tinkering with fpgas?

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

Re: [9fans] speaking of kenc

[lucio]

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

This has puzzled me for years.  Why are processors designed by
engineers who seem to have no software understanding?

Is it the same reason that only car manufactures dictate car design?
And is it auspicious that others are entering the arena with new
ideas?  Or are desktop computers doomed to run Wintel for ever?

++L

Re: [9fans] speaking of kenc

[lucio]

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

Not easier, but at least you can escape the constraints laid down by
the designer, in that only the code generator implementor needs to be
burdened by them.  I'm sure the code generator can be impossibly
difficult to get right, but you gain the ability to optimise as Plan 9
C's compiler suite does.  You are hardly likely to do so in a straight
assembler.

++L

Re: [9fans] speaking of kenc

[W B Hacker]

Rogelio Serrano wrote:
> On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
>> > besides, its so easy to write one.
>> > provided you have the instruction set manuals.
>>
>> Oh, yeah?  For the Intel x86 series?  Across all its instruction sets,
>> emulation modes and addressing modes?  How long do you think it will
>> take you?  And what language would you write in?  On what platform?
>>
>> ++L
>>
>>
> 
> yes. and is it easier if you build it into the code generator? the
> designers actually dont give you a choice.
> 
> i wrote an assembler as a testing tool for the code generator. in the
> end i just refactored the assembler into the code generator. i just
> coded for a small subset that is needed.
> 
> the root of all this evil is the designer of the processor. can we
> make them change their ways? not until we start designing our own.
>

Be fair - they have to make optimization choices also.

And some coders have done just that. Chuck Moore and the forth chipset.
Others since. Not enough was gained to prevail.

First off, most such ended up dog-slow. After all, a binary ordinarily needs to 
be compiled ONCE, and the chipset could give a Massatwoshits with what language 
or toolset.

likewise, though it's hard to sidestep the x86 'inertia', it IS happening.

Look at the ARM, to name just one example.
And mobile devices and STB's are a *huge* market - hence there is money available.

Meanwhile, Google is 'enabling' solutions that need less local power or storage, 
and they are by no means alone.

A major paradigm shift is underway - much of it toward the very environment 
Plan9 envisioned. Regardless of language.

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

C'mon! FedEx, postal service, or pack mule don't reach your corner of the globe?

Ability to post here says you can place an order.

Bill

Re: [9fans] speaking of kenc

[lucio]

> On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> 
>>
>> You may not have noticed, as it is no longer a popular approach, that
>> earlier Unixes provided innumerable tools to generate C code.  So much
>> so that the "goto" was retained more to make such code generation
>> easier than to please a handful of spoiled programmers.
>>
> 
> your point?
> 
That C and not assembler ought to be the target language, no matter
the application.  That assembler is deprecated in favour of C.

++L

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> 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.
>

i think ken is clever enough to use mnemonics. how different is that
from assembly?

can you work with this?

 89 e5 83 ec 08 e8 a9 00 00 00 e8 00 01 00 00 e8 9b 1c 00 00 c9 c3

believe me i did. debugging a pl/0 code generator.

ok ken cc is a single pass compiler. there is no assembly anywhere.
not even in internal buffers.

Re: [9fans] speaking of kenc

[W B Hacker]

Rogelio Serrano wrote:

*snip*

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

Actually it is damned hard to create a processor that *is* 'locked' to any 
language more complex than high/low/tristate tables.

I'd dare say 'couldn't be done' were it not for Pershing's quote.

What it *does* with those states, is of course what we have come to call an 
'instruction set', if that is what you really meant by 'language'.

And there are such - including some x86 compatibles - where portions of that can 
be altered without a major fab change.

For most use, the trend has been exaclty the other way. Folks prefer a 
guaranteed-stable environment, even if it is a suboptimal one (x86 
'compatibility' again).

Mostly it is about costs - not 'elegance' or convenience for the coder.

We've got to 'eat what is on our plate'.

Bill

Re: [9fans] speaking of kenc

[W B Hacker]

lucio@proxima.alt.za wrote:
>> On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
>>
>>> You may not have noticed, as it is no longer a popular approach, that
>>> earlier Unixes provided innumerable tools to generate C code.  So much
>>> so that the "goto" was retained more to make such code generation
>>> easier than to please a handful of spoiled programmers.
>>>
>> your point?
>>
> That C and not assembler ought to be the target language, no matter
> the application.  That assembler is deprecated in favour of C.
> 
> ++L
> 
> 

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

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

Not even for biologicals with billion+ year history.

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

Bill

Re: [9fans] speaking of kenc

[lucio]

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

Brucee slipped, although he did say that the assembler code is in the
libraries:

	term% du -a /n/sources/plan9/sys/src/cmd | grep '\.s$'
	10	/n/sources/plan9/sys/src/cmd/2a/l.s
	1	/n/sources/plan9/sys/src/cmd/5a/l.s
	1	/n/sources/plan9/sys/src/cmd/5l/l.s
	13	/n/sources/plan9/sys/src/cmd/8a/l.s
	14	/n/sources/plan9/sys/src/cmd/ka/l.s
	1	/n/sources/plan9/sys/src/cmd/unix/drawterm/posix-mips/tas.s
	1	/n/sources/plan9/sys/src/cmd/unix/drawterm/posix-sun4u/tas.s
	13	/n/sources/plan9/sys/src/cmd/va/l.s
	10	/n/sources/plan9/sys/src/cmd/1a/l.s

That is it.

++L

Re: [9fans] speaking of kenc

[Rogelio Serrano]

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > yes. and is it easier if you build it into the code generator? the
> > designers actually dont give you a choice.
>
> Not easier, but at least you can escape the constraints laid down by
> the designer, in that only the code generator implementor needs to be
> burdened by them.  I'm sure the code generator can be impossibly
> difficult to get right, but you gain the ability to optimise as Plan 9
> C's compiler suite does.  You are hardly likely to do so in a straight
> assembler.
>
> ++L
>
>

assmebler has its place. for a code generator writer it is necessary
even as an intermediate step. for the rest of us it has no use.

with the massively parallel processors with high very IPC like the one
im simulating, assembler is just that. a testing tool.

Re: [9fans] speaking of kenc

[lucio]

>> That C and not assembler ought to be the target language, no matter
>> the application.  That assembler is deprecated in favour of C.
> 
> If that ever comes to pass, I'm going back to a wire-wrap tool.
> 
I don't see why.  I did post the sum-total of assembler coding in the
Plan 9 source directory, libraries and kernel code excluded.  Has that
sent you back to the wire-wrap tool yet?

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

> There *can be no* one-size fits-all final answers unless and until all progress 
> is to be called off and stagnation and decline to the death are mandated from 
> on-high.
> 
That is a view from an uncommon position.  It so happens that our
brain can "evolve" much more rapidly than any other organism, with
mutations occurring on a very small timescale.  But that perspective
is unique to that particular condition.  And one can philosophise on
how useful this continuous mutation really is.

> Not even for biologicals with billion+ year history.
> 
Ever wondered how old the nearest amoeba is?  From his point of view,
we're just a passing phase :-)

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

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

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

++L

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, W B Hacker <wbh@conducive.org> wrote:
> Rogelio Serrano wrote:
> > On 5/6/07, erik quanstrom <quanstro@coraid.com> wrote:
> >
> >>
> >> this absolutist argument that c is teh bomb. asm suks is silly.  it's
> >> like
> >> arguing bicycles and ferraris.  which one you need (and which one gets
> >> you there faster) depends on what you're doing.
> >>
> >
> > exactly.
> >
> > assembler is there because it is needed. if you are writing or porting
> > a compiler and you dont have an assembler you will end up writing one
> > anyway.
> >
>   ... OR machine-coding the 'primitives' for your own virtual-machine to obviate
> the need for having to worry about it at all.
>

i see. theres a good idea there somewhere. some sort of vm... highly optimised.

well it can be done. but to abstract all hardware, not possible. it
will be very complicated and dog slow.

Re: [9fans] speaking of kenc

[W B Hacker]

Rogelio Serrano wrote:
> On 5/6/07, W B Hacker <wbh@conducive.org> wrote:

*snip*

>>
>> If that ever comes to pass, I'm going back to a wire-wrap tool.
> 
> no kidding! wire wrap is still a nice technology for protoyping! try
> developing a 6 layer backplane pcb.

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

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

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

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

;-)

Bill

Re: [9fans] speaking of kenc

[lucio]

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

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

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

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

++L

Re: [9fans] speaking of kenc

[W B Hacker]

Rogelio Serrano wrote:
> On 5/6/07, W B Hacker <wbh@conducive.org> wrote:

*snip*

>> >
>>   ... OR machine-coding the 'primitives' for your own virtual-machine 
>> to obviate
>> the need for having to worry about it at all.
>>
> 
> i see. theres a good idea there somewhere. some sort of vm... highly 
> optimised.
> 
> well it can be done. but to abstract all hardware, not possible. it
> will be very complicated and dog slow.
> 

Seems otherwise. See Xen, Qemu, VMware, L4 & descendents, Inferno - not to 
mention the long-running won't die revenue king of them all IBM's MV/VM.

And 'abstract all' needs a virtual dual-ported area of RAM set aside and mapped 
where it has to be, interrupt handlign to go - not too much else.
Dangerous in the 'wrong hands' but simple enough. or see what DragonFly is doing 
w/r hand offs for so-far-native-DFLY-only virtual kernels. There may be soem 
meat on that bone.

Only a few of these get at all close to the hardware, yet the speed for the best 
of  them (seldom the same answer in every environment) is more than 'good 
enough' to do a great deal of useful thigs - devel at the head of the list.

I daresay there are few folks here who have not used them or come to appreciate 
them as time-savers vs rebooting 'hardware' native installs.

Even so - hardware doesn't *necesarily* have to change - multicore and privilege 
separation are fairly recent additions to commodity (x86/AMD) silicon and by no 
means fully utilized by all comers.

So there *could* be more of these written to run as direct 'native' hosts, and 
probably will be...

But that doesn't really change the asm / C / whatever 'need set'.

Just lets it be buried a little deeper under the covers.

Still no one-size fits all, though.

Bill

Re: [9fans] speaking of kenc

[lucio]

> well it can be done. but to abstract all hardware, not possible. it
> will be very complicated and dog slow.

That's relative.  Vista is dog-slow, if what I hear is anything to go
by.  Does that put anyone off?

I ought to point you to XYwrite II, the first "word processor" I used
on the PC. I think you need to run it on a 4.7 MHz processor to
appreciate how fast it was, on modern hardware it would be hard to
realise that there is plenty untapped performance behind the scenes.

Speed is there to be consumed, the fashion is to (ab)use it for
eye-candy and multimedia.  Thing is, the decision makers are those
with the full wallet and they can manipulate the market.  The loser is
the innovation that is the daughter of necessity.  But that is another
subject altogether.

++L

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, W B Hacker <wbh@conducive.org> wrote:
> Rogelio Serrano wrote:
> > On 5/6/07, W B Hacker <wbh@conducive.org> wrote:
>
> *snip*
>
> >> >
> >>   ... OR machine-coding the 'primitives' for your own virtual-machine
> >> to obviate
> >> the need for having to worry about it at all.
> >>
> >
> > i see. theres a good idea there somewhere. some sort of vm... highly
> > optimised.
> >
> > well it can be done. but to abstract all hardware, not possible. it
> > will be very complicated and dog slow.
> >
>
> Seems otherwise. See Xen, Qemu, VMware, L4 & descendents, Inferno - not to
> mention the long-running won't die revenue king of them all IBM's MV/VM.
>
> And 'abstract all' needs a virtual dual-ported area of RAM set aside and mapped
> where it has to be, interrupt handlign to go - not too much else.
> Dangerous in the 'wrong hands' but simple enough. or see what DragonFly is doing
> w/r hand offs for so-far-native-DFLY-only virtual kernels. There may be soem
> meat on that bone.
>

i see. it does not need to be as big as that actually. just enough to
avoid writing x86 assembler. and that "blob" can be written using a c
programmer and then generate object code that can be "linked" to the
kernel. well what im writing is more of an "event core". there is no
kernel actually. but the event core without assembly, generated from
machine definitions is a good idea actually.

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > im talking from the kernel writer point of view. and im most familiar
> > with the x86. c assumes there is a system already running. and most
> > probably that system is brought up using assembly coded initialization
> > code.
>
> No one said that assembler is obsolete, only deprecated.  Like many
> "we have always done it this way" paradigms, it dies hard and it is
> difficult to persuade "aficionados" that they would be better off
> programming at a higher level and reserve their skills for those rare
> occasions where they are ahead of the compilers or, as you rightly
> point out, where there are no alternatives, such as in setting up the
> stack or posting a kernel trap.
>

i see.

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

of course not. its a bitch to optimize.

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

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > well it can be done. but to abstract all hardware, not possible. it
> > will be very complicated and dog slow.
>
> That's relative.  Vista is dog-slow, if what I hear is anything to go
> by.  Does that put anyone off?
>

slow not really. but complicated yes, that puts me off.

> I ought to point you to XYwrite II, the first "word processor" I used
> on the PC. I think you need to run it on a 4.7 MHz processor to
> appreciate how fast it was, on modern hardware it would be hard to
> realise that there is plenty untapped performance behind the scenes.

i understand.

im not a fan of eye candy either and i like fast low cost systems that
do what we want them to do.

Re: [9fans] speaking of kenc

[matt]

>
>
> Similarly, Plan9 itself seems to have gone from bleeding edge to minor 
> sideshow without much time on stage in between.


There are Plan 9 ideas scattered around the Lunix world. Many more will 
come.
You talk as if it is all over.

Re: [9fans] speaking of kenc

[W B Hacker]

lucio@proxima.alt.za wrote:
>>> That C and not assembler ought to be the target language, no matter
>>> the application.  That assembler is deprecated in favour of C.
>> If that ever comes to pass, I'm going back to a wire-wrap tool.
>>
> I don't see why.  I did post the sum-total of assembler coding in the
> Plan 9 source directory, libraries and kernel code excluded.  Has that
> sent you back to the wire-wrap tool yet?

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

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

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

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

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

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

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

>> There *can be no* one-size fits-all final answers unless and until all progress 
>> is to be called off and stagnation and decline to the death are mandated from 
>> on-high.
>>
> That is a view from an uncommon position.  It so happens that our
> brain can "evolve" much more rapidly than any other organism, with
> mutations occurring on a very small timescale.  But that perspective
> is unique to that particular condition.  And one can philosophise on
> how useful this continuous mutation really is.
> 
>> Not even for biologicals with billion+ year history.
>>
> Ever wondered how old the nearest amoeba is?  From his point of view,
> we're just a passing phase :-)

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

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

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

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

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

;-)

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

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

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

Inertia cuts both ways.

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

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

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

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

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

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

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

So 'genius'?

At the time, perhaps.

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

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

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

Bill

Re: [9fans] speaking of kenc

[W B Hacker]

Rogelio Serrano wrote:
> On 5/6/07, W B Hacker <wbh@conducive.org> wrote:
>> Rogelio Serrano wrote:
>> > On 5/6/07, W B Hacker <wbh@conducive.org> wrote:
>>
>> *snip*
>>
>> >> >
>> >>   ... OR machine-coding the 'primitives' for your own virtual-machine
>> >> to obviate
>> >> the need for having to worry about it at all.
>> >>
>> >
>> > i see. theres a good idea there somewhere. some sort of vm... highly
>> > optimised.
>> >
>> > well it can be done. but to abstract all hardware, not possible. it
>> > will be very complicated and dog slow.
>> >
>>
>> Seems otherwise. See Xen, Qemu, VMware, L4 & descendents, Inferno - 
>> not to
>> mention the long-running won't die revenue king of them all IBM's MV/VM.
>>
>> And 'abstract all' needs a virtual dual-ported area of RAM set aside 
>> and mapped
>> where it has to be, interrupt handlign to go - not too much else.
>> Dangerous in the 'wrong hands' but simple enough. or see what 
>> DragonFly is doing
>> w/r hand offs for so-far-native-DFLY-only virtual kernels. There may 
>> be soem
>> meat on that bone.
>>
> 
> i see. it does not need to be as big as that actually. just enough to
> avoid writing x86 assembler. and that "blob" can be written using a c
> programmer and then generate object code that can be "linked" to the
> kernel. well what im writing is more of an "event core". there is no
> kernel actually. but the event core without assembly, generated from
> machine definitions is a good idea actually.
> 

You night also have a look at the latest incarnation of Minix. 4,000 lines of 
code for the kernel?

May be meat on *that* bone as well...

Bill

Re: [9fans] speaking of kenc

[W B Hacker]

lucio@proxima.alt.za wrote:
>> well it can be done. but to abstract all hardware, not possible. it
>> will be very complicated and dog slow.
> 
> That's relative.  Vista is dog-slow, if what I hear is anything to go
> by.  Does that put anyone off?
> 
> I ought to point you to XYwrite II, the first "word processor" I used
> on the PC.

I should dig out my copy and try it. Or Vedit or PeachCalc (x80 Visicalc clone).

RBase for DOS is another one.

Pretty much lives entirely in the L1 cache of a modern Core-D.
Work that took 15 miutes on a 386-20 is too fast to bother measuring.

In the OTHER direction, Netscape for OS/2 used to open in 2 seconds from cold 
SCSI cache, 2/10's of a second from warm on a K6-500, ASUS DA-2100, 20 MB/s SCSI 
drives.

Now SeaMonkey takes over twice that on Core-D 2.8 GHz, 2G DDR2, SATA 3.

And OpenOffice?  Begone!

 > I think you need to run it on a 4.7 MHz processor to
> appreciate how fast it was, on modern hardware it would be hard to
> realise that there is plenty untapped performance behind the scenes.
> 

See 'Menuet' for a quick desktop.  Written in asm, BTW.
"never say die..."

> Speed is there to be consumed, the fashion is to (ab)use it for
> eye-candy and multimedia.  Thing is, the decision makers are those
> with the full wallet and they can manipulate the market.  The loser is
> the innovation that is the daughter of necessity.  But that is another
> subject altogether.
> 
> ++L
> 
>

Ack - we should probably all hit the showers now.

Been enlightening to get some of these viewpoints aired.
I'm glad to find that not ALL 9Fans are Luddites, anyway...

(ducks and waddles off, pun 'inlined'...)

Bill

Re: [9fans] speaking of kenc

[matt]

 > slow not really

I don't know what sort of metric you are using but whatever it is, it's 
wrong.

My PC has gone from 20,000,000hz to 3,000,000,000hz in 10 years.

How does Vista boot to GUI compare to Win3.1 ?

To say Vista/OSX/Lunix are not slow is outrageously naive!

and for all you asm arguers I say : Windows 3.x, where would we be 
without it's asm goodness !

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, W B Hacker <wbh@conducive.org> wrote:

> > oh right i could just buy a non-x86 non-pc system. like i can find any
> > within 1k km where i live.
> >
>
> C'mon! FedEx, postal service, or pack mule don't reach your corner of the globe?
>
> Ability to post here says you can place an order.
>

heh heh you got me!

efika from genesi is only 166 usd for the motherboard.

but fedex effectively doubles my cost. dont know about pack mule...

> Bill
>
>
>
>


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

Re: [9fans] speaking of kenc

[Rogelio Serrano]

On 5/6/07, matt <mattmobile@proweb.co.uk> wrote:
>  > slow not really
>
> I don't know what sort of metric you are using but whatever it is, it's
> wrong.
>

i was not saying/claiming that any os is slow.

> My PC has gone from 20,000,000hz to 3,000,000,000hz in 10 years.
>
> How does Vista boot to GUI compare to Win3.1 ?
>
> To say Vista/OSX/Lunix are not slow is outrageously naive!
>

they are slow. one is even slower than the other but i can live with it.

> and for all you asm arguers I say : Windows 3.x, where would we be
> without it's asm goodness !
>



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

Re: [9fans] speaking of kenc

[Bruce Ellis]

have a look at the listed l.s files ... test files!

On 5/6/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > i think this has gone off track.  i read brucee's original post as an
> > argument against polluting c with asm()/__asm{}.  obviously there is
> > asm in the plan9 distro; try du -a /sys/src| grep '\.s$' . for which
> > it uses /sys/doc/asm.ps
>
> Brucee slipped, although he did say that the assembler code is in the
> libraries:
>
>        term% du -a /n/sources/plan9/sys/src/cmd | grep '\.s$'
>        10      /n/sources/plan9/sys/src/cmd/2a/l.s
>        1       /n/sources/plan9/sys/src/cmd/5a/l.s
>        1       /n/sources/plan9/sys/src/cmd/5l/l.s
>        13      /n/sources/plan9/sys/src/cmd/8a/l.s
>        14      /n/sources/plan9/sys/src/cmd/ka/l.s
>        1       /n/sources/plan9/sys/src/cmd/unix/drawterm/posix-mips/tas.s
>        1       /n/sources/plan9/sys/src/cmd/unix/drawterm/posix-sun4u/tas.s
>        13      /n/sources/plan9/sys/src/cmd/va/l.s
>        10      /n/sources/plan9/sys/src/cmd/1a/l.s
>
> That is it.
>
> ++L
>
>

Re: [9fans] speaking of kenc

[Richard Miller]

> The
> transputer had no assembly.

Not qute true actually.

The inmos occam compiler for the transputer did have an inline
assembly language construct.  But this quote from my copy of the
Transputer Development System manual (1988) shows its use was not
encouraged.  Note the implication that the machine language should
only be of interest to compiler writers ...

"The code insertion mechanism enables the user to access the
instruction set of the transputer directly within the framework of an
occam program.  Symbolic access to occam variable names is supported,
as is automatic jump sizing.  More details on the instruction set may
be found in the INMOS document 'The transputer instruction set -- a
compiler writer's guide'. 

"Code insertion may be employed to perform tasks not possible from
occam, or for particularly time-critical sections of a program.  There
are several reasons, however, which should encourage the user to
refrain from using code insertion as a solution to problems which may,
with some thought, be solved using occam.  Paramount among these is
that the validity of a system consisting entirely of occam can be
checked by the compiler.  A compiler can check usage of channels,
access to variables, communications protocols and range violations.  A
single code insert prevents the compiler from performing these checks
adequately.  A second reason for not using code insertions is that the
transputer instruction set is suited for use by a high level language,
particularly occam, and algorithms which are simple to code and easy
to debug in occam become difficult and obscure when coded in the
transputer instruction set directly."

Re: [9fans] speaking of kenc

[Roman Shaposhnik]

On Sun, 2007-05-06 at 14:18 +0100, Richard Miller wrote:
> > The
> > transputer had no assembly.
> 
> Not qute true actually.
> 
> The inmos occam compiler for the transputer did have an inline
> assembly language construct.  But this quote from my copy of the
> Transputer Development System manual (1988) shows its use was not
> encouraged.  Note the implication that the machine language should
> only be of interest to compiler writers ...
> 
> "The code insertion mechanism enables the user to access the
> instruction set of the transputer directly within the framework of an
> occam program.  Symbolic access to occam variable names is supported,
> as is automatic jump sizing.  More details on the instruction set may
> be found in the INMOS document 'The transputer instruction set -- a
> compiler writer's guide'. 
> 
> "Code insertion may be employed to perform tasks not possible from
> occam, or for particularly time-critical sections of a program.  There
> are several reasons, however, which should encourage the user to
> refrain from using code insertion as a solution to problems which may,
> with some thought, be solved using occam.  Paramount among these is
> that the validity of a system consisting entirely of occam can be
> checked by the compiler.  A compiler can check usage of channels,
> access to variables, communications protocols and range violations.  A
> single code insert prevents the compiler from performing these checks
> adequately.  A second reason for not using code insertions is that the
> transputer instruction set is suited for use by a high level language,
> particularly occam, and algorithms which are simple to code and easy
> to debug in occam become difficult and obscure when coded in the
> transputer instruction set directly."

  The above sounds very appropriate. Note, that given a proper mechanism
for creating asm-based intrinsic routines and also a proper mechanism
for inlining them -- we can have a very attractive solution to the
asm problem in C language as well. From that vantage point, GNU __asm
inlines surely seem like an overkill.  

Thanks,
Roman.

Re: [9fans] speaking of kenc

[Roman Shaposhnik]

On Sun, 2007-05-06 at 00:08 -0400, erik quanstrom wrote:
> 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.

  I think I would like to run with this analogy for a little while
longer. I happen to like it. You see, what I'm asking for is far
from passing a final judgment. What I'm asking for is a special 
kind of bike that I can store in my Ferrari somehow and use it
on those special occasions when I'm really stuck someplace. I happen
to like the analogy because as much as Ferrari is not the type of
car that would land itself easily to any kind of roof rails 
or roof racks C language is the same way.

Thanks,
Roman.

Re: [9fans] speaking of kenc

[Roman Shaposhnik]

On Sat, 2007-05-05 at 23:04 -0700, Skip Tavakkolian wrote:
> i think this has gone off track. 

  ain't that the fun? ;-)

>  i read brucee's original post as an
> argument against polluting c with asm()/__asm{}. 

  As always -- brucee is articulating a point that reminds me
of paternalistic, patronizing laws. Look, CPUs are giving me
a particular language and C doesn't cover all of it. Brucee
tells us: tough luck -- you can't have that richer vocabulary, 
I say we need to think of something that lets us tap into that 
pool of extra words. And yes some of them can be dirty words,
but even they are REALLY needed from time to time. I dislike
potty mouths as much as the next guy (and GCC __asm is way 
too potty for my taste) but I can really appreciate a fine
use of F2K words(*).  

Thanks,
Roman.

(*) there's probably a connection between this statement and
the fact that Russian is one of the languages where F2K
vocabulary is REALLY rich ;-)

Re: [9fans] speaking of kenc

[Roman Shaposhnik]

On Sun, 2007-05-06 at 07:12 +0200, lucio@proxima.alt.za wrote:
> > 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. 
 
  I think I would agree with this point 100%. 

Thanks,
Roman.

Re: [9fans] speaking of kenc

[W B Hacker]

Roman Shaposhnik wrote:
> On Sun, 2007-05-06 at 07:12 +0200, lucio@proxima.alt.za wrote:
>>> 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. 
>  
>   I think I would agree with this point 100%. 
> 
> Thanks,
> Roman.
> 
> 

Designers work in binary gate-array state tables.

Not much choice until CPU go over to optical, and can *maybe* use UTF-8 directly 
as I/O in color frequency coding as well as simple on/off states.

Even then only at a hefty price.

Until then, asm's mnemonics are easier for humans to work with than octal, hex, 
or binary, and there isn't much to be done about that IF/AS/WHEN you absolutely, 
positively, *have to* get down to the lowest possible layer and find a 
binary-only animal at that layer.

Fortunately, that 'have to' is 'damn seldom' thanks to a wide variety of 
toolsets, and those who do it often are no more fussed about doing it than 
having a different brand of beer now and then.

Build a CPU that 'needs no assembler' and the first thing that happens is some 
contrarian will write one for it *anyway*. And/OR port forth to it.

And they will be used. But never 'forced'.

That because the second contrarian who arrives will port a 'C' compiler to it.

Any of these can be labelled ugly or inelegant - but they are the tools that get 
the job done faster than most other choices.

And time - wall clock, CPU, or hours of our lives - is not just money.

Time is the scarcest, and least 'renewable' resource any of us will ever have.

So we must adapt to what we have while we invent better machines.

When machines start to adapt to US, we should become very, very wary, 'coz they 
will have become smarter than we are, and they will also have become either 
certifiably insane to make the attempt or clever liars to fake it.

Can't trust either of those to keep a beer keg cold...

Choices, folks.  Choices!

Bill

Re: [9fans] speaking of kenc

[Tim Wiess]

fascinating.
could you please continue this thread off the list now?
thanks.


> Roman Shaposhnik wrote:
>> On Sun, 2007-05-06 at 07:12 +0200, lucio@proxima.alt.za wrote:
>>>> 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. 
>>  
>>   I think I would agree with this point 100%. 
>> 
>> Thanks,
>> Roman.
>> 
>> 
> 
> Designers work in binary gate-array state tables.
> 
> Not much choice until CPU go over to optical, and can *maybe* use UTF-8 directly 
> as I/O in color frequency coding as well as simple on/off states.
> 
> Even then only at a hefty price.
> 
> Until then, asm's mnemonics are easier for humans to work with than octal, hex, 
> or binary, and there isn't much to be done about that IF/AS/WHEN you absolutely, 
> positively, *have to* get down to the lowest possible layer and find a 
> binary-only animal at that layer.
> 
> Fortunately, that 'have to' is 'damn seldom' thanks to a wide variety of 
> toolsets, and those who do it often are no more fussed about doing it than 
> having a different brand of beer now and then.
> 
> Build a CPU that 'needs no assembler' and the first thing that happens is some 
> contrarian will write one for it *anyway*. And/OR port forth to it.
> 
> And they will be used. But never 'forced'.
> 
> That because the second contrarian who arrives will port a 'C' compiler to it.
> 
> Any of these can be labelled ugly or inelegant - but they are the tools that get 
> the job done faster than most other choices.
> 
> And time - wall clock, CPU, or hours of our lives - is not just money.
> 
> Time is the scarcest, and least 'renewable' resource any of us will ever have.
> 
> So we must adapt to what we have while we invent better machines.
> 
> When machines start to adapt to US, we should become very, very wary, 'coz they 
> will have become smarter than we are, and they will also have become either 
> certifiably insane to make the attempt or clever liars to fake it.
> 
> Can't trust either of those to keep a beer keg cold...
> 
> Choices, folks.  Choices!
> 
> Bill

Re: [9fans] speaking of kenc

[Francisco J Ballesteros]

They have not reached (yet) the 100+ message count, don't worry. ;)

On 5/6/07, Benn Newman <newmanbe@sdf.lonestar.org> wrote:
> Yes! No! Yes! No!
> Yes!
> No!
>
> If you don't play,
> you don't have to try to win.
> (There is no award, after all.)
>
> For goodness' sake,
> please end this thread.
> --
> Benn Newman
>

Re: [9fans] speaking of kenc

[Benn Newman]

Yes! No! Yes! No!
Yes!
No!

If you don't play,
you don't have to try to win.
(There is no award, after all.)

For goodness' sake,
please end this thread.
-- 
Benn Newman

Re: [9fans] speaking of kenc

[W B Hacker]

lucio@proxima.alt.za wrote:
>> there's a realmode assembler in /n/sources/contrib/quanstro/realmode.tbz.
>> it does all addressing modes supported by x86 in 16bit mode.
>> 8a already does all the 32bit stuff one would need.
> 
> I'd say that proves my point, in that a single assembler for both
> families seems hard to put together.  Or should I look harder?
> 
> ++L
> 
> 

Probably.

It has been a long while, but IIRC the MC 68008 / 16 / 32 path (width, not part 
numbers), or the later IBM/Motorola Power Series architecture were places where 
a degree of 'seamlessness' and auto-adaptation was sought across bit-width.

I don't recall how successful the efforts were, 'coz the impending cost of 
adding  yet-another-fee-not-free assembler drove me to Ray Duncan's LMI forth 
around the time the 68000 and 6809 were new, and forth was a lot happier than 
asm-generated output in small memory. Reasonably self-documenting, too if you 
had a modicum of discipline in your style. And only if.

Bill

Re: [9fans] speaking of kenc

[lucio]

> there's a realmode assembler in /n/sources/contrib/quanstro/realmode.tbz.
> it does all addressing modes supported by x86 in 16bit mode.
> 8a already does all the 32bit stuff one would need.

I'd say that proves my point, in that a single assembler for both
families seems hard to put together.  Or should I look harder?

++L

Re: [9fans] speaking of kenc

[erik quanstrom]

> Oh, yeah?  For the Intel x86 series?  Across all its instruction sets,
> emulation modes and addressing modes?

there's a realmode assembler in /n/sources/contrib/quanstro/realmode.tbz.
it does all addressing modes supported by x86 in 16bit mode.
8a already does all the 32bit stuff one would need.

> How long do you think it will
> take you?  And what language would you write in?  On what platform?

less than 1 week.  c.  plan 9.  (i didn't write it.)

- erik