LLVM--Low Level Virtual Machine--and Ada

LLVM--Low Level Virtual Machine--and Ada

[Jerry]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Georg Bauhaus]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Duncan Sands]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Maxim Reznik]

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?

Re: LLVM--Low Level Virtual Machine--and Ada

[Duncan Sands]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Duncan Sands]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Robert A Duff]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Duncan Sands]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Robert A Duff]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Tero Koskinen]

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/

Re: LLVM--Low Level Virtual Machine--and Ada

[anon]

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
>

Re: LLVM--Low Level Virtual Machine--and Ada

[Steve]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Duncan Sands]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Colin Paul Gloster]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[anon]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Markus E Leypold]

> 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

Re: LLVM--Low Level Virtual Machine--and Ada

[Randy Brukardt]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Duncan Sands]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Colin Paul Gloster]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Colin Paul Gloster]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Markus E Leypold]

> 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

Re: LLVM--Low Level Virtual Machine--and Ada

[Randy Brukardt]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Duncan Sands]

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.

Re: LLVM--Low Level Virtual Machine--and Ada

[Randy Brukardt]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Robert A Duff]

"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

Re: LLVM--Low Level Virtual Machine--and Ada

[Randy Brukardt]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Robert A Duff]

"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

Re: LLVM--Low Level Virtual Machine--and Ada

[Colin Paul Gloster]

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

Re: LLVM--Low Level Virtual Machine--and Ada

[Markus E Leypold]

> 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

Re: LLVM--Low Level Virtual Machine--and Ada

[Duncan Sands]

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