* [9fans] speaking of kenc @ 2007-04-27 3:08 erik quanstrom 2007-04-27 3:44 ` David Leimbach 2007-04-27 4:54 ` Joel C. Salomon 0 siblings, 2 replies; 149+ messages in thread From: erik quanstrom @ 2007-04-27 3:08 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 3:08 [9fans] speaking of kenc erik quanstrom @ 2007-04-27 3:44 ` David Leimbach 2007-04-27 4:56 ` Bruce Ellis 2007-04-27 4:54 ` Joel C. Salomon 1 sibling, 1 reply; 149+ messages in thread From: David Leimbach @ 2007-04-27 3:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 3:44 ` David Leimbach @ 2007-04-27 4:56 ` Bruce Ellis 2007-04-27 6:21 ` Skip Tavakkolian 0 siblings, 1 reply; 149+ messages in thread From: Bruce Ellis @ 2007-04-27 4:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 4:56 ` Bruce Ellis @ 2007-04-27 6:21 ` Skip Tavakkolian 0 siblings, 0 replies; 149+ messages in thread From: Skip Tavakkolian @ 2007-04-27 6:21 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 3:08 [9fans] speaking of kenc erik quanstrom 2007-04-27 3:44 ` David Leimbach @ 2007-04-27 4:54 ` Joel C. Salomon 2007-04-27 4:58 ` Bruce Ellis ` (4 more replies) 1 sibling, 5 replies; 149+ messages in thread From: Joel C. Salomon @ 2007-04-27 4:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 4:54 ` Joel C. Salomon @ 2007-04-27 4:58 ` Bruce Ellis 2007-04-27 11:00 ` Charles Forsyth ` (3 subsequent siblings) 4 siblings, 0 replies; 149+ messages in thread From: Bruce Ellis @ 2007-04-27 4:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 4:54 ` Joel C. Salomon 2007-04-27 4:58 ` Bruce Ellis @ 2007-04-27 11:00 ` Charles Forsyth 2007-04-27 13:49 ` David Leimbach 2007-04-27 16:21 ` Douglas A. Gwyn 2007-04-27 11:12 ` Charles Forsyth ` (2 subsequent siblings) 4 siblings, 2 replies; 149+ messages in thread From: Charles Forsyth @ 2007-04-27 11:00 UTC (permalink / raw) To: 9fans >_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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 11:00 ` Charles Forsyth @ 2007-04-27 13:49 ` David Leimbach 2007-04-27 16:23 ` Douglas A. Gwyn 2007-04-27 16:21 ` Douglas A. Gwyn 1 sibling, 1 reply; 149+ messages in thread From: David Leimbach @ 2007-04-27 13:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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... ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 13:49 ` David Leimbach @ 2007-04-27 16:23 ` Douglas A. Gwyn 2007-04-29 2:02 ` erik quanstrom 0 siblings, 1 reply; 149+ messages in thread From: Douglas A. Gwyn @ 2007-04-27 16:23 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 16:23 ` Douglas A. Gwyn @ 2007-04-29 2:02 ` erik quanstrom 2007-04-29 2:55 ` Tim Wiess ` (2 more replies) 0 siblings, 3 replies; 149+ messages in thread From: erik quanstrom @ 2007-04-29 2:02 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-29 2:02 ` erik quanstrom @ 2007-04-29 2:55 ` Tim Wiess 2007-04-29 6:42 ` Uriel 2007-04-29 20:47 ` Charles Forsyth 2007-04-30 8:29 ` Douglas A. Gwyn 2 siblings, 1 reply; 149+ messages in thread From: Tim Wiess @ 2007-04-29 2:55 UTC (permalink / raw) To: 9fans > good point. except, dennis was mostly ignored. > why should mortals expect different results? perhaps we just need to speak lounder. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-29 2:55 ` Tim Wiess @ 2007-04-29 6:42 ` Uriel 0 siblings, 0 replies; 149+ messages in thread From: Uriel @ 2007-04-29 6:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-29 2:02 ` erik quanstrom 2007-04-29 2:55 ` Tim Wiess @ 2007-04-29 20:47 ` Charles Forsyth 2007-04-30 8:29 ` Douglas A. Gwyn 2 siblings, 0 replies; 149+ messages in thread From: Charles Forsyth @ 2007-04-29 20:47 UTC (permalink / raw) To: 9fans >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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-29 2:02 ` erik quanstrom 2007-04-29 2:55 ` Tim Wiess 2007-04-29 20:47 ` Charles Forsyth @ 2007-04-30 8:29 ` Douglas A. Gwyn 2007-04-30 13:08 ` Uriel 2007-05-01 0:22 ` erik quanstrom 2 siblings, 2 replies; 149+ messages in thread From: Douglas A. Gwyn @ 2007-04-30 8:29 UTC (permalink / raw) To: 9fans "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.). ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-30 8:29 ` Douglas A. Gwyn @ 2007-04-30 13:08 ` Uriel 2007-05-01 0:22 ` erik quanstrom 1 sibling, 0 replies; 149+ messages in thread From: Uriel @ 2007-04-30 13:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-30 8:29 ` Douglas A. Gwyn 2007-04-30 13:08 ` Uriel @ 2007-05-01 0:22 ` erik quanstrom 2007-05-01 14:45 ` Jon Snader 2007-05-02 8:33 ` Douglas A. Gwyn 1 sibling, 2 replies; 149+ messages in thread From: erik quanstrom @ 2007-05-01 0:22 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 0:22 ` erik quanstrom @ 2007-05-01 14:45 ` Jon Snader 2007-05-01 14:56 ` Devon H. O'Dell ` (2 more replies) 2007-05-02 8:33 ` Douglas A. Gwyn 1 sibling, 3 replies; 149+ messages in thread From: Jon Snader @ 2007-05-01 14:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 14:45 ` Jon Snader @ 2007-05-01 14:56 ` Devon H. O'Dell 2007-05-01 15:12 ` erik quanstrom ` (2 more replies) 2007-05-01 15:51 ` Anthony Sorace 2007-05-02 8:33 ` Douglas A. Gwyn 2 siblings, 3 replies; 149+ messages in thread From: Devon H. O'Dell @ 2007-05-01 14:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, Jon Snader 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 14:56 ` Devon H. O'Dell @ 2007-05-01 15:12 ` erik quanstrom 2007-05-01 15:29 ` Devon H. O'Dell 2007-05-01 21:32 ` Jon Snader 2007-05-02 0:04 ` Derek Fawcus 2 siblings, 1 reply; 149+ messages in thread From: erik quanstrom @ 2007-05-01 15:12 UTC (permalink / raw) To: 9fans > > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 15:12 ` erik quanstrom @ 2007-05-01 15:29 ` Devon H. O'Dell 0 siblings, 0 replies; 149+ messages in thread From: Devon H. O'Dell @ 2007-05-01 15:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 14:56 ` Devon H. O'Dell 2007-05-01 15:12 ` erik quanstrom @ 2007-05-01 21:32 ` Jon Snader 2007-05-02 0:04 ` Derek Fawcus 2 siblings, 0 replies; 149+ messages in thread From: Jon Snader @ 2007-05-01 21:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 14:56 ` Devon H. O'Dell 2007-05-01 15:12 ` erik quanstrom 2007-05-01 21:32 ` Jon Snader @ 2007-05-02 0:04 ` Derek Fawcus 2007-05-02 8:44 ` Charles Forsyth 2 siblings, 1 reply; 149+ messages in thread From: Derek Fawcus @ 2007-05-02 0:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-02 0:04 ` Derek Fawcus @ 2007-05-02 8:44 ` Charles Forsyth 0 siblings, 0 replies; 149+ messages in thread From: Charles Forsyth @ 2007-05-02 8:44 UTC (permalink / raw) To: 9fans > 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!!! ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 14:45 ` Jon Snader 2007-05-01 14:56 ` Devon H. O'Dell @ 2007-05-01 15:51 ` Anthony Sorace 2007-05-02 8:32 ` Douglas A. Gwyn 2007-05-02 8:33 ` Douglas A. Gwyn 2 siblings, 1 reply; 149+ messages in thread From: Anthony Sorace @ 2007-05-01 15:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, Jon Snader 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 15:51 ` Anthony Sorace @ 2007-05-02 8:32 ` Douglas A. Gwyn 2007-05-02 9:00 ` Steve Simon 0 siblings, 1 reply; 149+ messages in thread From: Douglas A. Gwyn @ 2007-05-02 8:32 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-02 8:32 ` Douglas A. Gwyn @ 2007-05-02 9:00 ` Steve Simon 2007-05-03 1:32 ` David Arnold 0 siblings, 1 reply; 149+ messages in thread From: Steve Simon @ 2007-05-02 9:00 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-02 9:00 ` Steve Simon @ 2007-05-03 1:32 ` David Arnold 2007-05-03 3:39 ` Adrian Tritschler 0 siblings, 1 reply; 149+ messages in thread From: David Arnold @ 2007-05-03 1:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -->"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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-03 1:32 ` David Arnold @ 2007-05-03 3:39 ` Adrian Tritschler 2007-05-03 3:57 ` Paul Lalonde 0 siblings, 1 reply; 149+ messages in thread From: Adrian Tritschler @ 2007-05-03 3:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-03 3:39 ` Adrian Tritschler @ 2007-05-03 3:57 ` Paul Lalonde 2007-05-03 4:11 ` Federico Benavento 0 siblings, 1 reply; 149+ messages in thread From: Paul Lalonde @ 2007-05-03 3:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----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----- ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-03 3:57 ` Paul Lalonde @ 2007-05-03 4:11 ` Federico Benavento 2007-05-03 13:34 ` Anthony Sorace ` (2 more replies) 0 siblings, 3 replies; 149+ messages in thread From: Federico Benavento @ 2007-05-03 4:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-03 4:11 ` Federico Benavento @ 2007-05-03 13:34 ` Anthony Sorace 2007-05-03 22:04 ` LiteStar numnums 2007-05-04 1:45 ` Roman Shaposhnick 2 siblings, 0 replies; 149+ messages in thread From: Anthony Sorace @ 2007-05-03 13:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-03 4:11 ` Federico Benavento 2007-05-03 13:34 ` Anthony Sorace @ 2007-05-03 22:04 ` LiteStar numnums 2007-05-04 1:45 ` Roman Shaposhnick 2 siblings, 0 replies; 149+ messages in thread From: LiteStar numnums @ 2007-05-03 22:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-03 4:11 ` Federico Benavento 2007-05-03 13:34 ` Anthony Sorace 2007-05-03 22:04 ` LiteStar numnums @ 2007-05-04 1:45 ` Roman Shaposhnick 2007-05-04 1:51 ` Lyndon Nerenberg ` (2 more replies) 2 siblings, 3 replies; 149+ messages in thread From: Roman Shaposhnick @ 2007-05-04 1:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 1:45 ` Roman Shaposhnick @ 2007-05-04 1:51 ` Lyndon Nerenberg 2007-05-04 2:00 ` erik quanstrom 2007-05-04 8:46 ` Douglas A. Gwyn 2 siblings, 0 replies; 149+ messages in thread From: Lyndon Nerenberg @ 2007-05-04 1:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 1:45 ` Roman Shaposhnick 2007-05-04 1:51 ` Lyndon Nerenberg @ 2007-05-04 2:00 ` erik quanstrom 2007-05-04 2:08 ` Roman Shaposhnick 2007-05-04 8:46 ` Douglas A. Gwyn 2 siblings, 1 reply; 149+ messages in thread From: erik quanstrom @ 2007-05-04 2:00 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 2:00 ` erik quanstrom @ 2007-05-04 2:08 ` Roman Shaposhnick 2007-05-04 2:12 ` Lyndon Nerenberg 2007-05-04 2:16 ` erik quanstrom 0 siblings, 2 replies; 149+ messages in thread From: Roman Shaposhnick @ 2007-05-04 2:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 2:08 ` Roman Shaposhnick @ 2007-05-04 2:12 ` Lyndon Nerenberg 2007-05-04 2:20 ` Roman Shaposhnick 2007-05-04 2:16 ` erik quanstrom 1 sibling, 1 reply; 149+ messages in thread From: Lyndon Nerenberg @ 2007-05-04 2:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 2:12 ` Lyndon Nerenberg @ 2007-05-04 2:20 ` Roman Shaposhnick 2007-05-04 2:35 ` Lyndon Nerenberg 0 siblings, 1 reply; 149+ messages in thread From: Roman Shaposhnick @ 2007-05-04 2:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 2:20 ` Roman Shaposhnick @ 2007-05-04 2:35 ` Lyndon Nerenberg 2007-05-04 6:53 ` Bruce Ellis 2007-05-05 5:11 ` Roman Shaposhnick 0 siblings, 2 replies; 149+ messages in thread From: Lyndon Nerenberg @ 2007-05-04 2:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs >> 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 2:35 ` Lyndon Nerenberg @ 2007-05-04 6:53 ` Bruce Ellis 2007-05-05 4:49 ` Roman Shaposhnick 2007-05-05 5:11 ` Roman Shaposhnick 1 sibling, 1 reply; 149+ messages in thread From: Bruce Ellis @ 2007-05-04 6:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 6:53 ` Bruce Ellis @ 2007-05-05 4:49 ` Roman Shaposhnick 0 siblings, 0 replies; 149+ messages in thread From: Roman Shaposhnick @ 2007-05-05 4:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 2:35 ` Lyndon Nerenberg 2007-05-04 6:53 ` Bruce Ellis @ 2007-05-05 5:11 ` Roman Shaposhnick 2007-05-05 5:14 ` Bruce Ellis 2007-05-05 5:30 ` lucio 1 sibling, 2 replies; 149+ messages in thread From: Roman Shaposhnick @ 2007-05-05 5:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-05 5:11 ` Roman Shaposhnick @ 2007-05-05 5:14 ` Bruce Ellis 2007-05-05 18:52 ` erik quanstrom 2007-05-06 1:13 ` Rogelio Serrano 2007-05-05 5:30 ` lucio 1 sibling, 2 replies; 149+ messages in thread From: Bruce Ellis @ 2007-05-05 5:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-05 5:14 ` Bruce Ellis @ 2007-05-05 18:52 ` erik quanstrom 2007-05-05 19:13 ` lucio 2007-05-06 1:13 ` Rogelio Serrano 1 sibling, 1 reply; 149+ messages in thread From: erik quanstrom @ 2007-05-05 18:52 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-05 18:52 ` erik quanstrom @ 2007-05-05 19:13 ` lucio 2007-05-05 23:09 ` Bruce Ellis 2007-05-06 4:08 ` erik quanstrom 0 siblings, 2 replies; 149+ messages in thread From: lucio @ 2007-05-05 19:13 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-05 19:13 ` lucio @ 2007-05-05 23:09 ` Bruce Ellis 2007-05-06 1:24 ` Rogelio Serrano 2007-05-06 4:08 ` erik quanstrom 1 sibling, 1 reply; 149+ messages in thread From: Bruce Ellis @ 2007-05-05 23:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-05 23:09 ` Bruce Ellis @ 2007-05-06 1:24 ` Rogelio Serrano 0 siblings, 0 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 1:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-05 19:13 ` lucio 2007-05-05 23:09 ` Bruce Ellis @ 2007-05-06 4:08 ` erik quanstrom 2007-05-06 4:53 ` W B Hacker ` (4 more replies) 1 sibling, 5 replies; 149+ messages in thread From: erik quanstrom @ 2007-05-06 4:08 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 4:08 ` erik quanstrom @ 2007-05-06 4:53 ` W B Hacker 2007-05-06 5:01 ` lucio ` (3 subsequent siblings) 4 siblings, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 4:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 4:08 ` erik quanstrom 2007-05-06 4:53 ` W B Hacker @ 2007-05-06 5:01 ` lucio 2007-05-06 5:01 ` Rogelio Serrano ` (2 subsequent siblings) 4 siblings, 0 replies; 149+ messages in thread From: lucio @ 2007-05-06 5:01 UTC (permalink / raw) To: 9fans >> 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 4:08 ` erik quanstrom 2007-05-06 4:53 ` W B Hacker 2007-05-06 5:01 ` lucio @ 2007-05-06 5:01 ` Rogelio Serrano 2007-05-06 5:07 ` Rogelio Serrano ` (2 more replies) 2007-05-06 5:10 ` W B Hacker 2007-05-07 1:47 ` Roman Shaposhnik 4 siblings, 3 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 5:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:01 ` Rogelio Serrano @ 2007-05-06 5:07 ` Rogelio Serrano 2007-05-06 5:15 ` lucio 2007-05-06 6:04 ` Skip Tavakkolian 2007-05-06 5:12 ` lucio 2007-05-06 5:15 ` W B Hacker 2 siblings, 2 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 5:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:07 ` Rogelio Serrano @ 2007-05-06 5:15 ` lucio 2007-05-06 5:37 ` Bruce Ellis 2007-05-06 6:30 ` Rogelio Serrano 2007-05-06 6:04 ` Skip Tavakkolian 1 sibling, 2 replies; 149+ messages in thread From: lucio @ 2007-05-06 5:15 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:15 ` lucio @ 2007-05-06 5:37 ` Bruce Ellis 2007-05-06 6:30 ` Rogelio Serrano 1 sibling, 0 replies; 149+ messages in thread From: Bruce Ellis @ 2007-05-06 5:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:15 ` lucio 2007-05-06 5:37 ` Bruce Ellis @ 2007-05-06 6:30 ` Rogelio Serrano 2007-05-06 6:46 ` lucio ` (2 more replies) 1 sibling, 3 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 6:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:30 ` Rogelio Serrano @ 2007-05-06 6:46 ` lucio 2007-05-06 6:49 ` lucio 2007-05-06 6:51 ` W B Hacker 2 siblings, 0 replies; 149+ messages in thread From: lucio @ 2007-05-06 6:46 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:30 ` Rogelio Serrano 2007-05-06 6:46 ` lucio @ 2007-05-06 6:49 ` lucio 2007-05-06 7:35 ` Rogelio Serrano 2007-05-06 6:51 ` W B Hacker 2 siblings, 1 reply; 149+ messages in thread From: lucio @ 2007-05-06 6:49 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:49 ` lucio @ 2007-05-06 7:35 ` Rogelio Serrano 0 siblings, 0 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 7:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:30 ` Rogelio Serrano 2007-05-06 6:46 ` lucio 2007-05-06 6:49 ` lucio @ 2007-05-06 6:51 ` W B Hacker 2007-05-06 10:25 ` Rogelio Serrano 2 siblings, 1 reply; 149+ messages in thread From: W B Hacker @ 2007-05-06 6:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:51 ` W B Hacker @ 2007-05-06 10:25 ` Rogelio Serrano 0 siblings, 0 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 10:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:07 ` Rogelio Serrano 2007-05-06 5:15 ` lucio @ 2007-05-06 6:04 ` Skip Tavakkolian 2007-05-06 7:24 ` lucio 2007-05-07 1:55 ` Roman Shaposhnik 1 sibling, 2 replies; 149+ messages in thread From: Skip Tavakkolian @ 2007-05-06 6:04 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:04 ` Skip Tavakkolian @ 2007-05-06 7:24 ` lucio 2007-05-06 11:47 ` Bruce Ellis 2007-05-07 1:55 ` Roman Shaposhnik 1 sibling, 1 reply; 149+ messages in thread From: lucio @ 2007-05-06 7:24 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:24 ` lucio @ 2007-05-06 11:47 ` Bruce Ellis 0 siblings, 0 replies; 149+ messages in thread From: Bruce Ellis @ 2007-05-06 11:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:04 ` Skip Tavakkolian 2007-05-06 7:24 ` lucio @ 2007-05-07 1:55 ` Roman Shaposhnik 1 sibling, 0 replies; 149+ messages in thread From: Roman Shaposhnik @ 2007-05-07 1:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ;-) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:01 ` Rogelio Serrano 2007-05-06 5:07 ` Rogelio Serrano @ 2007-05-06 5:12 ` lucio 2007-05-06 13:18 ` Richard Miller 2007-05-07 1:57 ` Roman Shaposhnik 2007-05-06 5:15 ` W B Hacker 2 siblings, 2 replies; 149+ messages in thread From: lucio @ 2007-05-06 5:12 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:12 ` lucio @ 2007-05-06 13:18 ` Richard Miller 2007-05-06 20:23 ` Roman Shaposhnik 2007-05-07 1:57 ` Roman Shaposhnik 1 sibling, 1 reply; 149+ messages in thread From: Richard Miller @ 2007-05-06 13:18 UTC (permalink / raw) To: 9fans > 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." ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 13:18 ` Richard Miller @ 2007-05-06 20:23 ` Roman Shaposhnik 0 siblings, 0 replies; 149+ messages in thread From: Roman Shaposhnik @ 2007-05-06 20:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:12 ` lucio 2007-05-06 13:18 ` Richard Miller @ 2007-05-07 1:57 ` Roman Shaposhnik 2007-05-07 4:29 ` W B Hacker 1 sibling, 1 reply; 149+ messages in thread From: Roman Shaposhnik @ 2007-05-07 1:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-07 1:57 ` Roman Shaposhnik @ 2007-05-07 4:29 ` W B Hacker 2007-05-07 15:08 ` Tim Wiess 0 siblings, 1 reply; 149+ messages in thread From: W B Hacker @ 2007-05-07 4:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-07 4:29 ` W B Hacker @ 2007-05-07 15:08 ` Tim Wiess 0 siblings, 0 replies; 149+ messages in thread From: Tim Wiess @ 2007-05-07 15:08 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:01 ` Rogelio Serrano 2007-05-06 5:07 ` Rogelio Serrano 2007-05-06 5:12 ` lucio @ 2007-05-06 5:15 ` W B Hacker 2007-05-06 7:43 ` Rogelio Serrano 2 siblings, 1 reply; 149+ messages in thread From: W B Hacker @ 2007-05-06 5:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:15 ` W B Hacker @ 2007-05-06 7:43 ` Rogelio Serrano 2007-05-06 8:02 ` W B Hacker 2007-05-06 8:03 ` lucio 0 siblings, 2 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 7:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:43 ` Rogelio Serrano @ 2007-05-06 8:02 ` W B Hacker 2007-05-06 8:12 ` Rogelio Serrano 2007-05-06 8:03 ` lucio 1 sibling, 1 reply; 149+ messages in thread From: W B Hacker @ 2007-05-06 8:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 8:02 ` W B Hacker @ 2007-05-06 8:12 ` Rogelio Serrano 2007-05-06 9:00 ` W B Hacker 0 siblings, 1 reply; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 8:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 8:12 ` Rogelio Serrano @ 2007-05-06 9:00 ` W B Hacker 0 siblings, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 9:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:43 ` Rogelio Serrano 2007-05-06 8:02 ` W B Hacker @ 2007-05-06 8:03 ` lucio 2007-05-06 8:42 ` Rogelio Serrano 2007-05-06 9:09 ` W B Hacker 1 sibling, 2 replies; 149+ messages in thread From: lucio @ 2007-05-06 8:03 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 8:03 ` lucio @ 2007-05-06 8:42 ` Rogelio Serrano 2007-05-06 10:20 ` matt 2007-05-06 9:09 ` W B Hacker 1 sibling, 1 reply; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 8:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 8:42 ` Rogelio Serrano @ 2007-05-06 10:20 ` matt 2007-05-06 10:29 ` Rogelio Serrano 0 siblings, 1 reply; 149+ messages in thread From: matt @ 2007-05-06 10:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ! ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 10:20 ` matt @ 2007-05-06 10:29 ` Rogelio Serrano 0 siblings, 0 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 10:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 8:03 ` lucio 2007-05-06 8:42 ` Rogelio Serrano @ 2007-05-06 9:09 ` W B Hacker 1 sibling, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 9:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 4:08 ` erik quanstrom ` (2 preceding siblings ...) 2007-05-06 5:01 ` Rogelio Serrano @ 2007-05-06 5:10 ` W B Hacker 2007-05-06 5:32 ` lucio 2007-05-07 1:47 ` Roman Shaposhnik 4 siblings, 1 reply; 149+ messages in thread From: W B Hacker @ 2007-05-06 5:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:10 ` W B Hacker @ 2007-05-06 5:32 ` lucio 2007-05-06 6:18 ` Rogelio Serrano 2007-05-06 6:21 ` W B Hacker 0 siblings, 2 replies; 149+ messages in thread From: lucio @ 2007-05-06 5:32 UTC (permalink / raw) To: 9fans >> 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:32 ` lucio @ 2007-05-06 6:18 ` Rogelio Serrano 2007-05-06 6:30 ` W B Hacker 2007-05-06 6:21 ` W B Hacker 1 sibling, 1 reply; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 6:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:18 ` Rogelio Serrano @ 2007-05-06 6:30 ` W B Hacker 0 siblings, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 6:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:32 ` lucio 2007-05-06 6:18 ` Rogelio Serrano @ 2007-05-06 6:21 ` W B Hacker 1 sibling, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 6:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 4:08 ` erik quanstrom ` (3 preceding siblings ...) 2007-05-06 5:10 ` W B Hacker @ 2007-05-07 1:47 ` Roman Shaposhnik 4 siblings, 0 replies; 149+ messages in thread From: Roman Shaposhnik @ 2007-05-07 1:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-05 5:14 ` Bruce Ellis 2007-05-05 18:52 ` erik quanstrom @ 2007-05-06 1:13 ` Rogelio Serrano 2007-05-06 3:31 ` W B Hacker ` (2 more replies) 1 sibling, 3 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 1:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 1:13 ` Rogelio Serrano @ 2007-05-06 3:31 ` W B Hacker 2007-05-06 4:10 ` erik quanstrom 2007-05-06 5:21 ` Bruce Ellis 2 siblings, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 3:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 1:13 ` Rogelio Serrano 2007-05-06 3:31 ` W B Hacker @ 2007-05-06 4:10 ` erik quanstrom 2007-05-06 4:55 ` Rogelio Serrano 2007-05-06 5:21 ` Bruce Ellis 2 siblings, 1 reply; 149+ messages in thread From: erik quanstrom @ 2007-05-06 4:10 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 4:10 ` erik quanstrom @ 2007-05-06 4:55 ` Rogelio Serrano 2007-05-06 5:10 ` lucio 0 siblings, 1 reply; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 4:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 4:55 ` Rogelio Serrano @ 2007-05-06 5:10 ` lucio 2007-05-06 6:05 ` W B Hacker 2007-05-06 6:45 ` Rogelio Serrano 0 siblings, 2 replies; 149+ messages in thread From: lucio @ 2007-05-06 5:10 UTC (permalink / raw) To: 9fans > 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? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:10 ` lucio @ 2007-05-06 6:05 ` W B Hacker 2007-05-06 8:45 ` matt 2007-05-06 6:45 ` Rogelio Serrano 1 sibling, 1 reply; 149+ messages in thread From: W B Hacker @ 2007-05-06 6:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:05 ` W B Hacker @ 2007-05-06 8:45 ` matt 0 siblings, 0 replies; 149+ messages in thread From: matt @ 2007-05-06 8:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > > 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:10 ` lucio 2007-05-06 6:05 ` W B Hacker @ 2007-05-06 6:45 ` Rogelio Serrano 2007-05-06 6:52 ` lucio 2007-05-06 7:03 ` W B Hacker 1 sibling, 2 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 6:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:45 ` Rogelio Serrano @ 2007-05-06 6:52 ` lucio 2007-05-06 7:09 ` W B Hacker 2007-05-06 7:03 ` W B Hacker 1 sibling, 1 reply; 149+ messages in thread From: lucio @ 2007-05-06 6:52 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:52 ` lucio @ 2007-05-06 7:09 ` W B Hacker 2007-05-06 7:34 ` Rogelio Serrano 2007-05-06 7:40 ` lucio 0 siblings, 2 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 7:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:09 ` W B Hacker @ 2007-05-06 7:34 ` Rogelio Serrano 2007-05-06 7:49 ` W B Hacker 2007-05-06 7:54 ` lucio 2007-05-06 7:40 ` lucio 1 sibling, 2 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 7:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:34 ` Rogelio Serrano @ 2007-05-06 7:49 ` W B Hacker 2007-05-06 7:54 ` lucio 1 sibling, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 7:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:34 ` Rogelio Serrano 2007-05-06 7:49 ` W B Hacker @ 2007-05-06 7:54 ` lucio 2007-05-06 8:35 ` Rogelio Serrano 1 sibling, 1 reply; 149+ messages in thread From: lucio @ 2007-05-06 7:54 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:54 ` lucio @ 2007-05-06 8:35 ` Rogelio Serrano 0 siblings, 0 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 8:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:09 ` W B Hacker 2007-05-06 7:34 ` Rogelio Serrano @ 2007-05-06 7:40 ` lucio 2007-05-06 8:59 ` W B Hacker 1 sibling, 1 reply; 149+ messages in thread From: lucio @ 2007-05-06 7:40 UTC (permalink / raw) To: 9fans >> 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 7:40 ` lucio @ 2007-05-06 8:59 ` W B Hacker 0 siblings, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 8:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 6:45 ` Rogelio Serrano 2007-05-06 6:52 ` lucio @ 2007-05-06 7:03 ` W B Hacker 1 sibling, 0 replies; 149+ messages in thread From: W B Hacker @ 2007-05-06 7:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 1:13 ` Rogelio Serrano 2007-05-06 3:31 ` W B Hacker 2007-05-06 4:10 ` erik quanstrom @ 2007-05-06 5:21 ` Bruce Ellis 2007-05-06 7:01 ` Rogelio Serrano 2 siblings, 1 reply; 149+ messages in thread From: Bruce Ellis @ 2007-05-06 5:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 5:21 ` Bruce Ellis @ 2007-05-06 7:01 ` Rogelio Serrano 0 siblings, 0 replies; 149+ messages in thread From: Rogelio Serrano @ 2007-05-06 7:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-05 5:11 ` Roman Shaposhnick 2007-05-05 5:14 ` Bruce Ellis @ 2007-05-05 5:30 ` lucio 1 sibling, 0 replies; 149+ messages in thread From: lucio @ 2007-05-05 5:30 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 2:08 ` Roman Shaposhnick 2007-05-04 2:12 ` Lyndon Nerenberg @ 2007-05-04 2:16 ` erik quanstrom 2007-05-04 9:24 ` C H Forsyth 1 sibling, 1 reply; 149+ messages in thread From: erik quanstrom @ 2007-05-04 2:16 UTC (permalink / raw) To: 9fans 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. > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 2:16 ` erik quanstrom @ 2007-05-04 9:24 ` C H Forsyth 2007-05-04 11:18 ` erik quanstrom 2007-05-04 16:19 ` Paul Lalonde 0 siblings, 2 replies; 149+ messages in thread From: C H Forsyth @ 2007-05-04 9:24 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 9:24 ` C H Forsyth @ 2007-05-04 11:18 ` erik quanstrom 2007-05-04 16:19 ` Paul Lalonde 1 sibling, 0 replies; 149+ messages in thread From: erik quanstrom @ 2007-05-04 11:18 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 9:24 ` C H Forsyth 2007-05-04 11:18 ` erik quanstrom @ 2007-05-04 16:19 ` Paul Lalonde 2007-05-04 21:58 ` Dave Eckhardt 1 sibling, 1 reply; 149+ messages in thread From: Paul Lalonde @ 2007-05-04 16:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----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----- ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 16:19 ` Paul Lalonde @ 2007-05-04 21:58 ` Dave Eckhardt 2007-05-04 22:27 ` Paul Lalonde 0 siblings, 1 reply; 149+ messages in thread From: Dave Eckhardt @ 2007-05-04 21:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 21:58 ` Dave Eckhardt @ 2007-05-04 22:27 ` Paul Lalonde 0 siblings, 0 replies; 149+ messages in thread From: Paul Lalonde @ 2007-05-04 22:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----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----- ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 1:45 ` Roman Shaposhnick 2007-05-04 1:51 ` Lyndon Nerenberg 2007-05-04 2:00 ` erik quanstrom @ 2007-05-04 8:46 ` Douglas A. Gwyn 2007-05-05 4:47 ` Roman Shaposhnick 2 siblings, 1 reply; 149+ messages in thread From: Douglas A. Gwyn @ 2007-05-04 8:46 UTC (permalink / raw) To: 9fans "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). ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-04 8:46 ` Douglas A. Gwyn @ 2007-05-05 4:47 ` Roman Shaposhnick 0 siblings, 0 replies; 149+ messages in thread From: Roman Shaposhnick @ 2007-05-05 4:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 14:45 ` Jon Snader 2007-05-01 14:56 ` Devon H. O'Dell 2007-05-01 15:51 ` Anthony Sorace @ 2007-05-02 8:33 ` Douglas A. Gwyn 2007-05-02 11:25 ` Jon Snader 2 siblings, 1 reply; 149+ messages in thread From: Douglas A. Gwyn @ 2007-05-02 8:33 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-02 8:33 ` Douglas A. Gwyn @ 2007-05-02 11:25 ` Jon Snader 0 siblings, 0 replies; 149+ messages in thread From: Jon Snader @ 2007-05-02 11:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-01 0:22 ` erik quanstrom 2007-05-01 14:45 ` Jon Snader @ 2007-05-02 8:33 ` Douglas A. Gwyn 2007-05-02 11:30 ` erik quanstrom 1 sibling, 1 reply; 149+ messages in thread From: Douglas A. Gwyn @ 2007-05-02 8:33 UTC (permalink / raw) To: 9fans "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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-02 8:33 ` Douglas A. Gwyn @ 2007-05-02 11:30 ` erik quanstrom 0 siblings, 0 replies; 149+ messages in thread From: erik quanstrom @ 2007-05-02 11:30 UTC (permalink / raw) To: 9fans > "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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 11:00 ` Charles Forsyth 2007-04-27 13:49 ` David Leimbach @ 2007-04-27 16:21 ` Douglas A. Gwyn 1 sibling, 0 replies; 149+ messages in thread From: Douglas A. Gwyn @ 2007-04-27 16:21 UTC (permalink / raw) To: 9fans > >_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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 4:54 ` Joel C. Salomon 2007-04-27 4:58 ` Bruce Ellis 2007-04-27 11:00 ` Charles Forsyth @ 2007-04-27 11:12 ` Charles Forsyth 2007-04-27 11:46 ` erik quanstrom 2007-04-28 9:09 ` ron minnich 4 siblings, 0 replies; 149+ messages in thread From: Charles Forsyth @ 2007-04-27 11:12 UTC (permalink / raw) To: 9fans >_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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 4:54 ` Joel C. Salomon ` (2 preceding siblings ...) 2007-04-27 11:12 ` Charles Forsyth @ 2007-04-27 11:46 ` erik quanstrom 2007-04-27 14:21 ` Joel C. Salomon 2007-04-28 9:09 ` ron minnich 4 siblings, 1 reply; 149+ messages in thread From: erik quanstrom @ 2007-04-27 11:46 UTC (permalink / raw) To: 9fans > > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 11:46 ` erik quanstrom @ 2007-04-27 14:21 ` Joel C. Salomon 2007-04-27 14:26 ` erik quanstrom 0 siblings, 1 reply; 149+ messages in thread From: Joel C. Salomon @ 2007-04-27 14:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 14:21 ` Joel C. Salomon @ 2007-04-27 14:26 ` erik quanstrom 2007-04-27 14:41 ` Rob Pike 2007-04-27 14:55 ` Joel C. Salomon 0 siblings, 2 replies; 149+ messages in thread From: erik quanstrom @ 2007-04-27 14:26 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 14:26 ` erik quanstrom @ 2007-04-27 14:41 ` Rob Pike 2007-04-27 14:55 ` Joel C. Salomon 1 sibling, 0 replies; 149+ messages in thread From: Rob Pike @ 2007-04-27 14:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs \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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 14:26 ` erik quanstrom 2007-04-27 14:41 ` Rob Pike @ 2007-04-27 14:55 ` Joel C. Salomon 2007-04-27 15:24 ` erik quanstrom 2007-04-27 15:53 ` C H Forsyth 1 sibling, 2 replies; 149+ messages in thread From: Joel C. Salomon @ 2007-04-27 14:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 14:55 ` Joel C. Salomon @ 2007-04-27 15:24 ` erik quanstrom 2007-04-27 15:53 ` C H Forsyth 1 sibling, 0 replies; 149+ messages in thread From: erik quanstrom @ 2007-04-27 15:24 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 14:55 ` Joel C. Salomon 2007-04-27 15:24 ` erik quanstrom @ 2007-04-27 15:53 ` C H Forsyth 1 sibling, 0 replies; 149+ messages in thread From: C H Forsyth @ 2007-04-27 15:53 UTC (permalink / raw) To: 9fans >> > 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) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-27 4:54 ` Joel C. Salomon ` (3 preceding siblings ...) 2007-04-27 11:46 ` erik quanstrom @ 2007-04-28 9:09 ` ron minnich 2007-04-28 9:17 ` Lucio De Re ` (2 more replies) 4 siblings, 3 replies; 149+ messages in thread From: ron minnich @ 2007-04-28 9:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 9:09 ` ron minnich @ 2007-04-28 9:17 ` Lucio De Re 2007-04-28 13:48 ` Eric Van Hensbergen 2007-04-28 15:45 ` Charles Forsyth 2007-04-28 21:24 ` Roman Shaposhnik 2 siblings, 1 reply; 149+ messages in thread From: Lucio De Re @ 2007-04-28 9:17 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 9:17 ` Lucio De Re @ 2007-04-28 13:48 ` Eric Van Hensbergen 2007-04-28 13:57 ` Lucio De Re ` (2 more replies) 0 siblings, 3 replies; 149+ messages in thread From: Eric Van Hensbergen @ 2007-04-28 13:48 UTC (permalink / raw) To: Lucio De Re, Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 13:48 ` Eric Van Hensbergen @ 2007-04-28 13:57 ` Lucio De Re 2007-04-28 14:15 ` LiteStar numnums 2007-04-28 21:21 ` Roman Shaposhnik 2 siblings, 0 replies; 149+ messages in thread From: Lucio De Re @ 2007-04-28 13:57 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 13:48 ` Eric Van Hensbergen 2007-04-28 13:57 ` Lucio De Re @ 2007-04-28 14:15 ` LiteStar numnums 2007-04-28 21:21 ` Roman Shaposhnik 2 siblings, 0 replies; 149+ messages in thread From: LiteStar numnums @ 2007-04-28 14:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 13:48 ` Eric Van Hensbergen 2007-04-28 13:57 ` Lucio De Re 2007-04-28 14:15 ` LiteStar numnums @ 2007-04-28 21:21 ` Roman Shaposhnik 2007-04-28 21:54 ` ron minnich 2 siblings, 1 reply; 149+ messages in thread From: Roman Shaposhnik @ 2007-04-28 21:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: Lucio De Re 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 21:21 ` Roman Shaposhnik @ 2007-04-28 21:54 ` ron minnich 2007-04-28 22:33 ` Steve Simon 0 siblings, 1 reply; 149+ messages in thread From: ron minnich @ 2007-04-28 21:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 21:54 ` ron minnich @ 2007-04-28 22:33 ` Steve Simon 0 siblings, 0 replies; 149+ messages in thread From: Steve Simon @ 2007-04-28 22:33 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 9:09 ` ron minnich 2007-04-28 9:17 ` Lucio De Re @ 2007-04-28 15:45 ` Charles Forsyth 2007-04-28 17:58 ` Rodrigo Miranda ` (2 more replies) 2007-04-28 21:24 ` Roman Shaposhnik 2 siblings, 3 replies; 149+ messages in thread From: Charles Forsyth @ 2007-04-28 15:45 UTC (permalink / raw) To: 9fans This discussion made me curious whether good high-level languages are being developed for scientific computing. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 15:45 ` Charles Forsyth @ 2007-04-28 17:58 ` Rodrigo Miranda 2007-04-28 20:12 ` Eric Van Hensbergen 2007-04-28 18:15 ` Lluís Batlle i Rossell 2007-04-29 2:39 ` Joel C. Salomon 2 siblings, 1 reply; 149+ messages in thread From: Rodrigo Miranda @ 2007-04-28 17:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 17:58 ` Rodrigo Miranda @ 2007-04-28 20:12 ` Eric Van Hensbergen 2007-04-28 21:10 ` Roman Shaposhnik 0 siblings, 1 reply; 149+ messages in thread From: Eric Van Hensbergen @ 2007-04-28 20:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 20:12 ` Eric Van Hensbergen @ 2007-04-28 21:10 ` Roman Shaposhnik 0 siblings, 0 replies; 149+ messages in thread From: Roman Shaposhnik @ 2007-04-28 21:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 15:45 ` Charles Forsyth 2007-04-28 17:58 ` Rodrigo Miranda @ 2007-04-28 18:15 ` Lluís Batlle i Rossell 2007-04-29 2:39 ` Joel C. Salomon 2 siblings, 0 replies; 149+ messages in thread From: Lluís Batlle i Rossell @ 2007-04-28 18:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 15:45 ` Charles Forsyth 2007-04-28 17:58 ` Rodrigo Miranda 2007-04-28 18:15 ` Lluís Batlle i Rossell @ 2007-04-29 2:39 ` Joel C. Salomon 2007-04-29 12:41 ` erik quanstrom 2 siblings, 1 reply; 149+ messages in thread From: Joel C. Salomon @ 2007-04-29 2:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-29 2:39 ` Joel C. Salomon @ 2007-04-29 12:41 ` erik quanstrom 2007-04-29 16:00 ` Joel C. Salomon 0 siblings, 1 reply; 149+ messages in thread From: erik quanstrom @ 2007-04-29 12:41 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-29 12:41 ` erik quanstrom @ 2007-04-29 16:00 ` Joel C. Salomon 0 siblings, 0 replies; 149+ messages in thread From: Joel C. Salomon @ 2007-04-29 16:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > > 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? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-04-28 9:09 ` ron minnich 2007-04-28 9:17 ` Lucio De Re 2007-04-28 15:45 ` Charles Forsyth @ 2007-04-28 21:24 ` Roman Shaposhnik 2 siblings, 0 replies; 149+ messages in thread From: Roman Shaposhnik @ 2007-04-28 21:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc @ 2007-05-06 12:36 erik quanstrom 2007-05-06 15:18 ` lucio 0 siblings, 1 reply; 149+ messages in thread From: erik quanstrom @ 2007-05-06 12:36 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 12:36 erik quanstrom @ 2007-05-06 15:18 ` lucio 2007-05-06 16:23 ` W B Hacker 0 siblings, 1 reply; 149+ messages in thread From: lucio @ 2007-05-06 15:18 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 15:18 ` lucio @ 2007-05-06 16:23 ` W B Hacker 2007-05-06 17:53 ` Benn Newman 0 siblings, 1 reply; 149+ messages in thread From: W B Hacker @ 2007-05-06 16:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 16:23 ` W B Hacker @ 2007-05-06 17:53 ` Benn Newman 2007-05-06 17:56 ` Francisco J Ballesteros 0 siblings, 1 reply; 149+ messages in thread From: Benn Newman @ 2007-05-06 17:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: [9fans] speaking of kenc 2007-05-06 17:53 ` Benn Newman @ 2007-05-06 17:56 ` Francisco J Ballesteros 0 siblings, 0 replies; 149+ messages in thread From: Francisco J Ballesteros @ 2007-05-06 17:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 149+ messages in thread
end of thread, other threads:[~2007-05-07 15:08 UTC | newest] Thread overview: 149+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-04-27 3:08 [9fans] speaking of kenc erik quanstrom 2007-04-27 3:44 ` David Leimbach 2007-04-27 4:56 ` Bruce Ellis 2007-04-27 6:21 ` Skip Tavakkolian 2007-04-27 4:54 ` Joel C. Salomon 2007-04-27 4:58 ` Bruce Ellis 2007-04-27 11:00 ` Charles Forsyth 2007-04-27 13:49 ` David Leimbach 2007-04-27 16:23 ` Douglas A. Gwyn 2007-04-29 2:02 ` erik quanstrom 2007-04-29 2:55 ` Tim Wiess 2007-04-29 6:42 ` Uriel 2007-04-29 20:47 ` Charles Forsyth 2007-04-30 8:29 ` Douglas A. Gwyn 2007-04-30 13:08 ` Uriel 2007-05-01 0:22 ` erik quanstrom 2007-05-01 14:45 ` Jon Snader 2007-05-01 14:56 ` Devon H. O'Dell 2007-05-01 15:12 ` erik quanstrom 2007-05-01 15:29 ` Devon H. O'Dell 2007-05-01 21:32 ` Jon Snader 2007-05-02 0:04 ` Derek Fawcus 2007-05-02 8:44 ` Charles Forsyth 2007-05-01 15:51 ` Anthony Sorace 2007-05-02 8:32 ` Douglas A. Gwyn 2007-05-02 9:00 ` Steve Simon 2007-05-03 1:32 ` David Arnold 2007-05-03 3:39 ` Adrian Tritschler 2007-05-03 3:57 ` Paul Lalonde 2007-05-03 4:11 ` Federico Benavento 2007-05-03 13:34 ` Anthony Sorace 2007-05-03 22:04 ` LiteStar numnums 2007-05-04 1:45 ` Roman Shaposhnick 2007-05-04 1:51 ` Lyndon Nerenberg 2007-05-04 2:00 ` erik quanstrom 2007-05-04 2:08 ` Roman Shaposhnick 2007-05-04 2:12 ` Lyndon Nerenberg 2007-05-04 2:20 ` Roman Shaposhnick 2007-05-04 2:35 ` Lyndon Nerenberg 2007-05-04 6:53 ` Bruce Ellis 2007-05-05 4:49 ` Roman Shaposhnick 2007-05-05 5:11 ` Roman Shaposhnick 2007-05-05 5:14 ` Bruce Ellis 2007-05-05 18:52 ` erik quanstrom 2007-05-05 19:13 ` lucio 2007-05-05 23:09 ` Bruce Ellis 2007-05-06 1:24 ` Rogelio Serrano 2007-05-06 4:08 ` erik quanstrom 2007-05-06 4:53 ` W B Hacker 2007-05-06 5:01 ` lucio 2007-05-06 5:01 ` Rogelio Serrano 2007-05-06 5:07 ` Rogelio Serrano 2007-05-06 5:15 ` lucio 2007-05-06 5:37 ` Bruce Ellis 2007-05-06 6:30 ` Rogelio Serrano 2007-05-06 6:46 ` lucio 2007-05-06 6:49 ` lucio 2007-05-06 7:35 ` Rogelio Serrano 2007-05-06 6:51 ` W B Hacker 2007-05-06 10:25 ` Rogelio Serrano 2007-05-06 6:04 ` Skip Tavakkolian 2007-05-06 7:24 ` lucio 2007-05-06 11:47 ` Bruce Ellis 2007-05-07 1:55 ` Roman Shaposhnik 2007-05-06 5:12 ` lucio 2007-05-06 13:18 ` Richard Miller 2007-05-06 20:23 ` Roman Shaposhnik 2007-05-07 1:57 ` Roman Shaposhnik 2007-05-07 4:29 ` W B Hacker 2007-05-07 15:08 ` Tim Wiess 2007-05-06 5:15 ` W B Hacker 2007-05-06 7:43 ` Rogelio Serrano 2007-05-06 8:02 ` W B Hacker 2007-05-06 8:12 ` Rogelio Serrano 2007-05-06 9:00 ` W B Hacker 2007-05-06 8:03 ` lucio 2007-05-06 8:42 ` Rogelio Serrano 2007-05-06 10:20 ` matt 2007-05-06 10:29 ` Rogelio Serrano 2007-05-06 9:09 ` W B Hacker 2007-05-06 5:10 ` W B Hacker 2007-05-06 5:32 ` lucio 2007-05-06 6:18 ` Rogelio Serrano 2007-05-06 6:30 ` W B Hacker 2007-05-06 6:21 ` W B Hacker 2007-05-07 1:47 ` Roman Shaposhnik 2007-05-06 1:13 ` Rogelio Serrano 2007-05-06 3:31 ` W B Hacker 2007-05-06 4:10 ` erik quanstrom 2007-05-06 4:55 ` Rogelio Serrano 2007-05-06 5:10 ` lucio 2007-05-06 6:05 ` W B Hacker 2007-05-06 8:45 ` matt 2007-05-06 6:45 ` Rogelio Serrano 2007-05-06 6:52 ` lucio 2007-05-06 7:09 ` W B Hacker 2007-05-06 7:34 ` Rogelio Serrano 2007-05-06 7:49 ` W B Hacker 2007-05-06 7:54 ` lucio 2007-05-06 8:35 ` Rogelio Serrano 2007-05-06 7:40 ` lucio 2007-05-06 8:59 ` W B Hacker 2007-05-06 7:03 ` W B Hacker 2007-05-06 5:21 ` Bruce Ellis 2007-05-06 7:01 ` Rogelio Serrano 2007-05-05 5:30 ` lucio 2007-05-04 2:16 ` erik quanstrom 2007-05-04 9:24 ` C H Forsyth 2007-05-04 11:18 ` erik quanstrom 2007-05-04 16:19 ` Paul Lalonde 2007-05-04 21:58 ` Dave Eckhardt 2007-05-04 22:27 ` Paul Lalonde 2007-05-04 8:46 ` Douglas A. Gwyn 2007-05-05 4:47 ` Roman Shaposhnick 2007-05-02 8:33 ` Douglas A. Gwyn 2007-05-02 11:25 ` Jon Snader 2007-05-02 8:33 ` Douglas A. Gwyn 2007-05-02 11:30 ` erik quanstrom 2007-04-27 16:21 ` Douglas A. Gwyn 2007-04-27 11:12 ` Charles Forsyth 2007-04-27 11:46 ` erik quanstrom 2007-04-27 14:21 ` Joel C. Salomon 2007-04-27 14:26 ` erik quanstrom 2007-04-27 14:41 ` Rob Pike 2007-04-27 14:55 ` Joel C. Salomon 2007-04-27 15:24 ` erik quanstrom 2007-04-27 15:53 ` C H Forsyth 2007-04-28 9:09 ` ron minnich 2007-04-28 9:17 ` Lucio De Re 2007-04-28 13:48 ` Eric Van Hensbergen 2007-04-28 13:57 ` Lucio De Re 2007-04-28 14:15 ` LiteStar numnums 2007-04-28 21:21 ` Roman Shaposhnik 2007-04-28 21:54 ` ron minnich 2007-04-28 22:33 ` Steve Simon 2007-04-28 15:45 ` Charles Forsyth 2007-04-28 17:58 ` Rodrigo Miranda 2007-04-28 20:12 ` Eric Van Hensbergen 2007-04-28 21:10 ` Roman Shaposhnik 2007-04-28 18:15 ` Lluís Batlle i Rossell 2007-04-29 2:39 ` Joel C. Salomon 2007-04-29 12:41 ` erik quanstrom 2007-04-29 16:00 ` Joel C. Salomon 2007-04-28 21:24 ` Roman Shaposhnik 2007-05-06 12:36 erik quanstrom 2007-05-06 15:18 ` lucio 2007-05-06 16:23 ` W B Hacker 2007-05-06 17:53 ` Benn Newman 2007-05-06 17:56 ` Francisco J Ballesteros
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).