* LLVM--Low Level Virtual Machine--and Ada @ 2007-07-18 3:56 Jerry 2007-07-18 7:24 ` Georg Bauhaus ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Jerry @ 2007-07-18 3:56 UTC (permalink / raw) I've been hearing a lot lately about LLVM, the Low Level Virtual Machine. Apparently it is kind of like the gcc arrangement with a front-end and back-end for compilers. The difference with the LLVM is that it is supposed "super easy" to make a front end. So naturally one wonders, What is the likelihood of Ada being supported? http://llvm.org/ Jerry ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-18 3:56 LLVM--Low Level Virtual Machine--and Ada Jerry @ 2007-07-18 7:24 ` Georg Bauhaus 2007-07-18 7:48 ` Duncan Sands 2007-07-21 22:04 ` anon 2 siblings, 0 replies; 30+ messages in thread From: Georg Bauhaus @ 2007-07-18 7:24 UTC (permalink / raw) Jerry wrote: > I've been hearing a lot lately about LLVM, the Low Level Virtual > Machine. Apparently it is kind of like the gcc arrangement with a > front-end and back-end for compilers. The difference with the LLVM is > that it is supposed "super easy" to make a front end. So naturally one > wonders, What is the likelihood of Ada being supported? > IIRC, Duncan Sands has recently mentioned here that he will be porting GNAT soon. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-18 3:56 LLVM--Low Level Virtual Machine--and Ada Jerry 2007-07-18 7:24 ` Georg Bauhaus @ 2007-07-18 7:48 ` Duncan Sands 2007-07-19 14:30 ` Maxim Reznik 2007-07-21 22:04 ` anon 2 siblings, 1 reply; 30+ messages in thread From: Duncan Sands @ 2007-07-18 7:48 UTC (permalink / raw) To: comp.lang.ada; +Cc: Jerry On Wednesday 18 July 2007 05:56:35 Jerry wrote: > I've been hearing a lot lately about LLVM, the Low Level Virtual > Machine. Apparently it is kind of like the gcc arrangement with a > front-end and back-end for compilers. The difference with the LLVM is > that it is supposed "super easy" to make a front end. So naturally one > wonders, What is the likelihood of Ada being supported? > > http://llvm.org/ Hi Jerry, I'm porting GNAT to it. Most likely it will not be in the next LLVM release, but in the one after that. However it should be possible to check out a development version in the near future. I will post an announcement here once something usable is publically available. It works quite well in my development tree, for example all the ACATS tests pass except for a bunch of tasking tests (I don't know why those fail yet). Duncan. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-18 7:48 ` Duncan Sands @ 2007-07-19 14:30 ` Maxim Reznik 2007-07-19 14:56 ` Duncan Sands [not found] ` <200707191656.27602.baldrick@free.fr> 0 siblings, 2 replies; 30+ messages in thread From: Maxim Reznik @ 2007-07-19 14:30 UTC (permalink / raw) On 18 , 10:48, Duncan Sands <baldr...@free.fr> wrote: > Hi Jerry, I'm porting GNAT to it. Most likely it will not be in the I read llvm specification long time ago. There weren't many operations needed to run Ada programs on it. Such as overflow checks on integer arithmetic (even divide by 0), variable access from nested subprogram by lexical level, allocation in stack variables of unknown (till runtime) size, multitasking, asynchronouse jumps, (what else?) Has anything changed? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-19 14:30 ` Maxim Reznik @ 2007-07-19 14:56 ` Duncan Sands [not found] ` <200707191656.27602.baldrick@free.fr> 1 sibling, 0 replies; 30+ messages in thread From: Duncan Sands @ 2007-07-19 14:56 UTC (permalink / raw) To: comp.lang.ada; +Cc: Maxim Reznik Hi Maxim, > I read llvm specification long time ago. There weren't many operations > needed to run Ada programs on it. Such as overflow checks on integer > arithmetic (even divide by 0), these are generated as explicit conditional statements by the front-end, the same as for gcc, so no special LLVM support needed here. If it had special support that would be great of course. But it is no worse than gcc in this respect. > variable access from nested subprogram by lexical level I've implemented nested functions and (for the intel x86) pointers to nested functions. > , allocation in stack variables of unknown (till runtime) size All these kinds of variable size things have been implemented. > , multitasking, These is done using library calls, so no special support is needed. > asynchronouse jumps, The only such jumps are for exception handling. I recently helped complete the LLVM exception handling implementation. > what else?) Nothing, or at least nothing that I haven't already done. > Has anything changed? Yes, someone sat down and did the work :) Ciao, Duncan. ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <200707191656.27602.baldrick@free.fr>]
* Re: LLVM--Low Level Virtual Machine--and Ada [not found] ` <200707191656.27602.baldrick@free.fr> @ 2007-07-19 15:03 ` Duncan Sands 2007-07-19 21:30 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Duncan Sands @ 2007-07-19 15:03 UTC (permalink / raw) To: comp.lang.ada; +Cc: Maxim Reznik PS: the only thing that needed new LLVM functionality, i.e. functionality that didn't exist and wasn't being worked on, was pointers to nested functions. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-19 15:03 ` Duncan Sands @ 2007-07-19 21:30 ` Robert A Duff 2007-07-20 7:44 ` Duncan Sands 0 siblings, 1 reply; 30+ messages in thread From: Robert A Duff @ 2007-07-19 21:30 UTC (permalink / raw) Duncan Sands <baldrick@free.fr> writes: > PS: the only thing that needed new LLVM functionality, > i.e. functionality that didn't exist and wasn't being > worked on, was pointers to nested functions. How did you implement those? GNAT uses trampolines, which are less than ideal for several reasons. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-19 21:30 ` Robert A Duff @ 2007-07-20 7:44 ` Duncan Sands 2007-07-20 14:06 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Duncan Sands @ 2007-07-20 7:44 UTC (permalink / raw) To: comp.lang.ada; +Cc: Robert A Duff > > PS: the only thing that needed new LLVM functionality, > > i.e. functionality that didn't exist and wasn't being > > worked on, was pointers to nested functions. > > How did you implement those? > > GNAT uses trampolines, which are less than ideal > for several reasons. Hi Bob, I used trampolines. I really couldn't do it any other way without a bunch of modifications to the GNAT front-end. Also, this seems to be the only solution if you want to be able to pass such pointers to foreign language routines, which seems nice to have if not essential. The major downside I see is that they seem to be extremely expensive, presumably because you take an icache hit every time you jump to the stack. I plan to implement a bunch of small optimizations which may help, such as converting direct calls to trampolines into direct calls to the nested functions (inlining hopefully will create such direct calls). Any suggestions for a better approach than trampolines? I'm also curious to hear what the other less than ideal properties of trampolines are! Ciao, Duncan. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-20 7:44 ` Duncan Sands @ 2007-07-20 14:06 ` Robert A Duff 2007-07-21 13:09 ` Tero Koskinen 2007-07-23 7:47 ` Duncan Sands 0 siblings, 2 replies; 30+ messages in thread From: Robert A Duff @ 2007-07-20 14:06 UTC (permalink / raw) Duncan Sands <baldrick@free.fr> writes: >> > PS: the only thing that needed new LLVM functionality, >> > i.e. functionality that didn't exist and wasn't being >> > worked on, was pointers to nested functions. >> >> How did you implement those? >> >> GNAT uses trampolines, which are less than ideal >> for several reasons. > > Hi Bob, I used trampolines. I really couldn't do it any other > way without a bunch of modifications to the GNAT front-end. > Also, this seems to be the only solution if you want to be able > to pass such pointers to foreign language routines, which seems > nice to have if not essential. The major downside I see is that > they seem to be extremely expensive, presumably because you take > an icache hit every time you jump to the stack. I plan to implement > a bunch of small optimizations which may help, such as converting > direct calls to trampolines into direct calls to the nested functions > (inlining hopefully will create such direct calls). Any suggestions > for a better approach than trampolines? I'm also curious to hear > what the other less than ideal properties of trampolines are! The main problem with trampolines is what you said -- they're slow. Another problem is that some modern machines use DEP (which I think stands for "data execution prevention" or something like that). DEP means the operating system prevents writeable data from being executed as code. The purpose is to prevent certain kinds of security holes that are common in languages that don't do array-bounds checking. But DEP prevents trampolines from working, so users have to turn it off in order to run some Ada programs (such as the compiler). It's a pain because users get some mysterious error message when trampolines are used. Another problem (I've heard) is that there's at least one machine supported by gcc where trampolines don't work. I don't remember which machine, and I don't even know for sure that this is true. The alternative to trampolines is to represent access-to-nested-subprogram as a pair, sometimes called a "fat pointer": (address-of-code, static link). AdaCore is thinking about doing this at some point. You are correct that this won't work when interfacing to C. The answer is: if the Convention of the access type is C, and the procedure is nested, use a trampoline. Trampolines are probably also required for 'Unrestricted_Access, because it allows you to bypass the normal accessibility rules. Access-to-nested subp is much more important in Ada 2005 than in Ada 95, because we now have downward closures. (See the Iterate procedures in the Containers packages for examples.) When using downward closures, you almost always want nested subprograms. (Downward closures are one of my favorite features, by the way.) Another issue is nested type extensions -- dispatch tables contain pointers to subprograms. E.g. type T1 is library level, and "T2 is new T1" is nested. The primitives of T2 need a static link. You don't want to store static links for T1 -- that would be a distributed overhead. T2's primitives can be trampolines, but that's inefficient. There's a trick mentioned in the AI that introduced this feature: store the static link as an implicit component of T2. T2's primitives can be a wrapper that loads the static link and then calls the user-defined code. This eliminates any overhead on T1, and is still more efficient than trampolines for T2. See the AI for details. One use for nested type extensions is when you want a Finalize procedure of a controlled type to be nested. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-20 14:06 ` Robert A Duff @ 2007-07-21 13:09 ` Tero Koskinen 2007-07-23 7:47 ` Duncan Sands 1 sibling, 0 replies; 30+ messages in thread From: Tero Koskinen @ 2007-07-21 13:09 UTC (permalink / raw) On Fri, 20 Jul 2007 10:06:25 -0400 Robert A Duff wrote: > Another problem is that some modern machines use DEP (which I think > stands for "data execution prevention" or something like that). DEP > means the operating system prevents writeable data from being executed > as code. For example, OpenBSD people call this technique W^X (write xor execute). It is enabled on sparc{,64}, alpha, i386, amd64, and hppa architectures. > But DEP prevents trampolines from working, so users have to turn > it off in order to run some Ada programs (such as the compiler). > It's a pain because users get some mysterious error message > when trampolines are used. Presentation slide(s) at http://www.openbsd.org/papers/ven05-deraadt/mgp00012.html tells how OpenBSD handles trampolines and non-executable stack. In addition, OpenBSD's gcc-local(1) manual page says: - On most architectures, trampoline code marks the smallest possible area around the trampoline stub executable using mprotect(2), since the stack area is by default non-executable. I don't personally know all the technical details, but above information would suggest that it is somehow possible to use trampolines and DEP/W^X together. From user viewpoint everything "just works". I can compile (almost) vanilla gcc 4.2 with Ada support on OpenBSD and then use it to compile normal Ada code. The operating system and the compiler(s) handle the memory protection details behind the curtains and I don't need to worry about it. No pain involved. :) -- Tero Koskinen - http://iki.fi/tero.koskinen/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-20 14:06 ` Robert A Duff 2007-07-21 13:09 ` Tero Koskinen @ 2007-07-23 7:47 ` Duncan Sands 2007-07-24 2:12 ` Randy Brukardt 1 sibling, 1 reply; 30+ messages in thread From: Duncan Sands @ 2007-07-23 7:47 UTC (permalink / raw) To: comp.lang.ada; +Cc: Robert A Duff Hi Bob, thanks for your informative reply. > Another problem is that some modern machines use DEP (which I think > stands for "data execution prevention" or something like that). DEP > means the operating system prevents writeable data from being executed > as code. The purpose is to prevent certain kinds of security holes > that are common in languages that don't do array-bounds checking. > But DEP prevents trampolines from working, so users have to turn > it off in order to run some Ada programs (such as the compiler). > It's a pain because users get some mysterious error message > when trampolines are used. I'm not sure that this is a problem anymore: gcc uses a bunch of tricks (eg: setting a flag on the program that notes it runs code on the stack) to inform the operating system that the trampoline is kosher IIRC. That said, I haven't tried to implement any of this in LLVM yet, which is also why I'm vague on the details. > Another problem (I've heard) is that there's at least one machine > supported by gcc where trampolines don't work. I don't remember which > machine, and I don't even know for sure that this is true. All architectures currently supported by LLVM support trampolines in gcc. Ciao, Duncan. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-23 7:47 ` Duncan Sands @ 2007-07-24 2:12 ` Randy Brukardt 2007-07-24 8:03 ` Duncan Sands 2007-07-24 23:28 ` Robert A Duff 0 siblings, 2 replies; 30+ messages in thread From: Randy Brukardt @ 2007-07-24 2:12 UTC (permalink / raw) "Duncan Sands" <baldrick@free.fr> wrote in message news:mailman.6.1185176858.3834.comp.lang.ada@ada-france.org... > Hi Bob, thanks for your informative reply. > > > Another problem is that some modern machines use DEP (which I think > > stands for "data execution prevention" or something like that). DEP > > means the operating system prevents writeable data from being executed > > as code. The purpose is to prevent certain kinds of security holes > > that are common in languages that don't do array-bounds checking. > > But DEP prevents trampolines from working, so users have to turn > > it off in order to run some Ada programs (such as the compiler). > > It's a pain because users get some mysterious error message > > when trampolines are used. > > I'm not sure that this is a problem anymore: gcc uses a bunch of tricks > (eg: setting a flag on the program that notes it runs code on the stack) > to inform the operating system that the trampoline is kosher IIRC. That > said, I haven't tried to implement any of this in LLVM yet, which is also > why I'm vague on the details. That would be bad, as it would effectively turn of DEP for LLVM programs. These error detections are critically needed and turning them off just means you have buggy software that you can't/won't fix and that you're willing to remain part of the problem. Honestly, I never understood why programs *ever* needed to execute permission on stack and data. When we did our first 32-bit compilers, I kept those segments completely separate and was dismayed to find out that we couldn't set the permissions on the segments to actually match the uses (and thus detect bugs earlier). I managed to get the DOS extender versions sort-of-right by discarding the overlapping writable segments given to us by the OS and creating new non-overlapping ones for the data and stack. But neither Unix nor Windows provided anything that helped at all. I find it bizarre to find people deciding to apply the obvious technique of least privilege nearly 20 years later - what the heck have they been doing in the mean time? (Not caring if software is correct is one obvious answer...) Janus/Ada has never used any executable data/stack in its 32-bit versions; such code would save no more than a clock cycle or two (out of hundreds or thousands) and as such could not be significant. We use compiler-generated thunks rather than run-time generated trampolines, and I'm not sure why anyone would use the latter (given that they increase the exploitability of a program). Most be something I don't understand... Randy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 2:12 ` Randy Brukardt @ 2007-07-24 8:03 ` Duncan Sands 2007-07-24 9:50 ` Colin Paul Gloster 2007-07-24 19:21 ` Randy Brukardt 2007-07-24 23:28 ` Robert A Duff 1 sibling, 2 replies; 30+ messages in thread From: Duncan Sands @ 2007-07-24 8:03 UTC (permalink / raw) To: comp.lang.ada; +Cc: Randy Brukardt Hi Randy, > Janus/Ada has never used any executable data/stack in its 32-bit versions; > such code would save no more than a clock cycle or two (out of hundreds or > thousands) and as such could not be significant. We use compiler-generated > thunks rather than run-time generated trampolines, and I'm not sure why > anyone would use the latter (given that they increase the exploitability of > a program). Most be something I don't understand... how do these thunks work? Thanks, Duncan. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 8:03 ` Duncan Sands @ 2007-07-24 9:50 ` Colin Paul Gloster 2007-07-24 10:47 ` Markus E Leypold 2007-07-24 19:21 ` Randy Brukardt 1 sibling, 1 reply; 30+ messages in thread From: Colin Paul Gloster @ 2007-07-24 9:50 UTC (permalink / raw) On 2007-07-24, Duncan Sands <baldrick@free.fr> wrote: |-----------------------------------------------------------------------------| |" Hi Randy, | | | |> Janus/Ada has never used any executable data/stack in its 32-bit versions; | |> such code would save no more than a clock cycle or two (out of hundreds or | |> thousands) and as such could not be significant. We use compiler-generated | |> thunks rather than run-time generated trampolines, and I'm not sure why | |> anyone would use the latter (given that they increase the exploitability of| |> a program). Most be something I don't understand... | | | | how do these thunks work? | | | | Thanks, | | | | Duncan." | |-----------------------------------------------------------------------------| You should pay RR Software for a source code license to obtain that information. Regards, Colin Paul Gloster ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 9:50 ` Colin Paul Gloster @ 2007-07-24 10:47 ` Markus E Leypold 2007-07-25 12:12 ` Colin Paul Gloster 0 siblings, 1 reply; 30+ messages in thread From: Markus E Leypold @ 2007-07-24 10:47 UTC (permalink / raw) > On 2007-07-24, Duncan Sands <baldrick@free.fr> wrote: > > |-----------------------------------------------------------------------------| > |" Hi Randy, | > | | > |> Janus/Ada has never used any executable data/stack in its 32-bit versions; | > |> such code would save no more than a clock cycle or two (out of hundreds or | > |> thousands) and as such could not be significant. We use compiler-generated | > |> thunks rather than run-time generated trampolines, and I'm not sure why | > |> anyone would use the latter (given that they increase the exploitability of| > |> a program). Most be something I don't understand... | > | | > | how do these thunks work? | > | | > | Thanks, | > | | > | Duncan." | > |-----------------------------------------------------------------------------| > > You should pay RR Software for a source code license to obtain that > information. You speaking for RR software? AFAIR, Randy has been very forward and frank in the past to discuss compiler implementation (many thanks to him: I usually learn something from his posts). How do I have to understand the "should" in this sentence then? - It's a moral obligation. - Randy has changed the rules: Thunks (as opposed to other details) are only being disclosed against money. - ... Regards -- Markus ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 10:47 ` Markus E Leypold @ 2007-07-25 12:12 ` Colin Paul Gloster 2007-07-25 12:59 ` Markus E Leypold 0 siblings, 1 reply; 30+ messages in thread From: Colin Paul Gloster @ 2007-07-25 12:12 UTC (permalink / raw) On 2007-07-24, Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote: |---------------------------------------------------------------------------------| |"> On 2007-07-24, Duncan Sands <baldrick@free.fr> wrote: | |> | |> |-----------------------------------------------------------------------------|| |> |" Hi Randy, || |> | || |> |> Janus/Ada has never used any executable data/stack in its 32-bit versions; || |> |> such code would save no more than a clock cycle or two (out of hundreds or || |> |> thousands) and as such could not be significant. We use compiler-generated || |> |> thunks rather than run-time generated trampolines, and I'm not sure why || |> |> anyone would use the latter (given that they increase the exploitability of|| |> |> a program). Most be something I don't understand... || |> | || |> | how do these thunks work? || |> | || |> | Thanks, || |> | || |> | Duncan." || |> |-----------------------------------------------------------------------------|| |> | |> You should pay RR Software for a source code license to obtain that | |> information. | | | | You speaking for RR software? AFAIR, Randy has been very forward and | | frank in the past to discuss compiler implementation (many thanks to | | him: I usually learn something from his posts). How do I have to | | understand the "should" in this sentence then? | | | | - It's a moral obligation. | | | | - Randy has changed the rules: Thunks (as opposed to other details) | | are only being disclosed against money. | | | | - ..." | |---------------------------------------------------------------------------------| I do not work for RR Software. As in the past, RR Software has a pricelist including listing money in exchange for an implementation's source code ( WWW.RRSoftware.com/html/companyinf/prices.htm ). Randy has been and continues to be very informative even when not charging money for such help. You may wish to look at the rather detailed news:f85jbd$mgj$1@jacob-sparre.dk and the subsequent posts in that subthread, which though detailed are still not as thorough an answer as the source code, which quite rightly costs money. Regards, Colin Paul Gloster ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-25 12:12 ` Colin Paul Gloster @ 2007-07-25 12:59 ` Markus E Leypold 0 siblings, 0 replies; 30+ messages in thread From: Markus E Leypold @ 2007-07-25 12:59 UTC (permalink / raw) > On 2007-07-24, Markus E Leypold > <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote: > |> | > |> You should pay RR Software for a source code license to obtain that | > |> information. | > | | > | You speaking for RR software? AFAIR, Randy has been very forward and | > | frank in the past to discuss compiler implementation (many thanks to | > | him: I usually learn something from his posts). How do I have to | > | understand the "should" in this sentence then? | > | | > | - It's a moral obligation. | > | | > | - Randy has changed the rules: Thunks (as opposed to other details) | > | are only being disclosed against money. | > | | > | - ..." | > |---------------------------------------------------------------------------------| > > I do not work for RR Software. As in the past, RR Software has a > pricelist including listing money in exchange for an implementation's > source code ( > WWW.RRSoftware.com/html/companyinf/prices.htm And that relates to Duncan's question how? > ). Randy has been and continues to be very informative even when not Exactly. But as I understood it, Duncan was only interested in knowing how compilers work (and in the thunk vs. trampolines trade off). Suggesting that he buys the source (which after all contains no essay on the conceptual issues involved) strikes me as somewhat surreal. Like suggesting to someone who asks how car gear boxes work, to buy plans of a specific car: It might enable one to build the same car, but won't help to understand the principles of gear box construction. > charging money for such help. You may wish to look at the rather Why would I wish? For what? > detailed news:f85jbd$mgj$1@jacob-sparre.dk and the subsequent posts > in that subthread, which though detailed are still not as thorough > an answer as the source code, which quite rightly costs money. (Which nobody ever doubted: Only that was not the topic; Nobody in this thread asked for the source code and certainly not for free. So why do you write "rightly" as if anybody tried to deny RR sofware the right?) Not to be unthankful: But if Randy thought he's getting exploited here at c.l.a., I think he'd either fall silent or raise the topic of consultation against payment himself. Frankly, I'm appalled how you insuate that - someone is trying to rip Randy off. - that it should be normal that you pay for answers in usenet. Regarding the latter, I thought (up to now) that Usenet is a free and public forum -- not a platform to sell consulting services. Participation is voluntary. If one doesn't want to answer questions, there is a simple solution: Just say no or nothing. Or don't write to newsgroups because it doesn't figure in your corporate planning and doesn't bring money (like a well known compiler vendor doesn't do it any more). Regards -- Markus ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 8:03 ` Duncan Sands 2007-07-24 9:50 ` Colin Paul Gloster @ 2007-07-24 19:21 ` Randy Brukardt 2007-07-24 19:36 ` Duncan Sands 1 sibling, 1 reply; 30+ messages in thread From: Randy Brukardt @ 2007-07-24 19:21 UTC (permalink / raw) "Duncan Sands" <baldrick@free.fr> wrote in message news:mailman.7.1185264194.3834.comp.lang.ada@ada-france.org... ... > > Janus/Ada has never used any executable data/stack in its 32-bit versions; > > such code would save no more than a clock cycle or two (out of hundreds or > > thousands) and as such could not be significant. We use compiler-generated > > thunks rather than run-time generated trampolines, and I'm not sure why > > anyone would use the latter (given that they increase the exploitability of > > a program). Most be something I don't understand... > > how do these thunks work? Generally, the compiler passes the address of the thunk to wherever it is needed, and it is called indirectly. The thunks themselves adjust the parameters as needed and call the real routine. This is necessarily a very general description; we use many different kinds of thunks, and the details are different for each. There are some where the address of the routine to call is passed in as well; some of them are just wrappers, and some implement entire operations (like an allocator). In general, the front end generates the thunks; the back end knows about them for optimization and debugger and error message purposes, but it doesn't generate any. I would expect it to be fairly hard to retrofit them if the front end is insisting on doing something else. (It's also possible that trampolines are much faster on some architectures; I've primarily looked at the x86 machines where there is little advantage.) Randy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 19:21 ` Randy Brukardt @ 2007-07-24 19:36 ` Duncan Sands 2007-07-24 19:58 ` Randy Brukardt 0 siblings, 1 reply; 30+ messages in thread From: Duncan Sands @ 2007-07-24 19:36 UTC (permalink / raw) To: comp.lang.ada; +Cc: Randy Brukardt Hi Randy, > > how do these thunks work? > > Generally, the compiler passes the address of the thunk to wherever it is > needed, and it is called indirectly. The thunks themselves adjust the > parameters as needed and call the real routine. presumably pointers to nested functions are "fat pointers" containing both the identity of the nested function (equivalently, the identity of a "thunk" that knows about the nested function) and also some kind of pointer into the stack of the parent of the nested function. Is that right? Thanks, Duncan. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 19:36 ` Duncan Sands @ 2007-07-24 19:58 ` Randy Brukardt 0 siblings, 0 replies; 30+ messages in thread From: Randy Brukardt @ 2007-07-24 19:58 UTC (permalink / raw) "Duncan Sands" <baldrick@free.fr> wrote in message news:mailman.8.1185305754.3834.comp.lang.ada@ada-france.org... > Hi Randy, > > > > how do these thunks work? > > > > Generally, the compiler passes the address of the thunk to wherever it is > > needed, and it is called indirectly. The thunks themselves adjust the > > parameters as needed and call the real routine. > > presumably pointers to nested functions are "fat pointers" containing > both the identity of the nested function (equivalently, the identity of > a "thunk" that knows about the nested function) and also some kind of > pointer into the stack of the parent of the nested function. Is that > right? Janus/Ada uses displays rather than static links (that was originally a requirement of the University project that led to Janus/Ada, and we never changed it), so in most cases, you don't need any special stack pointers. (You only need them when you call to a place that is outside of the normal nesting of subprograms.) There are some cases when you do need them, and in those cases we need to provide a replacement display. That is usually saved in a well-known place (i.e., for shared generics it is part of the generic data block) and shared with a number of related thunks, although for anonymous-access-to-subprogram it will be part of the pointer. Even in these cases, we determine in the thunk how much of the display needs to be replaced (it is often none) so as to keep the overhead to a minimum, and all of this code is part of the thunk, not part of the call site. Randy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 2:12 ` Randy Brukardt 2007-07-24 8:03 ` Duncan Sands @ 2007-07-24 23:28 ` Robert A Duff 2007-07-25 0:39 ` Randy Brukardt 1 sibling, 1 reply; 30+ messages in thread From: Robert A Duff @ 2007-07-24 23:28 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "Duncan Sands" <baldrick@free.fr> wrote in message > news:mailman.6.1185176858.3834.comp.lang.ada@ada-france.org... >> Hi Bob, thanks for your informative reply. >> >> > Another problem is that some modern machines use DEP (which I think >> > stands for "data execution prevention" or something like that). DEP >> > means the operating system prevents writeable data from being executed >> > as code. The purpose is to prevent certain kinds of security holes >> > that are common in languages that don't do array-bounds checking. >> > But DEP prevents trampolines from working, so users have to turn >> > it off in order to run some Ada programs (such as the compiler). >> > It's a pain because users get some mysterious error message >> > when trampolines are used. >> >> I'm not sure that this is a problem anymore: gcc uses a bunch of tricks >> (eg: setting a flag on the program that notes it runs code on the stack) >> to inform the operating system that the trampoline is kosher IIRC. That >> said, I haven't tried to implement any of this in LLVM yet, which is also >> why I'm vague on the details. > > That would be bad, as it would effectively turn of DEP for LLVM programs. > These error detections are critically needed and turning them off just means > you have buggy software that you can't/won't fix and that you're willing to > remain part of the problem. Are you saying that executable data necessarily means the program is buggy? If so, I don't agree. Trampolines are not bugs. They're slow. Turning off DEP might expose _other_ bugs that cause security holes, but those can be detected/prevented by array-bounds checking and the like. The need for DEP is really because we live in a C world. And DEP doesn't even solve the problem. > Honestly, I never understood why programs *ever* needed to execute > permission on stack and data. There are several legitimate reasons why a program might want to execute data. For example, consider a JIT compiler. >... When we did our first 32-bit compilers, I kept > those segments completely separate and was dismayed to find out that we > couldn't set the permissions on the segments to actually match the uses (and > thus detect bugs earlier). I managed to get the DOS extender versions > sort-of-right by discarding the overlapping writable segments given to us by > the OS and creating new non-overlapping ones for the data and stack. But > neither Unix nor Windows provided anything that helped at all. I find it > bizarre to find people deciding to apply the obvious technique of least > privilege nearly 20 years later - what the heck have they been doing in the > mean time? (Not caring if software is correct is one obvious answer...) I agree with you about "least privilege". To me, that means that writeable stack/data areas should be no-execute by default. But a program should be allowed to change that. > Janus/Ada has never used any executable data/stack in its 32-bit versions; > such code would save no more than a clock cycle or two (out of hundreds or > thousands) and as such could not be significant. On the contrary, trampolines do not save a clock cycle or two -- they are horribly slow! >...We use compiler-generated > thunks rather than run-time generated trampolines, and I'm not sure why > anyone would use the latter (given that they increase the exploitability of > a program). Most be something I don't understand... Here's the reason for trampolines: The gcc dialect of C allows nested functions (unlike standard C). They wanted to allow pointers to these functions. They wanted to make those pointers fit in one machine word, for two reasons: Some C programs might assume a pointer-to-function has that representation (a single address -- of code). Programs that obey the standard (i.e. do not nest functions) should not pay extra (no distributed overhead). A pointer-to-nested function needs access to the function's environment, and the only way to do that, while keeping such a pointer in a single word, is trampolines. Trampolines are not efficient! Because after writing the code, the instruction cache needs to be flushed before calling the thing -- that is expensive on modern machines. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-24 23:28 ` Robert A Duff @ 2007-07-25 0:39 ` Randy Brukardt 2007-07-25 2:00 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Randy Brukardt @ 2007-07-25 0:39 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccvec95qld.fsf@shell01.TheWorld.com... > "Randy Brukardt" <randy@rrsoftware.com> writes: > > > "Duncan Sands" <baldrick@free.fr> wrote in message > > news:mailman.6.1185176858.3834.comp.lang.ada@ada-france.org... ... > >> I'm not sure that this is a problem anymore: gcc uses a bunch of tricks > >> (eg: setting a flag on the program that notes it runs code on the stack) > >> to inform the operating system that the trampoline is kosher IIRC. That > >> said, I haven't tried to implement any of this in LLVM yet, which is also > >> why I'm vague on the details. > > > > That would be bad, as it would effectively turn of DEP for LLVM programs. > > These error detections are critically needed and turning them off just means > > you have buggy software that you can't/won't fix and that you're willing to > > remain part of the problem. > > Are you saying that executable data necessarily means the program is > buggy? If so, I don't agree. Trampolines are not bugs. They're slow. > Turning off DEP might expose _other_ bugs that cause security holes, but > those can be detected/prevented by array-bounds checking and the like. No, but I am saying that the vast majority of programs have no need for executable data. Which includes virtually all Ada programs, and it is bad to be turning off things which protects the program from bugs. > The need for DEP is really because we live in a C world. > And DEP doesn't even solve the problem. Of course it doesn't "solve" the problem, but it surely helps. And remember that even Ada programs have to call C code to access OS facilities and the like. Probably 50% of the bugs (and by far the worst ones) are in those interfaces, where the checking of Ada is no help. (And another 10% is compiler bugs that would have been detected by DEP; overwriting the return address of something is probably the most common symptom of compiler bugs that I have to track down. That may be because those are the hardest to find...) > > Honestly, I never understood why programs *ever* needed to execute > > permission on stack and data. > > There are several legitimate reasons why a program might want to execute > data. For example, consider a JIT compiler. Sure, but how many people are writing JIT compilers or overlay managers so they can get 2 megabytes of compiler code to execute on a 640K MS-DOS machine?? Hardly anyone, and people who need to do such things should be put through extreme hoops before being allowed to do so. (I'd suggest that they be required to write all of the JIT code in SPARC or a similar proof system, except that SPARC won't allow such dymamic things -- it's major failing IMHO.) > >... When we did our first 32-bit compilers, I kept > > those segments completely separate and was dismayed to find out that we > > couldn't set the permissions on the segments to actually match the uses (and > > thus detect bugs earlier). I managed to get the DOS extender versions > > sort-of-right by discarding the overlapping writable segments given to us by > > the OS and creating new non-overlapping ones for the data and stack. But > > neither Unix nor Windows provided anything that helped at all. I find it > > bizarre to find people deciding to apply the obvious technique of least > > privilege nearly 20 years later - what the heck have they been doing in the > > mean time? (Not caring if software is correct is one obvious answer...) > > I agree with you about "least privilege". To me, that means that > writeable stack/data areas should be no-execute by default. But a > program should be allowed to change that. Yes, possibly only with extreme permission. > > Janus/Ada has never used any executable data/stack in its 32-bit versions; > > such code would save no more than a clock cycle or two (out of hundreds or > > thousands) and as such could not be significant. > > On the contrary, trampolines do not save a clock cycle or two -- they > are horribly slow! Then why use them for Ada? Ada surely doesn't require them. > >...We use compiler-generated > > thunks rather than run-time generated trampolines, and I'm not sure why > > anyone would use the latter (given that they increase the exploitability of > > a program). Most be something I don't understand... > > Here's the reason for trampolines: > > The gcc dialect of C allows nested functions (unlike standard C). > > They wanted to allow pointers to these functions. > > They wanted to make those pointers fit in one machine word, > for two reasons: > > Some C programs might assume a pointer-to-function has that > representation (a single address -- of code). > > Programs that obey the standard (i.e. do not nest functions) should > not pay extra (no distributed overhead). > > A pointer-to-nested function needs access to the function's environment, > and the only way to do that, while keeping such a pointer in a single > word, is trampolines. That's not quite true, as the use of displays rather than static links would allow up-level access without any fat pointers. Although they might have wanted non-nested access, for which that wouldn't work. (Non-nested access shouldn't work IMHO, because of the significant risk that the stack frames no longer exist when the routine is called. That's the reason the anonymous access-to-subprogram parameters can't be converted to other kinds of access-to-subprogram.) In any case, Ada has restrictions such that these aren't needed for most access-to-subprograms, and fat pointers are fine for anonymous access-to-subprogram parameters (because you can't give these a convention and thus they don't need to be interoperable with C or anything else). GNAT is probably screwed though, because of the mistake of 'Unrestricted_Access for subprograms. Still, I think GNAT should do what it can to avoid them; most Ada access-to-subprogram types don't need them (although you would have to insist on having convention C on those types that are intended for interface use; perhaps that would be unacceptable). > Trampolines are not efficient! Because after writing the code, the > instruction cache needs to be flushed before calling the thing -- that > is expensive on modern machines. True. Thunks have similar issues in that the address of the thing isn't known before the call (so there is a pipeline stall), but at least we don't have to flush the cache. And there sometimes is the possibility of in-lining the call (something we don't currently do, but it is on the radar). Randy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-25 0:39 ` Randy Brukardt @ 2007-07-25 2:00 ` Robert A Duff 2007-07-25 13:14 ` Duncan Sands 0 siblings, 1 reply; 30+ messages in thread From: Robert A Duff @ 2007-07-25 2:00 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message > news:wccvec95qld.fsf@shell01.TheWorld.com... >> "Randy Brukardt" <randy@rrsoftware.com> writes: >> >> > "Duncan Sands" <baldrick@free.fr> wrote in message >> > news:mailman.6.1185176858.3834.comp.lang.ada@ada-france.org... > ... >> >> I'm not sure that this is a problem anymore: gcc uses a bunch of tricks >> >> (eg: setting a flag on the program that notes it runs code on the > stack) >> >> to inform the operating system that the trampoline is kosher IIRC. > That >> >> said, I haven't tried to implement any of this in LLVM yet, which is > also >> >> why I'm vague on the details. >> > >> > That would be bad, as it would effectively turn of DEP for LLVM > programs. >> > These error detections are critically needed and turning them off just > means >> > you have buggy software that you can't/won't fix and that you're willing > to >> > remain part of the problem. >> >> Are you saying that executable data necessarily means the program is >> buggy? If so, I don't agree. Trampolines are not bugs. They're slow. >> Turning off DEP might expose _other_ bugs that cause security holes, but >> those can be detected/prevented by array-bounds checking and the like. > > No, but I am saying that the vast majority of programs have no need for > executable data. Which includes virtually all Ada programs, and it is bad to > be turning off things which protects the program from bugs. Agreed. >> The need for DEP is really because we live in a C world. >> And DEP doesn't even solve the problem. > > Of course it doesn't "solve" the problem, but it surely helps. Well, maybe, but security issues invoke the "weakest link in the chain" problem. >... And remember > that even Ada programs have to call C code to access OS facilities and the > like. That's what I meant by, "we live in a C world." ;-) >> I agree with you about "least privilege". To me, that means that >> writeable stack/data areas should be no-execute by default. But a >> program should be allowed to change that. > > Yes, possibly only with extreme permission. Not sure what you mean by "extreme". A process may or may not have permission to read/write/execute certain pages of memory, and may or may not have permission to change its permisions... >> > Janus/Ada has never used any executable data/stack in its 32-bit > versions; >> > such code would save no more than a clock cycle or two (out of hundreds > or >> > thousands) and as such could not be significant. >> >> On the contrary, trampolines do not save a clock cycle or two -- they >> are horribly slow! > > Then why use them for Ada? Ada surely doesn't require them. Correct. Ada itself does not require trampolines. So why use them? Well, I suppose it was an easy implementation. They could be got rid of, except in the cases of interface-to-C, and 'Unrestricted_Access. >> >...We use compiler-generated >> > thunks rather than run-time generated trampolines, and I'm not sure why >> > anyone would use the latter (given that they increase the exploitability > of >> > a program). Most be something I don't understand... >> >> Here's the reason for trampolines: >> >> The gcc dialect of C allows nested functions (unlike standard C). >> >> They wanted to allow pointers to these functions. >> >> They wanted to make those pointers fit in one machine word, >> for two reasons: >> >> Some C programs might assume a pointer-to-function has that >> representation (a single address -- of code). >> >> Programs that obey the standard (i.e. do not nest functions) should >> not pay extra (no distributed overhead). >> >> A pointer-to-nested function needs access to the function's environment, >> and the only way to do that, while keeping such a pointer in a single >> word, is trampolines. > > That's not quite true, as the use of displays rather than static links would > allow up-level access without any fat pointers. I don't get it (how displays help, here). If you have displays instead of static links, you need to pass display, or pointers to them. >...Although they might have > wanted non-nested access, for which that wouldn't work. (Non-nested access > shouldn't work IMHO, because of the significant risk that the stack frames > no longer exist when the routine is called. I agree, but that's how it works in gcc C -- you can pass a pointer to a nested function to another procedure, and that thing might save it in a global, and then call it later. It works, so long as the outer function is still active. I.e. it's unsafe. Ada prevents that sort of thing. >... That's the reason the anonymous > access-to-subprogram parameters can't be converted to other kinds of > access-to-subprogram.) > > In any case, Ada has restrictions such that these aren't needed for most > access-to-subprograms, and fat pointers are fine for anonymous > access-to-subprogram parameters Right. >...(because you can't give these a convention > and thus they don't need to be interoperable with C or anything else). GNAT > is probably screwed though, because of the mistake of 'Unrestricted_Access > for subprograms. Not "screwed". It just means that 'Unrestricted_Access might need to use trampolines. The standard Ada features can avoid them. >... Still, I think GNAT should do what it can to avoid them; Agreed. > most Ada access-to-subprogram types don't need them (although you would have > to insist on having convention C on those types that are intended for > interface use; perhaps that would be unacceptable). It's acceptable, IMHO. >> Trampolines are not efficient! Because after writing the code, the >> instruction cache needs to be flushed before calling the thing -- that >> is expensive on modern machines. > > True. Thunks have similar issues in that the address of the thing isn't > known before the call (so there is a pipeline stall), but at least we don't > have to flush the cache. And there sometimes is the possibility of in-lining > the call (something we don't currently do, but it is on the radar). Trampolines are worse than thunks, efficiency-wise. But it's only in Ada 2005 that it started to matter much. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-25 2:00 ` Robert A Duff @ 2007-07-25 13:14 ` Duncan Sands 0 siblings, 0 replies; 30+ messages in thread From: Duncan Sands @ 2007-07-25 13:14 UTC (permalink / raw) To: comp.lang.ada; +Cc: Robert A Duff > > That's not quite true, as the use of displays rather than static links would > > allow up-level access without any fat pointers. > > I don't get it (how displays help, here). If you have displays instead > of static links, you need to pass display, or pointers to them. I was wondering the same thing. > >> Trampolines are not efficient! Because after writing the code, the > >> instruction cache needs to be flushed before calling the thing -- that > >> is expensive on modern machines. > > > > True. Thunks have similar issues in that the address of the thing isn't > > known before the call (so there is a pipeline stall), but at least we don't > > have to flush the cache. And there sometimes is the possibility of in-lining > > the call (something we don't currently do, but it is on the radar). > > Trampolines are worse than thunks, efficiency-wise. > > But it's only in Ada 2005 that it started to matter much. In programs that use Ada.Containers heavily, my profiling tools regularly show "code on the stack" (i.e. trampolines) as where the program is spending most of its time. Ciao, Duncan. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-18 3:56 LLVM--Low Level Virtual Machine--and Ada Jerry 2007-07-18 7:24 ` Georg Bauhaus 2007-07-18 7:48 ` Duncan Sands @ 2007-07-21 22:04 ` anon 2007-07-22 13:22 ` Steve 2007-07-23 12:29 ` Colin Paul Gloster 2 siblings, 2 replies; 30+ messages in thread From: anon @ 2007-07-21 22:04 UTC (permalink / raw) The question should be. Should Ada be ported or is it a waste of time? The LLVM is based on RISC concept and the RISC is being replaced by the ZISC aka (Zero Instruction Set Computer). The reason is that today most newer computer systems are based on parallel cpus and artificial neural networks. While RISC and CISC are based on a single processor which came from the early days computers using time-slicing to emulate a parallel system. In today world parallel cpu are here and in the next few years should replace all single cpu system and designs such as RISC and CISC. This suggest that LLVM to be on the cuting edge, needs to alter its design structure away from the RISC and go toward true parallel design such as ZISC. But as long as LLVM is using the RISC design that is being phased out then Ada should not be ported because there are better projects that are waiting in the wings. So, when and only when LLVM updates or moves it designs to the future of computting should Ada be ported. Note: This is not a cut down on RISC processors. It is just that the world has outgrown the RISC before it had its true day in the sun. But the main problem is that both CISC and RISC that were developed in the early days of computers. We should have surpass both designed long ago, but the companies that create the CPU are still operated by those that think CISC or RISC is the way to go. It will be fun to watch those guys sell their stock as newer designs finally take hold. In <1184730995.862147.208590@g12g2000prg.googlegroups.com>, Jerry <lanceboyle@qwest.net> writes: >I've been hearing a lot lately about LLVM, the Low Level Virtual >Machine. Apparently it is kind of like the gcc arrangement with a >front-end and back-end for compilers. The difference with the LLVM is >that it is supposed "super easy" to make a front end. So naturally one >wonders, What is the likelihood of Ada being supported? > >http://llvm.org/ > >Jerry > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-21 22:04 ` anon @ 2007-07-22 13:22 ` Steve 2007-07-23 12:29 ` Colin Paul Gloster 1 sibling, 0 replies; 30+ messages in thread From: Steve @ 2007-07-22 13:22 UTC (permalink / raw) "anon" <anon@anon.org> wrote in message news:spvoi.348118$p47.256522@bgtnsc04-news.ops.worldnet.att.net... > The question should be. Should Ada be ported or is it a waste of time? It certainly make sense to create an Ada port today. The majority of CPU's available today are CISC and RISC. > The LLVM is based on RISC concept and the RISC is being replaced by > the ZISC aka (Zero Instruction Set Computer). The reason is that today > most newer computer systems are based on parallel cpus and artificial > neural networks. While RISC and CISC are based on a single processor > which came from the early days computers using time-slicing to > emulate a parallel system. > > In today world parallel cpu are here and in the next few years should > replace all single cpu system and designs such as RISC and CISC. This > suggest that LLVM to be on the cuting edge, needs to alter its design > structure away from the RISC and go toward true parallel design such > as ZISC. But as long as LLVM is using the RISC design that is being > phased out then Ada should not be ported because there are better > projects that are waiting in the wings. I remember reading articles 20 years ago detailing how and why Prolog would replace all other programming languages. Or the more recent example of VLIW computers replacing RISC and CISC designs. It seems somewhat dubious to focus on a technology that is not in widespread use today. While it certainly makes sense to explore these technologies, after all that is how we move forword, it should not be to the exclusion of existing technologies. > So, when and only when LLVM updates or moves it designs to the future > of computting should Ada be ported. > Using the same reasoning, you should always hold off on buynig or using a computer until future designs are available, since they will be much better. > Note: This is not a cut down on RISC processors. It is just that the > world has outgrown the RISC before it had its true day in the sun. But > the main problem is that both CISC and RISC that were developed in the > early days of computers. We should have surpass both designed long > ago, but the companies that create the CPU are still operated by those > that think CISC or RISC is the way to go. It will be fun to watch > those guys sell their stock as newer designs finally take hold. BTW: We're still in the early days of computers. Regards, Steve (The Duck) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-21 22:04 ` anon 2007-07-22 13:22 ` Steve @ 2007-07-23 12:29 ` Colin Paul Gloster 2007-07-23 14:42 ` anon 1 sibling, 1 reply; 30+ messages in thread From: Colin Paul Gloster @ 2007-07-23 12:29 UTC (permalink / raw) On 2007-07-21, anon <anon@anon.org> wrote: |--------------------------------------------------------------------------------------------------| |"The question should be. Should Ada be ported or is it a waste of time? | |" | |--------------------------------------------------------------------------------------------------| What one does with one's time is not necessarily wasteful even if it could instead be expended on something more worthwhile. It would be a worse waste to simply stop now. |--------------------------------------------------------------------------------------------------| |"The LLVM is based on RISC concept and the RISC is being replaced by | | the ZISC aka (Zero Instruction Set Computer). The reason is that today | | most newer computer systems are based on parallel cpus and artificial | | neural networks. While RISC and CISC are based on a single processor | | which came from the early days computers using time-slicing to | | emulate a parallel system. | | | | In today world parallel cpu are here and in the next few years should | | replace all single cpu system and designs such as RISC and CISC." | |--------------------------------------------------------------------------------------------------| So will Field Programmable Gate Arrays (FPGAs) replace RISCs in the meantime? Are Programmable Logic Devices (PLDs) obsolete because of FPGAs? Do you dislike the way combinatorial loops are not an easy accident with PLDs? Were RISCs up-to-date when Hennesy and Patterson claimed to have invented the idea in the 1980's with a publication of theirs cited in their book "Computer Architecture - A Quantitative Approach", despite the claims of users of Microchip PICs that Microchip invented RISCs (without the term RISC) in the 1970's? Should sequential programs which achieve what is required of them be replaced? I own a lot of video tapes. Many of them were bought after DVDs became common. Should I have bought their alternatives on DVDs instead, simply to spend more money for something which someone else thinks is better? |--------------------------------------------------------------------------------------------------| |" This | | suggest that LLVM to be on the cuting edge, [..]" | |--------------------------------------------------------------------------------------------------| I do not expect the Ada to C part of LLVM to be even nearly as good as Taft's Ada 95 to C with POSIX compiler, so how could it be cutting edge? Do you criticise people for using GNAT instead of compilers which perform better? I would rather have choices. |--------------------------------------------------------------------------------------------------| | | |"[..] We should have surpass both designed long | | ago, but the companies that create the CPU are still operated by those | | that think CISC [..] is the way to go. It will be fun to watch | | those guys sell their stock as newer designs finally take hold. | | | |[..]" | |--------------------------------------------------------------------------------------------------| Did you commend those of Intel who ceased Intel's production of the CISC family of MCS51 processors for realizing that it is impure; illogical; and out of date, or did you laugh at Intel for leaving what is probably still the biggest market by volume of sales in the computer industry and for disclosing the 8051 non-zero instruction set which has been copied by many chip manufacturers? C. P. G. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-23 12:29 ` Colin Paul Gloster @ 2007-07-23 14:42 ` anon 2007-07-23 16:55 ` Markus E Leypold 2007-07-24 10:19 ` Colin Paul Gloster 0 siblings, 2 replies; 30+ messages in thread From: anon @ 2007-07-23 14:42 UTC (permalink / raw) The Non-Microsoft programmers of the world need to think of the future. Not what going on today but what they wish and hope for the future. From a old saying: Ones Life and Time is way Too Short to waste it. Or you will be out of work and a has been before you even get started. Programmers need to think 5, 10 and 15 years into the future. And that's only a small precent of the time for a "Software Patent" which is 75 plus years. Like at the movement Microsoft is not waiting around. They are using a small force to patch Vista, maybe 5 to 10%. But the rest aka primary force is working on the replacement for Vista which should be out in 2009-2010. Now, Linux and the GNU forces are still just playing catch up. With alot of software functionabillty being that of Win 98, almost ten years outdated. The problem is that some want to reinvent the wheel over and over. Its one thing to do this in a classroom environment, but it is another to waste one time staying in a place that has limited growth. An example is KDE and GOME which are the two main DeskTop for Linux and if you look at them, they are just a GNU version on Microsoft Windows Desktop. Linux need it own Dektop but the Linux designers are just playing catch up with Microsoft. If these programmers put half of their time in writing code for the future functionabillty of Linux and GNU, they would help push Microsoft off the mountain with a black eye to boot. And who does not want to give Microsoft a black eye. Now, most programmers write code for two reasons: love of programming, and money. Love of programming is great and when it done with the future in mind or a purpose in the future it can bring a lot of profit with it. But reinventing the wheel has no profit and can actually leave you alone and homeless. As for FPGA. They are like summertime TV just something to pass the time until ZISC processors are out in force. Those who use the FPGA as deciated processors will be OK for the time begin. But as the ZISC comes out these programmers will be put out to paster, like a lame horse. Not to stud, but to wait for the glue factor. And for those who are learning and writting code for the future like ZISC will be the leaders of tomorrow! Or even the next Bill Gates! Of course, you might use FPGA to make a ZISC procesor, but I guess the true invening should be left up to Microsoft. Or IBM which created the 8 / 7 operational processors on a chip in the Playstation 3 which they have stated will be out in a general processor system design in the future. But I guess that writtng programs for a emulator that has no farseeable future is more exciting than writting code for a 7 o perational processors system. Which will lead somewhere. People who will pay for code wants multi-processors code, not some outdated emulator code. In <slrnfa97p0.dk6.Colin_Paul_Gloster@localhost.localdomain>, Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes: >On 2007-07-21, anon <anon@anon.org> wrote: > >|--------------------------------------------------------------------------------------------------| >|"The question should be. Should Ada be ported or is it a waste of time? | >|" | >|--------------------------------------------------------------------------------------------------| > >What one does with one's time is not necessarily wasteful even if it >could instead be expended on something more worthwhile. It would be a >worse waste to simply stop now. > >|--------------------------------------------------------------------------------------------------| >|"The LLVM is based on RISC concept and the RISC is being replaced by | >| the ZISC aka (Zero Instruction Set Computer). The reason is that today | >| most newer computer systems are based on parallel cpus and artificial | >| neural networks. While RISC and CISC are based on a single processor | >| which came from the early days computers using time-slicing to | >| emulate a parallel system. | >| | >| In today world parallel cpu are here and in the next few years should | >| replace all single cpu system and designs such as RISC and CISC." | >|--------------------------------------------------------------------------------------------------| > >So will Field Programmable Gate Arrays (FPGAs) replace RISCs in the >meantime? Are Programmable Logic Devices (PLDs) obsolete because of >FPGAs? Do you dislike the way combinatorial loops are not an easy >accident with PLDs? Were RISCs up-to-date when Hennesy and Patterson >claimed to have invented the idea in the 1980's with a publication of >theirs cited in their book "Computer Architecture - A Quantitative >Approach", despite the claims of users of Microchip PICs that >Microchip invented RISCs (without the term RISC) in the 1970's? Should >sequential programs which achieve what is required of them be replaced? >I own a lot of video tapes. Many of them were bought after DVDs became >common. Should I have bought their alternatives on DVDs instead, >simply to spend more money for something which someone else thinks is >better? > >|--------------------------------------------------------------------------------------------------| >|" This | >| suggest that LLVM to be on the cuting edge, [..]" | >|--------------------------------------------------------------------------------------------------| > >I do not expect the Ada to C part of LLVM to be even nearly as good as >Taft's Ada 95 to C with POSIX compiler, so how could it be cutting >edge? Do you criticise people for using GNAT instead of compilers >which perform better? I would rather have choices. > >|--------------------------------------------------------------------------------------------------| >| | >|"[..] We should have surpass both designed long | >| ago, but the companies that create the CPU are still operated by those | >| that think CISC [..] is the way to go. It will be fun to watch | >| those guys sell their stock as newer designs finally take hold. | >| | >|[..]" | >|--------------------------------------------------------------------------------------------------| > >Did you commend those of Intel who ceased Intel's production of the >CISC family of MCS51 processors for realizing that it is impure; >illogical; and out of date, or did you laugh at Intel for leaving what >is probably still the biggest market by volume of sales in the >computer industry and for disclosing the 8051 non-zero instruction set >which has been copied by many chip manufacturers? > >C. P. G. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-23 14:42 ` anon @ 2007-07-23 16:55 ` Markus E Leypold 2007-07-24 10:19 ` Colin Paul Gloster 1 sibling, 0 replies; 30+ messages in thread From: Markus E Leypold @ 2007-07-23 16:55 UTC (permalink / raw) > Now, Linux and the GNU forces are still just playing catch up. With I don't think there is any effort to "catch" Windows: The plan is not to buil > alot of software functionabillty being that of Win 98, almost ten > years outdated. I think, that is nonsense. Security-wise: Linux and Unix had Kerberos long before Windows. Security-wise: Separation of user and administrative rights. Stability-wise: Only with Windows 2000 Windows really achieved the stability (>100s of days of uptime) that even patchy Linux servers had 5 years before. Networking-wise: Remote Desktops and application never where a problem from the very beginning (Windows: CALs, Terminal services in the desktop version only since XP, AFAIK no simple way to remote single apps). And so on. > The problem is that some want to reinvent the wheel over and over. Absolutely right. Seing Mikrosoft stealing other peoples wheels and the "inventing" them (does anybody remember the Halloween documents ...?): Pathetic. > Its one thing to do this in a classroom environment, but it > is another to waste one time staying in a place that has limited > growth. An example is KDE and GOME which are the two main > DeskTop for Linux and if you look at them, they are just a GNU > version on Microsoft Windows Desktop. I agree they are far to Windows-like in some sspects: Usually the bad ones. But by no means identical: There is a lot in Gnome, you'll be looking for in vain in the MS desktop. > Linux need it own Dektop but the Linux designers are just playing > catch up with Microsoft. But you know, that the desktop is not alone what defines usability? > If these programmers put half of their time in writing code for the Which programmers? Writing code instead of what? You lost me there. > future functionabillty of Linux and GNU, they would help push > Microsoft off the mountain with a black eye to boot. And who > does not want to give Microsoft a black eye. Me. The Anti-MS-wars are not really interesting. What I see with concern are the hidden costs of a MS-environment: Like people buying a 3 Ghz processor and after installing certain Antivirus software get a performance and percieved response latency worse than with a 400 Mhz processor. This doesn't awaken the desire to hit back, but more to extricate one's infra structure from that morass before everything (data and all) is irretrievably bogged down in proprietary formats and wasteful online-licensed software which needs to be activated: I still want to be able to access my data 10 years from now (indeed I have to: the IRS in my country requires one to retain business related data for that time). There is no desire to blacken any eyes: Only to steal oneself silently away and let history have it's course. > Now, most programmers write code for two reasons: love of > programming, and money. Love of programming is great and when it > done with the future in mind or a purpose in the future it can bring a > lot of profit with it. But reinventing the wheel has no profit and can > actually leave you alone and homeless. And now, what are your conclusions? Shall we forbid other people to program? Because they do it for the wrong reason or shortsighted? Shall we refuse to use GNome and KDE and use Windows instead just to demonstrate our opposition against Gnome (according to you) being a clone of the windows desktop. I'm sure _that_ will hurt Windows like hell ... Or ist it you that will come and rescue us where others fail? I have to admit I fail to see your take home message: Which changes do you want and how do you propose to put them in effect? > As for FPGA. They are like summertime TV just something to pass > the time until ZISC processors are out in force. Those who use the FPGA OK. Everything is clear now. And because FPGA are like summertime TV (which should be clear to every thinking person!), they will go away in winter and ZISC will rule. Is it possible that you're just replacing a missing argument by a bad metaphor? > as deciated processors will be OK for the time begin. But as the ZISC > comes out these programmers will be put out to paster, like a lame > horse. Not to stud, but to wait for the glue factor. And for those who > are learning and writting code for the future like ZISC will be the leaders > of tomorrow! Or even the next Bill Gates! Well, well: If you tell that to everybody, everybody will do it: And then you won't be the next Bill Gates (at least not alone). How about keeping your profound analysis secret and exploiting it yourself? > Of course, you might use FPGA to make a ZISC procesor, but I guess > the true invening should be left up to Microsoft. Because MS is known for it's leadership in hardware design? > Or IBM which created the 8 / 7 operational processors on a chip in > the Playstation 3 which they have stated will be out in a general > processor system design in the future. > But I guess that writtng programs for a emulator that has no > farseeable future is more exciting than writting code for a 7 o > perational processors system. Which will lead somewhere. People who > will pay for code wants multi-processors code, not some outdated > emulator code. You're sure you're not just a school kid? Or Xah Lee? Or David Wallace? Recently you pretended that you had a long history in programming / software developement. But reading your overgeneralizing statements I really wonder wether you have ANY idea how markets work. Regards -- Markus ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: LLVM--Low Level Virtual Machine--and Ada 2007-07-23 14:42 ` anon 2007-07-23 16:55 ` Markus E Leypold @ 2007-07-24 10:19 ` Colin Paul Gloster 1 sibling, 0 replies; 30+ messages in thread From: Colin Paul Gloster @ 2007-07-24 10:19 UTC (permalink / raw) On 2007-07-23, anon <anon@anon.org> wrote: |-------------------------------------------------------------------------------| |"[..] From a old | | saying: Ones Life and Time is way Too Short to waste it. Or you will be | | out of work and a has been before you even get started. | | | |[..] | | | |[..] People | | who will pay for code wants multi-processors code, not some | | outdated emulator code." | |-------------------------------------------------------------------------------| A hobby does not need to generate income. Who would pay for the Ada frontend to the LLVM if Taft's compiler and C and POSIX are available for the platform? People still pay for Java. |-------------------------------------------------------------------------------| |"Programmers need to think 5, 10 and 15 years into the future. [..]" | |-------------------------------------------------------------------------------| 8-bit computers are cheaper than 16/32/64-bit computers. More advanced computers which have resulted from progressive research have not eradicated all of the earlier machines which are still being produced in large volumes. |-------------------------------------------------------------------------------| |"[..] | | | | [..] And who | | does not want to give Microsoft a black eye." | |-------------------------------------------------------------------------------| People who are not malicious. |-------------------------------------------------------------------------------| |" | | [..] But reinventing the wheel has no profit and can | | actually leave you alone and homeless." | |-------------------------------------------------------------------------------| True, but many supposed researchers actually do reinvent things without knowing it and without becoming homeless. |-------------------------------------------------------------------------------| |" | | As for FPGA. They are like summertime TV just something to pass | | the time until ZISC processors are out in force. Those who use the FPGA | | as deciated processors will be OK for the time begin. But as the ZISC | | comes out these programmers will be put out to paster, like a lame | | horse. Not to stud, but to wait for the glue factor. And for those who | | are learning and writting code for the future like ZISC will be the leaders | | of tomorrow! Or even the next Bill Gates! | | | |[..]" | |-------------------------------------------------------------------------------| Please explain. Why does a market still exist for CPLDs if people who use FPGAs are okay for the time being? Regards, C. P. G. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2007-07-25 13:14 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-07-18 3:56 LLVM--Low Level Virtual Machine--and Ada Jerry 2007-07-18 7:24 ` Georg Bauhaus 2007-07-18 7:48 ` Duncan Sands 2007-07-19 14:30 ` Maxim Reznik 2007-07-19 14:56 ` Duncan Sands [not found] ` <200707191656.27602.baldrick@free.fr> 2007-07-19 15:03 ` Duncan Sands 2007-07-19 21:30 ` Robert A Duff 2007-07-20 7:44 ` Duncan Sands 2007-07-20 14:06 ` Robert A Duff 2007-07-21 13:09 ` Tero Koskinen 2007-07-23 7:47 ` Duncan Sands 2007-07-24 2:12 ` Randy Brukardt 2007-07-24 8:03 ` Duncan Sands 2007-07-24 9:50 ` Colin Paul Gloster 2007-07-24 10:47 ` Markus E Leypold 2007-07-25 12:12 ` Colin Paul Gloster 2007-07-25 12:59 ` Markus E Leypold 2007-07-24 19:21 ` Randy Brukardt 2007-07-24 19:36 ` Duncan Sands 2007-07-24 19:58 ` Randy Brukardt 2007-07-24 23:28 ` Robert A Duff 2007-07-25 0:39 ` Randy Brukardt 2007-07-25 2:00 ` Robert A Duff 2007-07-25 13:14 ` Duncan Sands 2007-07-21 22:04 ` anon 2007-07-22 13:22 ` Steve 2007-07-23 12:29 ` Colin Paul Gloster 2007-07-23 14:42 ` anon 2007-07-23 16:55 ` Markus E Leypold 2007-07-24 10:19 ` Colin Paul Gloster
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox