The GNU Manifesto - GNU Project - Free Software Foundation (FSF) "Competition makes things get done better."
The paradigm of competition is a race: by rewarding the winner, we encourage everyone to run faster. When capitalism really works this way, it does a good job; but its defenders are wrong in assuming it always works this way. If the runners forget why the reward is offered and become intent on winning, no matter how, they may find other strategies--such as, attacking other runners. If the runners get into a fist fight, they will all finish late.
Proprietary and secret software is the moral equivalent of runners in a fist fight. Sad to say, the only referee we've got does not seem to object to fights; he just regulates them ("For every ten yards you run, you can fire one shot"). He really ought to break them up, and penalize runners for even trying to fight.

The GNU Manifesto - GNU Project - Free Software Foundation (FSF) "Don't people have a right to control how their creativity is used?"
"Control over the use of one's ideas" really constitutes control over other people's lives; and it is usually used to make their lives more difficult.

The GNU Manifesto - GNU Project - Free Software Foundation (FSF) Complete system sources will be available to everyone. As a result, a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him. Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes.
Schools will be able to provide a much more educational environment by encouraging all students to study and improve the system code. Harvard's computer lab used to have the policy that no program could be installed on the system if its sources were not on public display, and upheld it by actually refusing to install certain programs. I was very much inspired by this.

The GNU Manifesto - GNU Project - Free Software Foundation (FSF) By working on and using GNU rather than proprietary programs, we can be hospitable to everyone and obey the law. In addition, GNU serves as an example to inspire and a banner to rally others to join us in sharing. This can give us a feeling of harmony which is impossible if we use software that is not free. For about half the programmers I talk to, this is an important happiness that money cannot replace.

The GNU Manifesto - GNU Project - Free Software Foundation (FSF) Many programmers are unhappy about the commercialization of system software. It may enable them to make more money, but it requires them to feel in conflict with other programmers in general rather than feel as comrades. The fundamental act of friendship among programmers is the sharing of programs; marketing arrangements now typically used essentially forbid programmers to treat others as friends. The purchaser of software must choose between friendship and obeying the law. Naturally, many decide that friendship is more important. But those who believe in law often do not feel at ease with either choice. They become cynical and think that programming is just a way of making money.

http://lists.alt.org/pipermail/fsl-discuss/2002-June/000508.html [fsl-discuss] Introduction and A Modest Proposal for a GNU infrastructure license RGPL
James Michael DuPont mdupont777@yahoo.com
Fri, 21 Jun 2002 01:02:37 -0700 (PDT)
Previous message: [fsl-discuss] Announcing Greplaw
Next message: [fsl-discuss] Introduction and A Modest Proposal for a GNU infrastructure license RGPL
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]



Hello!

My name is James Michael DuPont,
I am working on a project to extend the GCC compiler.
The introspector.sf.net.

To safely implement this, a new license scheme that is
to be compatible with the GPL is needed.

Before I propose this let me point out a few things
that are often misunderstood :

1. The GPL protects the GCC against people not
publishing front and back ends to the compiler. With a
less restrictive license, we would have less of the
gcc.

2. Copyright does not cover the inputs and outputs and
usage(how and why it is run) of software. This license
attempts to via an END user license aggreement.

3. I am not trying to change the license of any
existing software, I am trying to access the internal
data of GPLed programs while protecting it as if it
were in memory of the program.

4. The motivation for creating this library is to
create a haven for free software tools to interact
with the meta data of the compilers.
It is not a ge

http://groups.google.com/groups?q=backend+gcc+stallman&hl=de&lr=&ie=UTF-8&oe=UTF8&selm=3r5n4j%24599%40cmcl2.NYU.EDU&rnum=5 Von:Richard Kenner (kenner@lab.ultra.nyu.edu)
Betrifft:Re: Modula-3 (Was: Comparison of languages for CS1 and CS2)
Newsgroups:comp.lang.ada, comp.lang.modula2, comp.lang.modula3
View: Complete Thread (29 articles) | Original Format
Datum:1995/06/08


In article <1995Jun7.101538.26580@wavehh.hanse.de> cracauer@wavehh.hanse.de (Martin Cracauer) writes:
>>I doubt it, what possible FSF goal can be met by such a separation, it
>>would seem to promote exactly that which FSF tries hard to prevent, the
>>creation of proprietary technologies which make use of free software.
>
>I don't think so. IMHO, the only reason why the separation isn't done
>is that noone spent the time on it.

Robert is quite correct. Richard Stallman has been adamantly opposed
to any attempt to split front ends into separate programs for
precisely the reason Robert gives.

