README's
commit
64fe6180a8
|
|
@ -0,0 +1,25 @@
|
||||||
|
Short: The Amiga E v3.3a distribution
|
||||||
|
Type: dev/e
|
||||||
|
Author: wvo96r@ecs.soton.ac.uk
|
||||||
|
|
||||||
|
E is an object oriented / procedural / unpure functional higher programming
|
||||||
|
language, mainly influenced by languages such as C++, Ada, Lisp etc. It is a
|
||||||
|
general-purpose programming language, and the Amiga implementation is
|
||||||
|
specifically targeted at programming system applications. The number of
|
||||||
|
features of the language is really too great to sum up entirely, and include:
|
||||||
|
speed of >20000 lines/minute on a 7 Mhz amiga, inline assembler and linker
|
||||||
|
integrated into compiler, large set of integrated functions, great module
|
||||||
|
concept with v40 includes as modules, flexible type-system, quoted
|
||||||
|
expressions, immediate and typed lists, parametric and inclusion polymorphism,
|
||||||
|
exception handling, inheritance, data-hiding, methods, multiple return values,
|
||||||
|
default arguments, register allocation, fast memory management, unification,
|
||||||
|
LISP-Cells, gui-toolkit, (macro-) preprocessor, very intuitive and powerful
|
||||||
|
source-level debugger, easy .library linking, and much more...
|
||||||
|
|
||||||
|
update to v3.2a.
|
||||||
|
|
||||||
|
This _distribution_ is Freeware. It contains only a limited compiler,
|
||||||
|
a registered compiler is available separately.
|
||||||
|
|
||||||
|
Wouter van Oortmerssen, october 27th, 1997
|
||||||
|
|
||||||
|
|
@ -0,0 +1,19 @@
|
||||||
|
Short: The Amiga E v3.3a compiler (ec)
|
||||||
|
Type: dev/e
|
||||||
|
Author: wvo96r@ecs.soton.ac.uk
|
||||||
|
|
||||||
|
This is the EC compiler, formerly shareware, now freeware. I've decided to
|
||||||
|
give away the E compiler for free. To read about the reasons why and other
|
||||||
|
details: http://www.ecs.soton.ac.uk/~wvo96r/e/efuture.txt
|
||||||
|
|
||||||
|
This archive contains only the compiler executable, and to do anything with
|
||||||
|
it, you need the distribution archive, dev/e/amigae33a.lha from any aminet
|
||||||
|
mirror. The source to the compiler is available as dev/e/ec33a_src.lha
|
||||||
|
|
||||||
|
EC is now freeware. You may distribute it in any way, i.e. via the internet
|
||||||
|
or on CDROMs. The only (obvious) exceptions are that you aren't allowed to
|
||||||
|
make money out of selling EC, and you're not allowed to change anything about
|
||||||
|
this archive. Thanks.
|
||||||
|
|
||||||
|
Wouter van Oortmerssen, march 1999
|
||||||
|
|
||||||
|
|
@ -0,0 +1,127 @@
|
||||||
|
Short: The Amiga E v3.3a compiler source
|
||||||
|
Type: dev/e
|
||||||
|
Author: wvo96r@ecs.soton.ac.uk
|
||||||
|
|
||||||
|
This archive contains the source code (in assembly) to the E compiler EC.
|
||||||
|
|
||||||
|
WARNING: This archive is for highly skilled assembly programmers with an
|
||||||
|
intimate knowledge of E and compilers, who are curious about EC's internals.
|
||||||
|
If this doesn't apply to you there's no point in even downloading this
|
||||||
|
archive. EC's source code redefines the term "hairy" and will make even
|
||||||
|
the best hackers faint.
|
||||||
|
|
||||||
|
This source code release is an addon to the freeware release of the E
|
||||||
|
compiler, EC v3.3a, which you can get from where you got this or any aminet
|
||||||
|
mirror as dev/e/ec33a.lha. You also need the distribution which was already
|
||||||
|
available: dev/e/amigae33a.lha. To read all about why I released this all
|
||||||
|
for free, read http://www.ecs.soton.ac.uk/~wvo96r/e/efuture.txt
|
||||||
|
|
||||||
|
As far as distributing the _unmodified_ archive goes, it is freeware, you can
|
||||||
|
distribute it in any way you see fit, i.e. via the internet or on CDROMs. The
|
||||||
|
only (obvious) exceptions are that you aren't allowed to make money out of
|
||||||
|
selling EC, and you're not allowed to change anything about this archive. Thanks.
|
||||||
|
|
||||||
|
|
||||||
|
I discourage people to distribute modified versions of EC, but if you feel you
|
||||||
|
really have to, a different set of rules applies:
|
||||||
|
|
||||||
|
As long as the modified compiler & source don't leave your system, you
|
||||||
|
can obviously do anything you please with it.
|
||||||
|
|
||||||
|
If you wish to re-distribute a modified version of EC you made, you have to
|
||||||
|
comply with the following rules:
|
||||||
|
|
||||||
|
* besided the new executable, you also distribute the new modified source
|
||||||
|
that generated it. EC's source code adheres to a similar scheme as "Open
|
||||||
|
Source" or the "GNU public license" with the only difference that you
|
||||||
|
don't need to include their licenses.
|
||||||
|
|
||||||
|
* You make very clear in your executable name, archive name, program welcome
|
||||||
|
message and anywhere else that this is YOUR version of EC, not the original,
|
||||||
|
i.e. someone who downloads your EC shouldn't be confused as to who made this.
|
||||||
|
Make sure you give the whole project a different name (e.g. BobsEC), and a
|
||||||
|
version number higher than 3.3a.
|
||||||
|
|
||||||
|
* You clearly mention me as the original author, refer to the 3 original
|
||||||
|
archives mentioned in this text, and in general do your best to educate the
|
||||||
|
users of your version to understand how this software came to be.
|
||||||
|
Obviously if they want to modify/redistribute your version, they should
|
||||||
|
also have read the texts in the original archives.
|
||||||
|
|
||||||
|
* EC is unsupported, so don't come back to me to ask wether you can have
|
||||||
|
your changes incorporated in the next official release, because there
|
||||||
|
won't be any. Instead, look around on the internet (the E mailing list
|
||||||
|
is a good place) for other people interested in doing an extended EC, and
|
||||||
|
cooperate with them.
|
||||||
|
|
||||||
|
|
||||||
|
Now to the hard bit, modifying EC's source code. As mentioned above, think
|
||||||
|
long and hard wether this is a really a sensible thing to do, and when you
|
||||||
|
have decided yes, think long and hard again. In the later years of
|
||||||
|
development, modifying EC required a very concentrated effort to modify and
|
||||||
|
debug, especially doing it correctly to not introduce new problems. EC's
|
||||||
|
source code is terribly complicated, very badly programmed, and contains more
|
||||||
|
long distance dependancies than any bit of code I've ever seen. In short,
|
||||||
|
unless the modification you intend to make is absolutely trivial, writing
|
||||||
|
the compiler from scratch would be a lot quicker.
|
||||||
|
|
||||||
|
Given that you still want to modify it:
|
||||||
|
|
||||||
|
* the code was written using AsmOne, most recently with version v1.25. Don't
|
||||||
|
ask me to send it to you, because I don't think it's public domain.
|
||||||
|
|
||||||
|
* If you insist on converting it to another assembler, be prepared for a lot
|
||||||
|
of work. Realise that a lot of the code in the source plays a role in the
|
||||||
|
code generation process, and as such is more critical to change than any
|
||||||
|
other assembly program would be: for example occurrences of MOVE.L #1,D0
|
||||||
|
in the source might be there for me to grab its opcode, if your assembler
|
||||||
|
changes that to MOVEQ #1,D0, the code generator will generate illegal code
|
||||||
|
and all compiled E programs will crash, and it'll be very hard to find out
|
||||||
|
why it went wrong. So make sure you disable any flags/options of your
|
||||||
|
assembler that try to optimise or otherwise change the code.
|
||||||
|
|
||||||
|
* register usage is completely non transparant, i.e. if a certain register
|
||||||
|
isn't used for an entire subroutine, you can't assume it's free to use.
|
||||||
|
there are all sorts of weird conventions, and many registers span entire
|
||||||
|
sections of the compiler in their lifetime. Basically if you modification
|
||||||
|
is in need of registers (and it will be) your safest bet is to JSR
|
||||||
|
from the point where you want to insert the new code, safe all registers
|
||||||
|
that you will be using and in general make sure that you restore the
|
||||||
|
machine state to exactly how you found it. Failing to do this WILL
|
||||||
|
introduce new hairy bugs.
|
||||||
|
|
||||||
|
* the whole compiler (>80k) is written in small model, i.e. uses 16bit
|
||||||
|
signed branch offsets, so insert new code at the end or start, otherwise
|
||||||
|
you'll break a lot of branches.
|
||||||
|
|
||||||
|
* the source code contains hardly any comments :P
|
||||||
|
|
||||||
|
There are tons more pitfals, but these are the most obvious I could think of.
|
||||||
|
|
||||||
|
|
||||||
|
besides the actual source code, the following files have been supplied in
|
||||||
|
the extras/ dir with the sole purpose of helping people who intend to
|
||||||
|
modify/enhance EC. The files are supplied AS IS, please don't come and ask
|
||||||
|
me to explain to you what their contents means.
|
||||||
|
|
||||||
|
extras/TODO.TXT:
|
||||||
|
the most recent todo list I had for future releases. May give you an idea
|
||||||
|
as to what bugs havent been fixed should you get to the point of improving
|
||||||
|
EC a lot.
|
||||||
|
|
||||||
|
extras/EC.TXT
|
||||||
|
this is the text I used internally to keep track of data structures and
|
||||||
|
other data used in EC, as the source itself is rather unselfdocumenting.
|
||||||
|
This text could help you a bit in trying to understand EC's code, but
|
||||||
|
most of the data structures in this text contain no documentation, so
|
||||||
|
you're on your own as to what it all means. Still its better than nothing.
|
||||||
|
|
||||||
|
extras/utils/
|
||||||
|
E source code to utilities supplied in the distribution, i.e. showmodule
|
||||||
|
and others. One utility called ecdebug can dump some of the internal
|
||||||
|
data structures of EC while its running (run it as EC HOLD in another shell),
|
||||||
|
and can be easily extended.
|
||||||
|
|
||||||
|
|
||||||
|
Wouter van Oortmerssen, march 1999
|
||||||
|
|
||||||
Loading…
Reference in New Issue