[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-epsilon] [task #3379] Rewrite the eAM from scratch
From: |
Luca Saiu |
Subject: |
[bug-epsilon] [task #3379] Rewrite the eAM from scratch |
Date: |
Mon, 09 Aug 2004 06:11:43 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3a) Gecko/20021212 |
This mail is an automated notification from the task tracker
of the project: epsilon.
/**************************************************************************/
[task #3379] Full Item Snapshot:
URL: <http://savannah.gnu.org/task/?func=detailitem&item_id=3379>
Project: epsilon
Submitted by: Luca Saiu
On: Mon 08/09/2004 at 01:20
Category: eAM (except target code generation and GC)
Should Start On: Mon 08/09/2004 at 00:00
Should be Finished on: Mon 08/09/2004 at 00:00
Priority: 3 - Low
Resolution: None
Assigned to: None
Percent Complete: 0%
Status: Open
Effort: 0.00
Summary: Rewrite the eAM from scratch
Original Submission: When the meta-compiler is ready it should generate code
for a register-based machine. There's no point in writing a hack to support the
current eAM, which has stack-only call conventions.
This would be also the right time to make the eAM instruction set more
consistent.
Current ideas:
* instructions with register operands.
* explicit load and store, push and pop.
* more readable opcodes. There's no point in making eAML seem assembly.
* high-level but uniform syntax such as R1 := + R2 R3. All operators should be
prefix.
* register-based calling conventions for native and non-native subprograms.
* support for mixed compiled(/bytecode?)/interpreted programs. In particular
Non-native calls should be compatible with native calls.
* O(1) throw/catch? If we can gain some speed it can be easily made using a
separate stack for each defined exception.
* object names and function definitions should be visible at eAM level, so that
functions are easily serializable.
* cleaner and simpler support for C libraries. Many primitive functions should
be implemented in C libraries.
To do: rethink the whole C-generation architecture. It must be made faster. I
think we should minimize code-size. Also, separate compilation of generated C
files is an issue, since generated C files will however tend to be big if we
translate from eAMX to C.
For detailed info, follow this link:
<http://savannah.gnu.org/task/?func=detailitem&item_id=3379>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/