>The GNU-Objective-C folks, for example, would be very happy to have
>their frontend mixed with the C frontent to allow Objctive-C
>programs.

True, but what does this have to do with the separation issue? It
seems instead that such mixture would be even *less* separated.

>From what I heared, the FSF would be happy to make the gcc backend an
>easier-to-use tool for language implementors.

Certainly true, but again this has nothing to do with separation of
the kind Robert was talking about.

>The backend has to be modified anyway2

Re: Converting the gcc backend to a library?
In message <200001092033.VAA01200@loewis.home.cs.tu-berlin.de>you write:
> > I submitted a patch in 1994, which turns the gcc backend into a
> > library. I was told that it would lead to the gcc backend based
> > commercial compiler. I am enclosing my ChangeLog here. I guess
> > I can recreate it if I won't waste my time this time.
>
> I hope this objection is not valid anymore (if it ever was). If if the
> gcc backend is a library, derived compilers would still have to be
> licensed under the GPL. And if somebody wants to produce a commercial
> compiler that is available under GPL terms, so be it. I know companies
> who do this right know...
If it takes a significant step towards the ability to turn the backend into
a shared library, then it has that kind of potential. Changes of that nature
would have to be OK'd by the steering committee, not any individual maintainer
due to the political issues.

Re: Converting the gcc backend to a library? > I submitted a patch in 1994, which turns the gcc backend into a
> library. I was told that it would lead to the gcc backend based
> commercial compiler. I am enclosing my ChangeLog here. I guess
> I can recreate it if I won't waste my time this time.

I hope this objection is not valid anymore (if it ever was). If if the
gcc backend is a library, derived compilers would still have to be
licensed under the GPL. And if somebody wants to produce a commercial
compiler that is available under GPL terms, so be it. I know companies
who do this right know...

Re: Converting the gcc backend to a library? On Dec 26, 1999, Mikael Djurfeldt wrote:

> Is there any work going on to convert the gcc backend to a library?

Only in the sense that it has been proposed before, ``blessed'' by the
maintainers. It's been in my personal wishlist for quite a long time,
and I intend to start working on it in some no-so-distant future.

> How difficult would this be?

If it is just a matter of packing the appropriate objects into a
library, not much. It shouldn't be too hard to figure out which files
in the gcc directory are part of the back-end and which are part of
the C front-end.

However, making this library useful after installation may be a
completely different issue, since we'd have to figure out which
headers to install to make the library useful after the build tree is
gone, for example.

Guile (About Guile) What is Guile? What can it do for you?
Guile is a library designed to help programmers create flexible applications. Using guile in an application allows programmers to write plug-ins, or modules (there are many names, but the concept is essentially the same) and users to use them to have an application fit their needs.
There is a long list of proven applications that employ extension languages. Successful and long-lived examples in the free software world are GNU Emacs and The GIMP.
Very popular examples of extending server applications are the apache projects perl and php modules.
Extension languages allow users, programmers, and third-party developers to add features to a program without having to re-write the program as a whole, and it allows people extending a program to co-operate with each other, without having to expend any extra effort.

The GNU Compiler Writer's Jump Point The GNU Compiler Writer's Jump Point
Welcome to the GNU Compiler Writer's Jump Point. Right now this page is only dedicated to providing information about writing new language front ends to GCC. Later, more information will be available.
Information on the GCC Backend Tree Interface
The tree data structure is defined in the files tree.def and tree.h in the GCC source code. This structure is the link between a language front-end and the GCC back-end. Although most of these links do not address this issue directly, they provide helpful information about the subject.

http://gcc.gnu.org/ml/gcc/1999-12/msg00539.html Mikael Djurfeldt wrote:

> That is, I'd like to link my interpreter with the gcc backend.

This is a very FAQ, for which there is no good answer. Here are
some resources which I have collected.

There is also 'Using and Porting GNU CC' which comes with GCC and
you can salso buy a hardcopy from the FSF.

Integration with the GCC back end is mainly via the tree.[ch] and
tree.def interface and the assorted subroutines that come with
that. You don't actually generate the RTL yourself - the routines
do that for you from the tree nodes.

You will see many complaints in the documentation that the front
end and back end are not cleanly separated. Also the back end is
more friendly to C front ends at least though this is not a show
stopper.

The back end interface is also pretty low level and could
usefully be encapsulated into some more friendly interface. In
that sense a library is a good idea. I am trying to integrate a
cobol front end into gcc at present and I will probably do some
encapsulation, but this does not have a fixed end date! So as far
as I know, you will have to do a fair bit of work.

