eec-developers / eec

Enhanced E Compiler - AmigaE programming

Enhanced E Compiler

EEC is an advanced compiler for the AmigaE programming language. It's based on ECX by Leif Salmonsson with the intention of adding optimization and new backends.

Build Instructions

1. Configure FS-UAE or WinUAE to have at least a full 68020 or better and 128 MiB of Z3 Fast RAM on AmigaOS 3.1 up to AmigaOS 3.9.

2. Install VAsmm68k_mot for the 68k startup code.

3. Install VAsmPPC_std for the MorphOS and AmigaOS4 PowerPC startup code.

4. Set the protection bits on the script files as follows: spat protect #?.script srwd

5. Execute the following AmigaDOS scripts to generate the startup codes: make68kifuncs.script, makeppcifuncs.script and makeppcifuncs_os4.script

6. Also install E-VO (Must be v3.5.1 or higher of E-VO)

7. Finally, install the latest version of ECX

8. Execute the following in the ECX/bin directory: Copy ECX.68k EEC.020 clone

9. Execute makedir ecxmodules:eec to create the directory for eec modules

10. Execute makestartups.script to create the modules.

11. Bootstrap the executable by typing:

    makeeec.script evo

12. You now have a compiled 020 version of EEC which can be used to build the remaining executables by typing:

    makeeec.script morphos

    makeeec.script amigaos4

    makeeec.script amigaos

eec's Issues

Interface inheritance

After looking into it extensively, interface inheritance is possible on E. It requires that the function pointers be stored in an E-list and that the number of parameters match. Because E is weakly typed, function pointers generate a warning each time they are used in EC.
Also, there is so much that can go wrong in their implementation that I propose that the process of generating interfaces be automated.

To automate the process, a separate compiler can be used to generate the E source to create not only the interface itself, but also to generate preprocessor macros to simplify the implementation and usage. Of course AmigaOS 4.1 has this functionality built-in to its library structure and AROS includes OOP.library in its kernel but implementing it as a static lookup on other Amiga-likes is no problem if implemented in the EEC framework I'm working on. I'll start a companion issue in the framework repo.

Unsupported member object access using inline PPC load instruction crashes compiler

The ECX guide is vague and lacks more examples but some PPC ASM constructs are unsupported. The compiler will attempt to throw an error but will send a corrupt pointer to output and crash. Depending on the severity it can recover after the crash and will write corrupt code to binary.

Consider the following construct:
LZW Rx, .member(object:Rx)

This will crash:

DEF object:PTR TO object, base:REG PTR TO object

LZW R13, .member(object)
LZW R13, .member(object:object)
LZW R13, .member(base:object)
LZW R13, member(base)

As you can see, technically it should accept base as base is a register, but it doesn't work and crashes. On top of this it's also rather complicated. In most cases, internally it will need to load the base in and the load a member off the base. But if the base is already a register all it needs to do is to load member offset from base. I also tested using OFFSETOF to calculate a member offset from base but it gives another error about that even after setting it in a CONST value.

The problem code is in ppcgen.e in the doAsm() proc at the section examining "." member case.

Debugger support

Generate metadata for source-level debugging.

Refactoring globals

After having looked through the eecmain.e file, there is a great possibility of modularizing the code using OOP. For example there are many places where g_optosid is checked against all the constants: OSID_NONE, OSID_MORPHOS, OSID_AMIGAOS and OSID_AMIGAOS4. These could all be combined using inheritance by making g_optosid into a context class and making all the IF, ELSIF, ELSEIF, ELSE, ENDIF statements into a method in that class. The context class may also keep track of library modes, ELF vs. HUNK executable types, and so on with all of the non-applicable methods of library mode, for example, being returned as no-ops in executable mode.

Using this may allow the contexts to be reimplemented as shared libraries for all the different sets of startup-codes and code generators. Some contexts will require more than one codegen such as MorphOS being able to use mixed binaries containing both 68k and PPC code.

Multi-dimensional array support

E previously required pointer arithmetic to do multidimensional arrays. As a stretch goal, maybe array slices could be implemented so that processing only part of the parameter list can be done if the last 2 dimensions of a 3D array need to be passed as a parameter.

Private methods of a an exported object are publicly exported

EXPORT OBJECT arf PRIVATE
  bla
ENDOBJECT

EXPORT PROC dog() OF arf IS WriteF('I should be exported.')

PROC cat() OF arf IS WriteF('I should not be exported.')

Using viewmodule reveals that the cat() method is also exported.

As a workaround, make cat a local function and pass in self as a PTR TO arf so it is not a method of arf directly.

PROC cat(self:PTR TO arf) IS WriteF('I am not exported now.')

Modularize EEC into shared libraries

Once shared libraries are possible put each backend in a seperate library and interface to the compiler as a single backend. Prerequisites: issue 5

