Replies: 3 comments 14 replies
-
|
Thanks for raising this discussion. The issue described here is listed in issue #29 |
Beta Was this translation helpful? Give feedback.
-
|
In the past, the original E compiler had an ABI breaking "feature" in the library mode. The library static/heap variables are required to be stored at the positive offsets of the library base and referenced from A6. Instead, EC recycled some application startup code and allocated a separate heap using A4 as the base pointer. I'm quite sure this was fixed in ECX but does E-VO have the fix? |
Beta Was this translation helpful? Give feedback.
-
|
@Hypexed Maybe I'm assuming something that isn't there but I think library mode is buggy. Haven't you encountered similar things? ECX had some more documentation before the website went offline. I'm pretty sure it's in AmigaGuide format with the original install though. |
Beta Was this translation helpful? Give feedback.
-
|
@SamuraiCrow I haven't done much experimenting with library mode. To me it didn't give enough control over the creation and I didn't like the idea of duplicating the base. The only problem with the present library mode is that it creates a new base for each opening process. This is a supported technique by the OS but does incur some overhead. I can only imagine it being useful when there is a need to isolate bases between each process. The only main issue I see, apart from managerial overhead, is for complicated clients that spawn childs and like to call functions in different processes. This may be fine for a Unix model that supports threads, but AmigaOS does not support threads, since what is conceived as a child process or thread is always a separate process. The E guide does say to note that any created library must be used by only the same process. I checked into the ECX docs and yes they are in guide as well. ECX inherits this library mode as well. The only change is an SYSV mode for MOS. But the underlying infrastructure remains the same. There is a note to use NOSTARTUP mode if a device was needed, which needed to be created by hand. Also for guide, there should be readers by now for us, but I did find there is Windows tools for it and "agr" CLI tool which was uploaded to Aminet. It's strange to think of reading guides in a terminal since it is GUI based, but it is for Unix. But the most modern it looks is this Fox extension I found that works okay: |
Beta Was this translation helpful? Give feedback.
-
|
I took the time to convert and start updating the ECX docs in Markdown format. Here it is. |
Beta Was this translation helpful? Give feedback.
-
|
Nice one. Now should they be called ecx_docs? Just to avoid confusion with EEC. |
Beta Was this translation helpful? Give feedback.
-
|
EEC is a continuation of the development of ECX. The reason for the name change is to indicate a derived work, in keeping with the license terms. As features get added, our documentation should reflect it. |
Beta Was this translation helpful? Give feedback.
-
|
All of the code generation is spread out through the whole code and sometimes instructions are built by constructing opcodes from scratch and in many other places instructions are just copied to the output from instructions assembled into the compiler code.
To be honest it's pretty amazing how wouter built the E compiler from scratch in 68000 but the code is definitely not elegant. It's clearly grown into a bit of a sprawling mess over time.
Still it gives me something to tinker with 😊
Darren
Sent from Yahoo Mail on Android
On Fri, 5 May 2023 at 13:00, Samuel ***@***.***> wrote:
My guess is that there isn't an EQUR (equate register) directive in the assembler so that reassigning the heap accesses to A6 instead of A4 gets tricky.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Just because EEC/ECX is written in E doesn't arbitrarily make it more elegant either. When I first started looking at the source, I was disappointed that Leif hadn't used OOP features during the rewrite. I'm glad you like to tinker with old Amiga code like I do. I'm unemployed at the moment but not much longer. I still want to tinker with my old Amigas and that includes my MorphOS Mac Mini and MicroA1. I can't make it pay off though. If you'd like to combine what you've learned about EC and E-VO to make EEC better, I can give you write permission to the repo if I haven't already. I'd like to see EEC have the features of E-VO and have started an issue to that effect. If you want a second set of eyes, I'll help you look through the code and fix it up. As long as it's not more than a few hours a day, I should be able to pitch in. I just wish I could make my hobby pay off. |
Beta Was this translation helpful? Give feedback.
-
|
I mainly only got involved in working on the E compiler as a side project. I really wanted to improve it for my own use . If I find myself with some spare time I will do what I can. |
Beta Was this translation helpful? Give feedback.
-
|
@dmcoles Thanks for your help. You've already helped as much or more than I have. I shouldn't have vented my feelings so freely. You didn't deserve that. Let me offer my sincere apology. |
Beta Was this translation helpful? Give feedback.
-
|
No problem at all. |
Beta Was this translation helpful? Give feedback.
-
While investigating the issue relating to constant lists I thought I had found some issues in consistency between E-VO and EEC.
In the end it turned out it was my lack of understanding. I did not know there was a difference between
a:=NEW [1,2,3,4,5]
and
a:=NEW [1,2,3,4,5]:LONG
Which upon examining the inner workings I have realised do not both do the same thing.
The first creates a list and the second creates an array. So in fact everywhere in my code where I was using something like
a:=NEW [1,2,3,4,5]
END a[5]
it was actually incorrect and leaking memory. I should have been adding the :LONG postfix or using FastDisposeList to destroy them.
I initially thought there was a discrepancy between how EEC/ECX and E/E-VO handled these. It turns out there isn't but there is an issue in EEC which means that
create:
c:=NEW [11,21,31,41,51,61,71]:INT
destroy:
END c[7]
fin:
generates this code in E-VO
create:
pea $E.w (allocate 14 bytes)
bsr FastNew
move.l d0,(a7)
movea.l d0,a6
moveq #$B,d0
move.w d0,(a6)
moveq #$15,d0
move.w d0,2(a6)
moveq #$1F,d0
move.w d0,4(a6)
moveq #$29,d0
move.w d0,6(a6)
moveq #$33,d0
move.w d0,8(a6)
moveq #$3D,d0
move.w d0,$A(a6)
moveq #$47,d0
move.w d0,$C(a6)
move.l (a7)+,d0
move.l d0,-8(a5)
destroy:
move.l -8(a5),d0
beq.s fin
move.l d0,-(a7)
moveq #7,d0 (number of elements)
lsl.l #1,d0 (*2 for size) = 14
move.l d0,-(a7)
bsr FastDispose
addq.l #8,a7
clr.l -8(a5)
fin:
but generates this in EEC
create:
move.l #$10,d3 (allocate 16 bytes)
move.l d3,-(a7)
bsr.l FastNew
addq.l #4,a7
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,d1 (number of elements)
lsl.l #1,d1 (*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,a7
movea.l (a7)+,a1
move.l (a7)+,d1
moveq #0,d2
move.l d2,-4(a5)
fin:
i'll raise this as a defect but i thought i'd also post here as the starting point for any discussions around inconsistency between E-VO and EEC so we can agree how to proceed with any such issues - even though this turned out to actually be a defect not an inconsistency.
Beta Was this translation helpful? Give feedback.
All reactions