Having said that, GCC back end provides tremendous value - 30
platforms supported out automatically; lots of optimisation;
automatic creation of numerous varieties of debugging
information, ability to use gdb for debugging.

I'm not sure also if you are aware

Re: Converting the gcc backend to a library? > Is the gcc development team interested in one or two of these
> developments if they were done right?

Even though I cannot speak for the team (just for myself), I think it
is a safe assumption that the answer is "yes". The critical matter is
that these changes (like any other) have to be done "right": they
should be well-documented, do not interfere with "normal" operation,
be maintainable, etc.

For step 2, it is not all that clear to me that the best solution is
to pack the globals into data structures, as you then have to pass the
pointer to the globals around from function to function. That would be
a significant change, and unnecessary for stand-alone operation.

Of course, if you can arrange to provide additional advantages for
stand-alone operation as well (eg. compiling multiple files in a
single cc1/cc1plus/f771/etc invocation), then that might provide the
rationale for an even larger change.

Converting the gcc backend to a library? Converting the gcc backend to a library?
To: gcc at gcc dot gnu dot org
Subject: Converting the gcc backend to a library?
From: Mikael Djurfeldt
Date: Sun, 26 Dec 1999 19:53:37 0100
Reply-to: Mikael Djurfeldt



I'm interested in writing an interpreter which incrementally compiles
functions and loads them into the process, i.e. an interactive
development environment which still can execute code efficiently.

I'd like to write a front-end which transforms the source language
into RTL, calls the backend to produce object code, and loads it.

That is, I'd like to link my interpreter with the gcc backend.

Is there any work going on to convert the gcc backend to a library?
How difficult would this be?

If it requires reasonable amount of work, I'd be prepared to provide a
helping hand. Is this something which the gcc development team could
imagine include into the gcc distribution?

[I've just joined the gcc list, so I'm not sure how out-of-context I
am when asking this question.]

Best regards,
/mdj

http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html To: gcc at gcc dot gnu dot org
Subject: Re: Converting the gcc backend to a library?
From: Richard Stallman
Date: Mon, 17 Jan 2000 19:51:25 -0700 (MST)
Reply-to: rms at gnu dot org



Companies often try to make software non-free, and some would write
non-free add-ons to GCC if we let them. The reason we have free C
and Objective C support is because the companies which wrote these
front ends had no *feasible* way to use them without making them part
of GCC, where the GPL required them to be free. It is vital that we
preserve this situation.

Anything that makes it easier to use GCC back ends without GCC front
ends--or simply brings GCC a big step closer to a form that would make
such usage easy--would endanger our leverage for causing new front
ends to be free.

Because of this, the GNU Project will in all probability not install
such changes, should they be available. This statement reflects a
firm conclusion based on a decade of thought.

I ask anyone who would like to make such changes in GCC to please
contact me privately. I would like to talk with you about the ideas
you are interested in working on, to look at the magnitude of their
potential benefits, and consider other possible ways of achieving
them. Please think about the importance of future free front ends,
as well as the interest of the project you are2

SRC Modula-3 home page C Modula-3
This region of the web describes SRC Modula-3 -- a Modula-3 compiler for Unix, Windows/NT, and Windows 95 -- and the terms under which it is distributed.
SRC Modula-3 was built by the DEC Systems Reseach Center and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/release-X.Y and its mirrors.
The distribution contains a Modula-3 compiler and runtime, a large set of libraries, and a few other tools. On the Unix platforms, the compiler uses a gcc-based back-end and should be fairly easy to port. On the Win32 platforms, the compiler uses a native code generator. Except for the very lowest levels of the thread implementation, the entire system is written in Modula-3.
The original compiler and runtime system were designed and implemented by Bill Kalsow and Eric Muller. The system should be of interest to two camps: those interested in trying out Modula-3 and those interested in compiler hacking.

http://groups.google.com/groups?q=:Tim+Mann+(mann%40pa.dec.com)+stallman&hl=de&lr=&ie=UTF-8&oe=UTF8&selm=516vkm%24509%40src-news.pa.dec.com&rnum=2 As the maintainer of a program that's partly under the GPL, I'd like
to wade in on this licensing discussion.

My own view on free software is this: If someone wants to write
software and give it away for free use by anyone, he should be able to
do that. If he wants to keep it proprietary and charge for the right
to use it, he should be able to do that.