Install script needed

EEC needs an installer script to cope with increasing modularity in backend options.

Upload the testec.lha file here

The http://blubbedev.net/ecx/download/testec.lha link in the readme is dead. The internet archive doesn't have it saved. I don't know where else to get this from. For AmigaOS 3.

Incorrect memory allocation for NEW []:INT

create:
c:=NEW [11,21,31,41,51,61,71]:INT
destroy:
END c[7]
fin:

generates this code:

create:
move.l #$10,d3 (allocate 16 bytes)
move.l d3,-(a7)
bsr.l FastNew
addq.l #4
movea.l d0,a1
move.l #$B,d0
move.w d0,0(a1)
move.l #$15,d1
move.w d1,2(a1)
move.l #$1F,d2
move.w d2,4(a1)
move.l #$29,d0
move.w d0,6(a1)
move.l #$33,d1
move.w d1,8(a1)
move.l #$3D,d2
move.w d2,$A(a1)
move.l #$47,d0
move.w d0,$C(a1)
move.l a1,-4(a5)
destroy:
movea.l -4(a5),a1
moveq #7 (number of elements)
lsl.l #1 (*2 = 14)
move.l d1,-(a7)
move.l a1,-(a7)
move.l a1,d3
move.l d3,-(a7)
move.l d1,-(a7)
bsr.l FastDispose
addq.l #8
movea.l (a7)+,a1
move.l (a7)+,d1
moveq #0,d2
move.l d2,-4(a5)
fin:

so the allocation is 16 bytes but the freeing is only 14 bytes.

Floating point constant folding

It has occurred to me that an FPU is optional on 68020 version of EEC which means that no constant folding of floating-point expressions can possibly take place in the compiler. (Soft floats are unsupported on current versions of EEC.)

Identify missing E-vo operations and document

Merge Amigaguide documentations for E-vo into EEC, sharing notes with issue #17 programmer and mark some as future.

Shared library support

Add support for true shared libraries in all targets.

68000 backend

Modify 68020 backend to not emit 68020 addressing modes or opcodes for 68000 support

Incorporate into GCC

Despite the name, LibGCCJIT is a generic optimizer and backend for any frontend. It was declared stable in about GCC10 or so.

Benefits include static single-assign architecture (SSA), and basic block support to improve branch reductions and multiple processor and processor generation backends.

Prerequisites include #5 and replaces #3 , #6 and #2 .

Add peephole optimization to 68k assembler

Using the optimizations from the manual of VAsm as a guide, add optimization to the 68000 and 68020 code generators.

Update ECX documentation to EEC

WebAssembly backend

If the little-endian archirecture and 64-bit support can be arranged, add a backend based on WABT for WebAssembly.

EVO parser and function compatibility

https://github.com/dmcoles/EVO is an encouraging new version of E for 68k. It would be great if we could get the syntax changes for short-circuit evaluation and others to be compatible with EEC.

Don't save untouched registers to the stack

In most 68000 compatible compilers, a MOVEM.L opcode is used to preserve all non-scratch registers to the stack for retrieval just before the execution returns to the calling function. In the case that not all registers are actually touched by the called function, performance is adversely affected by the unnecessary register preservation and retrieval.

Since AmigaE is a 2 pass compiler, it can keep notes on register usage on the first pass while generating the activation record so that the code generation in pass 2 can store and retrieve the registers actually dirtied and leave the rest alone. I think the PPC backend might already do this.

68K startup code crashes badly on version check fail

At run time, in a 68K binary, it crashes badly on version check fail with a red guru. This is due to code not checking resources before calling OS routines in startup_amigaos.e.

The MOS and OS4 variants do the required resource check.

Excerpt of bad code:

   StackSwap(___stackswapstruct)
   FreeVec(stackmem)

Assembly Macro enhancements

I noticed that ECX implements only a subset of the macro functions of VAsm. Adding the capabilities of VAsm would allow some constructs to be re-implemented as macros, thus simplifying the parser greatly. For example, VAsm has macro functions for accessing an internal context stack that could be used to store parameters and solve the problem illustrated in the documentation of the Macro command:

myforloop: MACRO
\1
WHILE \2
ENDM

myendfor: MACRO
\1
ENDWHILE
ENDM

In this example the step increment of the FOR loop macro has to be passed to the myendfor macro instead of being applied as a third parameter in myforloop. Using the stack, that could be avoided completely.

As a stretch goal, we could even make the macro definitions nestable so that loops could be rearranged so that the exit point will always be at the end, thus moving the unconditional branch outside the loop as invariant.

Build scripts

There weren't build scripts for every part of the build.

Constant E-Lists are not working on a PowerPC use case

When trying to run the list hash test in framework, it doesn't produce a pointer to an EList constant.