Personally, when I write software that I want to give away, I am happy
for anyone to use it in any way they please. If they want to take
some of my code and incorporate it along with some of their work into
a commercial, proprietary product, that does not bother me. If I'm
giving code away, I'm giving it to everyone, not only to other people
who also want to give their code away. If someone uses my code in a
proprietary product that does not supply enough added value to make it
worth the price and to compensate for the source not being available,
then people will just use my free version instead. No one can stop
them from doing this if I retain the copyright on it and grant them
the necessary rights. (See the X consortium license and the BSD
license for examples of how this is done.)

This is not Richard Stallman's view. He says that the copyright law
is immoral. All software should be free, regardless of whether the
person who wrote it wants it to be free or not. The GPL is written in

http://groups.google.com/groups?q=frontend+backend+gcc+stallman&hl=de&lr=&ie=UTF-8&oe=UTF8&selm=8h4jmt%24n9c%40src-news.pa.dec.com&rnum=1 m3.c and the related modifications to gcc are not in the gcc CVS tree
because Richard Stallman does not want them. The whole purpose of m3.c
is to allow gcc to act as a backend for a frontend that is a separate
program, communicating over a pipe. Because the frontend and backend
are separate programs with this arrangement, the frontend does not have
to be under the GPL. This provides an escape hatch from the GPL's so-called
"viral" nature (all additions or modifications to a GPL'ed program must
also be GPL'ed) and thus conflicts with Stallman's goals. Modula-3 does
use this escape hatch; the compiler frontend is under the SRC Modula-3
license, a quite liberal license that fits the Open Source definition
but is not compatible with the GPL.

Thus, although we could probably have gotten management permission to
transfer m3.c's ownership to the FSF, the FSF would then have refused
to distribute it, so that would not have been too useful. Instead we
put m3.c under the GPL (which is necessary because it's linked into the
same address space as part of gcc), but left the ownership with Compaq.
(By the way, this actually wouldn't prevent the FSF from distributing
the code *if they wanted it*; the last time I looked, there were several
files in the gcc distribution that were under the GPL but copyrighted
to some entity other than the FSF.)

An alternat

Google Groups: Ansicht Diskussionsthemen "GPL and NDAs"

In article <1995Jun7.101538.26580@wavehh.hanse.de> cracauer@wavehh.hanse.de (Martin Cracauer) writes:

>>I doubt it, what possible FSF goal can be met by such a separation, it

>>would seem to promote exactly that which FSF tries hard to prevent, the

>>creation of proprietary technologies which make use of free software.

>

>I don't think so. IMHO, the only reason why the separation isn't done

>is that noone spent the time on it.



Robert is quite correct.  Richard Stallman has been adamantly opposed

to any attempt to split front ends into separate programs for

precisely the reason Robert gives.



>The GNU-Objective-C folks, for example, would be very happy to have

>their frontend mixed with the C++ frontent to allow Objctive-C++

>programs.



True, but what does this have to do with the separation issue?  It

seems instead that such mixture would be even *less* separated.



>From what I heared, the FSF would be happy to make the gcc backend an

>easier-to-use tool for language implementors.



Certainly true, but again this has nothing to do with separation of

the kind Robert was talking about.



>The backend has to be modified anyway to allow better optimization for the

>deeper pipelines of modern CPUs.



There are lots of optimizations that could be added to the backend to

produce better code; GCC does reasonably well now with pipeline

delays, so the above doesn't appear to be one of the more important.



However, again, what does this have to do with the separation issue?



>If the current way to implement m3 causes major overhead, maybe the

>time required for every m3-inside-gcc-backend release would be better

>invested in turning gcc into something that causes less overhead.



The experiences of the GNAT project show how valuable GCC has been to

language implementation since they were able to concentrate solely on

language issues and leave code generation, optimization, and

portability issues to GCC.



However, everything can be improved.  I welcome your suggestions for

making it easier to write front ends to GCC.

HPANDF: High Performance ANDF (Architecture Neutral Distribution Format) HPANDF: High Performance ANDF (Architecture Neutral Distribution Format)



SUMMARY
HPANDF is an extension of OSF's ANDF required to provide language-independent front-end / back-end factorization for data parallel languages such as HPF, APC or HPADA. This project develops the HPANDF design and builds a prototype implementation. At the current stage, the ANDF extensions required to support array operations such as Fortran90 matrix arithmetic are implemented and we are designing the translation of ALIGN and DISTRIBUTE directives.

Comp.compilers: Re: Generating Java Bytecode > [Before you head down this path, you really should look at the
> history and learn why all the previous UNCOL projects failed. They
> all looked great with one or two input languages and targets, then
> collapsed of heat death when they tried to generalize more. -John]

Has this happened to ANDF yet? ANDF strikes me (as an idea; I have no
experience of it in practice) as a Good Thing, because it keeps lots
of high-level information which is of potential use in producing
machine code from ANDF. For example, although array bounds checks
would be lovely, I'd like my final code to contain very few of them,
particularly inside loops! I can imagine it being difficult to safely
remove bounds checks in a poorly designed bytecode: one would
potentially have to reconstruct the loops and things.

On the other hand, ANDF probably isn't appropriate for chips to execute.
[Haven't heard much about ANDF lately, perhaps Stavros M. can point us
at recent info. -John]

Michael Matz - Re: java bytecode considered bad Re: java bytecode considered bad
To: Trent Waddington
Subject: Re: java bytecode considered bad
From: Michael Matz
Date: Fri, 23 Feb 2001 01:24:14 0100 (MET)
cc: Gerald Pfeifer , Fergus Henderson ,



Hi,

On Fri, 23 Feb 2001, Trent Waddington wrote:
> > I don't see why we should want to reduce the functionality for users of
> > GCC to avoid that; unless I miss something, that is.
> >
>
> finally, the voice of sanity.

Well, in case you haven't noticed. Most of us are not of the opinion of
RMS on this topic (this special one, using JBC as IL; not generally the
fear of having a feasible IL, which some share with him).

> If you were going to choose an intermediate language to dump to
> proprietory backend's, wouldn't a low level C be more useful than JBC?

I think neither JBC nor C are feasible ILs, because too much information
is lost, and e.g. C allows things which makes a mapping from another
language to C unnecessarily inefficient, when compiled from that "IL"
(e.g. pointers).


Ciao,
Michael.

http://www.eecs.harvard.edu/~nr/pubs/c--gc-abstract.html Hi,

On Wed, 21 Feb 2001, Fergus Henderson wrote:

> > If it is possible to compile languages such as C into Java byte codes,
> > I see a great danger. The danger is that people will use Java byte
> > codes to hook GCC up to proprietary back ends and proprietary front
> > ends.
>
> People can already hook GCC up to proprietry front ends by simply
> having their front end generate C code. There are certainly a number

I think the fear of RMS is more, that people could write a new _backend_
for their hardware, do not publish it, but still use all the nice
frontends of GCC. With an intermediate language they could do this
legally, cause they don't have to link to GCC, but only write a reader for
that IL. This backend, because propritary and targeted to one hardware
could probably generate better code, than GCC in general, so it might be
successfull, although it "steals" all the hard work put in our frontends.
Without a feasible IL which GCC can generate this becomes legally
impossible. Now for this case, I don't know, if Java BC is a feasible IL
(meaning all languages can be compiled without loss of semantic and
information into JBC. Without loss of semantic can work of course, after
all that's the point of compiling. But without loss of information might
be impossible. That goal would be needed to generate efficient code
(think e.g.2

C-- Home Welcome to C--
Suppose you are writing a compiler; how will you get quality machine code? Writing your own code generator is a lot of work, so you might use somebody else's. There appear to be three notable, freely available code generators: VPO, MLRISC, and the gcc back end. Each of these impressive systems has a rich, complex, and ill-documented interface---and once you start to use one, you will be unable to switch easily to another. Furthermore, to use MLRISC you must write your front end in ML, to use gcc you must write it in C, and so on.
You might also generate C, if you can afford its calling conventions. And forget about proper tail calls, computed gotos, accurate garbage collection, efficient exceptions, or source-level debugging.
All of this is most unsatisfactory. It would be much better to have one portable assembly language that could be generated by a front end and implemented by any of the available code generators. Such a language should serve as the interface between high-level compilers and retargetable, optimizing code generators. Life would be easier for compiler writers, and authors of code generators would have customers instantly. C-- is that language.

http://www.eecs.harvard.edu/~nr/pubs/c--gc-abstract.html C--: a portable assembly language that supports garbage collection (Abstract)
Simon Peyton Jones, Norman Ramsey, and Fermin Reig
For a compiler writer, generating good machine code for a variety of platforms is hard work. One might try to reuse a retargetable code generator, but code generators are complex and difficult to use, and they limit one's choice of implementation language. One might try to use C as a portable assembly language, but C limits the compiler writer's flexibility and the performance of the resulting code. The wide use of C, despite these drawbacks, argues for a portable assembly language. C-- is a new language designed expressly for this purpose. The use of a portable assembly language introduces new problems in the support of such high-level run-time services as garbage collection, exception handling, concurrency, profiling, and debugging. We address these problems by combining the C-- language with a C-- run-time interface. The combination is designed to allow the compiler writer a choice of source-language semantics and implementation techniques, while still providing good performance.
This paper is available in TeX DVI format (101K), PostScript (407K), and PDF (104K).
Readers may also be interested in Machine-independent support for garbage collection, debugging, exception handling, and concurrency. This older report covers substantially the same material, but it goes into much greater detail about other high-level services, and it presents the

http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html java bytecode considered bad
To:
Subject: java bytecode considered bad
From: Trent Waddington
Date: Wed, 21 Feb 2001 03:19:22 1000 (GMT 1000)




Following is a dialog I have had with RMS over the last few weeks. The
skinny of it is that RMS thinks having gcc both generate and accept as an
input java bytecode allows folks to do nasty proprietary things with gcc
so he's not interested in the backend for the jvm which I wrote 18 months
ago (and doesn't think anyone else should be). I have tried to explain
that java bytecode (especially the stuff I generate) is not a good
intermediate language... I'll let the list handle it.

------------

>From s337240@student.uq.edu.au Wed Feb 21 03:11:22 2001
Date: Wed, 7 Feb 2001 08:00:02 1000 (GMT 1000)
From: Trent Waddington
To: rms@ai.mit.edu
Subject: java backend

Hi. I dont know if you remember me but I worked on a java bytecode
backend to gcc which was released early last year. At the time I was
instructed that it would be impossible to get the copyright on the backend
assigned to the FSF. I would like to try again to obtain the copyright
assignment as the ownership of this code is no longer a priority to the
university that I was working for at the time. As far as I know gcc does
n

Fergus Henderson - Re: java bytecode considered bad On 21-Feb-2001, Trent Waddington wrote:
> From: Richard Stallman
> To: s337240@student.uq.edu.au
> Subject: Re: java backend
>
> If it is possible to compile languages such as C into Java byte codes,
> I see a great danger. The danger is that people will use Java byte
> codes to hook GCC up to proprietary back ends and proprietary front
> ends.

People can already hook GCC up to proprietry front ends by simply
having their front end generate C code. There are certainly a number
of proprietry language front ends around that generate C code, e.g.
Cfront (the original C compiler), some Eiffel compilers, etc., as
well as many free software compilers that do the same. And if you
plan to use the GNU back-end, then C is almost certainly going to be a
better target language than Java or Java byte codes. So I think the
worry about proprietry front ends is misplaced. The cat is out of the
bag, and whatever damage will result from that is already unstoppable.

--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.

http://www.info.uni-karlsruhe.de/~andf/ What is the ANDF technology?
The Architectural Neutral Distribution Format (ANDF) is a software porting technology, which makes it possible to develop shrink-wrapped software for open systems, independent of any particular processor architecture. The ANDF intermediate format is also often seen - and used - as a compiler technology. The specification defines an integration interface between the two major components of a multi-platform cross-compilation system. The compilation of the source code is turned into a two stage process. In the first (ANDF Producer) stage, the application is transcribed into an ANDF format which utilises generalised declarations of the API calls used, together with generalised definitions of data types, constants, and so on. In the second (ANDF Installer) stage, the entities generated in the first stage are linked together and then mapped onto a concrete machine through the use of processor-specific libraries which implement the API calls and data formats. This phase also includes the optimized mapping to machine code.
The ANDF standard is a result of a request for technology (RFT) by the Open Software Foundation (OSF) in May 1989. In June 1991, DRA's TenDRA (TDF) technology was selected by OSF to be the base technology for OSF's ANDF technology.
Today a lot of tools are available, frontends for many common languages and especially a great variety of installers is available.
Please find more detailed information about ANDF in our "Technical Info" s

Geocrawler.com - gcc-help - ANDF

http://slashdot.org/features/98/10/20/116240.shtml Bruce Stephens has written in with a writeup on something he considers pretty cool- perhaps you'll agree. It's about something you may not have heard of:ANDF. Looks interesting for the hardcore.
Whatever happened to ANDF?
Once upon a time, there was a neat technology called ANDF: Architecture Neutral Distribution Format. It even merits a place in the GNU Project's task list: provide a decompiler for ANDF. (I'm not sure whether this item is still there; it's probably not high on the list of tasks!)
I haven't seen it mentioned much in years, however.
How does ANDF work?
ANDF is a format: it's a flattened representation of the abstract syntax tree for a program. Programs are compiled using a number of tools:
A producer, which produces target-independent ANDF from source
A linker, which links together some target-independent ANDF capsules
An installer, which combines target-independent capsules and target-specific ones, and knows how to produce target-specific code.
Much of 3 can actually be fairly portable. Many optimizations can be cast as portable manipulations of an abstract syntax tree. What's more target-specific is which of these manipulations you use. More than that; ANDF can represent a range of levels of detail, so even quite low-level things can be done using code that is shared between targets.
So, if you want to draw a line between developers (who compile code to produce binaries) and users (who just want to use the

TenDRA TenDRA is a portable C and C compiler, developed by DERA around the TDF/ANDF intermediate format. As well as being a compiler, it can provide strict checks for language and API conformance. A feature about ANDF on SlashDot provoked a good deal of discussion on the capabilities of the compiler and the merits and demerits of TenDRA and ANDF.
TenDRA is free software, with packages being avalible for both Debian GNU/Linux and FreeBSD. The Debian package is currently in the unstable distribution, which is due to be released as Debian 2.2. The FreeBSD port is available from their ports collection.

SOFTWARE RIGHTS
$Id: //depot/code/org.antlr/release/antlr-2.7.1/RIGHTS#1 $

ANTLR 1989-2000 Developed by jGuru.com (MageLang Institute),
http://www.ANTLR.org and http://www.jGuru.com

We reserve no legal rights to the ANTLR--it is fully in the
public domain. An individual or company may do whatever
they wish with source code distributed with ANTLR or the
code generated by ANTLR, including the incorporation of
ANTLR, or its output, into commerical software.

We encourage users to develop software with ANTLR. However,
we do ask that credit is given to us for developing
ANTLR. By "credit", we mean that if you use ANTLR or
incorporate any source code into one of your programs
(commercial product, research project, or otherwise) that
you acknowledge this fact somewhere in the documentation,
research report, etc... If you like ANTLR and have
developed a nice tool with the output, please mention that
you developed it using ANTLR. In addition, we ask that the
headers remain intact in our source code. As long as these
guidelines are kept, we expect to continue enhancing this
system and expect to make other tools available as they are
completed.

OpenCyc This document describes the Cyc Application Programmers Interface (API). This is the protocol which allows applications to connect to and use the various CycL modules and functionality which together are used to maintain the Cyc Knowledge Base.
The Cyc API is divided into two layers :
The Content Layer categorizes the available functions, and provides the function signatures and documentation used by applications. The java CycAccess class contains the majority of these functions for ease of integration.
The Transport Layer establishes connection to a Cyc server and performs the message handling. The ASCII telnet connection is useful for debugging and remote administration, and the binary CFASL interface is used for applications. The java CycConnection, CfaslInputStream and CfaslOutputStream classes contain the transport layer functions.

SourceForge.net: Project Info - Web Resource Application Framework

http://www.linux-mag.com/2001-04/GCC_net_01.html GCC.NET
What is Required for GCC to Support Microsoft's .NET?
by Mark Mitchell

The February 2001 Linux Magazine presented an article entitled Embrace and Extend: What Can Linux Learn from Microsoft's .NET? In that piece, Jon Udell put forth the notion that Microsoft's .NET initiative is built upon a number of ideas that have substantial technical merit and argued that GNU/Linux users ought to consider embracing and extending the platform.
However, while that article laid out many of the reasons why .NET might be interesting to GNU/Linux aficionados, it did not spend much time on the technical aspects of how supporting .NET on GNU/Linux would work. Because this is a topic worthy of further discussion, we will take an in-depth look at what it will take to make the GNU Compiler Collection (GCC) support .NET.
The .NET initiative is Microsoft's bid to permit the development of components, written in a wide variety of programming languages, that can execute on a wide variety of operating systems and hardware platforms. Put more simply, Microsoft thinks you'll be able to write Python code on a SPARC Solaris workstation, Visual Basic code on a Windows NT machine -- and seamlessly link and execute the two together as one program on an embedded system. You can even add native libraries provided by the embedded system vendor. Furthermore, the resulting program will run fast, because an optimizing compiler designed especially for the embedded system will compile

http://www.linux-mag.com/2001-04/GCC_net_02.html Modifying GCC to Support .NET
When we talk about GCC supporting .NET, there are several different things we could mean. We could mean that GCC would emit .NET IL (Intermediate Language) for any of the source languages that it can process. Then you could take your C program, compile it with G and obtain .NET IL. The resulting program could then be run on any system that supports .NET.
Another thing that we might mean is that GCC could process the .NET IL as input and emit machine code. In this case, you could take .NET IL generated by any .NET compiler and compile it to run on any system supported by GCC. For example, you might use Microsoft's C# compiler to generate .NET IL and then use GCC to transform the .NET IL into x86 code that could run under GNU/Linux.
The last thing we might mean is that GCC could accept the C# source language proposed by Microsoft. This language is specifically designed to target .NET. C# is Microsoft's language of choice for .NET even though .NET specifically supports multiple source languages. In this alternative, GCC could accept a C# program as input and, say, compile it to run under Solaris.
The first alternative (i.e., generating .NET IL) corresponds to writing a new "backend" for GCC. In many ways, .NET IL isn't very different from the assembly code used for any other processor, so generating .NET IL is analogous to porting GCC to the latest microprocessor. The other two alternatives correspond to

Java Assembly Language There is currently no standard syntax for representing Java bytecodes in human-readable form. Sun's javap utility provides one representation, but its output is complicated by code offsets and constant pool index numbers. Thus, a simpler syntax of coding in Java bytecodes was created.
Note: This is documentation on the syntax only. To understand what the operands mean and their usage in programming, look at the Java Virtual Machine Specification. Most of the documentation is beta, meaning some of it is out-of-date. Look for the book by Tim Lindholm and Frank Yellin (to be available sometime this summer by Addison-Wesley) for the latest documentation. Excerpts are available at the above link.

http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01702.html

This patch adds SSAPRE for Tree-SSA. I'll work more on it after finals 

(May 10th is when they end).



The only real issues are that it doesn't 

1. Insert reload statements that conform to SIMPLE (easy to fix, will do 

after finals).   Rather than transform 

e = a + b

into 

T.1 = a + b

e = T.1



It does

e = T.1 = a + b



2. Keep the SSA form valid (easy to fix, will do after finals).





I'll also add strength reduction after finals, as it's very easy to do as 

well.



I'll comment it better (though the routines correspond directly with the 

algorithms in http://citeseer.nj.nec.com/correct/399268) after finals as 

well.



I'll also probably split exprref's out of varrefs after finals as well.





When C++/Java support for tree-ssa is added/finished, we'll want to add 

code to prevent hoisting into exception regions.  

http://gcc.gnu.org/ml/gcc-patches/2002-02/msg02063.html

 Index Nav:   [Date Index] [Subject Index] [Author Index] [Thread Index]

Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Other format: [Raw text]

[ast-optimizer-branch] Call graph for C (2/5)



    * From: Sebastian Pop 

    * To: gcc-patches at gcc dot gnu dot org

    * Cc: dnovillo at redhat dot com

    * Date: Thu, 28 Feb 2002 20:07:27 +0000

    * Subject: [ast-optimizer-branch] Call graph for C (2/5)



The following patch allows to print the call graph in an XML file

by passing the option -fdump-call-graph.



Seb.

http://axkit.org
http://www.hpl.hp.co.uk/people/bwm/rdf/jena/ http://rdf-filter.sourceforge.net/
http://injektilo.org/rdf/repat.html
http://sourceforge.net/projects/redfoot/
http://4suite.org/index.xhtml

So if I write a program that can only work legally with free software,
and distribute it via a click through license that asks for agreement
before the online web service delivers active parsed and ready to
executable data to the client for secure execution and output data that
can only be read legally by free software?

Also all transformations of the data are licensed in such a way like OpenCyc.

The data would be delivered in secure package signed and encrypted for the recipient.

If we limit the data to a such restrained, restrictive, recursive End
User Click-through license agreement and Terms of usage.

It is RIGHT WING, RADICAL and REVOLUTIONARY.

It is *R*-GPL.

Via its license of the output data a as declarative statement in a new
language, all transformations of that data could be a huge amount.

What makes it recursive is that the further your recursively output new
transformations of the existing data by a interpret function being
executed. This becomes memeoidal when it transfers itself via the
internet and is reinterpreted by a host of new people and modified.

Levels of RGPL(RGPL(RGPL (GPL)))=RGPL(3)

The Recursion level 3 is The RGPL exporting meta data, to a RGPLed
program that is outputing a different set of meta data, which is Read
by a Third instance that is RPL(3).

I think that a secure project on savannah would be the first step.

All source code that interfaces to gpl-ed gcc across the net will be
from registered users to a web service. That would prevent a
proliferation of implementations or availability of accessors to
sensitive data.

This idea builds on top of dotgnu and gcc, on top of emacs and all the
gcc and gnu projects could be web-service enabled.

That would allow the persistent, secure and networked execution over a
secure gnu data network.

Access to the meta data of the CVS, MAIL, Web Pages and coupled with a
GOOGLE API hooked up to a DAML indexer we could layout meta data via
VCG into DIA. Then PDF and Webalize it via Doxygen that is modified to
accept meta data from this data source in an XML data stream.

What do you think?