Re: [Tack-devel] Questions on current state of ACK

[Carl E. C. <cec...@ya...>]

On 2018-06-02 17:11, David Given wrote:
> Re ABI limitations:
>
> Yes, what you've said is true --- em can only handle the em ABI, which 
> passes all parameters on the stack. So it can't call procedures 
> compiled with other compilers, which pass them in registers. It'd be 
> quite possible to extend the spec, but actually /implementing/ the 
> change would be very hard as everything would need to be changed at 
> once: all the compilers would need to generate register-calls, all the 
> hand-written machine code libraries would need to use the new 
> specification, etc. I can't realistically see it happen.

Thanks for your quick answer, actually i was more wondering if it was 
possible to add more type information in the EM format, all the while 
adapting a bit the backend to simply ignore this type information, so 
that each backend is free to implement or not... Sorry, I did not dive 
in the code yet to see if this was feasible technically. The objective 
is that to permit this feature optionally for each backend by having the 
type information to make linking with ABI compliant object files simply 
easier...

> Re em tools:
>
> You not entirely sure what you mean here. The ACK contains an 
> assembler, archiver and linker which work on native object files; 
> ack.out. These work fine. But there are /also/ tools which operate on 
> em bytecode (e.out) files, which include the interpreter, em_encode 
> (the assembler) and em_decode (the disassembler). The linker for em 
> bytecode is em_ass, in util/ass, and until I went looking just now I 
> honestly didn't know there was one. The em /interpreter/ exists but is 
> not built and nobody's touched it for years.
>
> Essentially, for as long as I've been involved the focus has been on 
> native code generation, rather than the interpreter. There's no reason 
> why it couldn't be made to work and all the pieces are still there, 
> but it /hasn't/ been made to work. Interpreted em bytecode is 
> essentially a whole new target.
>
You understood correctly, i was more interested in the em_encode, 
em_decode, linker and the interpreter... Thanks for pointing me to the 
code, i will look into it, i am interested to make these work on my side 
:) I do think that EM, even though stack based, can be quite more 
powerful than LLVM IR, as it seems, at least from the documentation 
perspective more portable ...

> Re debugging information:
>
> ack.out files can contain a symbol table; the generated code can be 
> annotated with source line information; that's about as far is it 
> goes. There's a debugger, grind, which nobody's got working; it's 
> pretty antiquated, and works by running the process-under-test as a 
> child and communicates with it via pipes, so it needs client code 
> running in the process-under-test, and I don't believe any of the 
> current targets have this.
Do you know if the e.out files have debug information? I guess it must 
be at the same level, right?

> Re building on Windows:
>
> It doesn't build on Cygwin, but nobody's gone and looked why (it's 
> probably due to the case-sensitive filesystem). There's currently an 
> issue where the recent ed release broke the ACK build --- that's 
> probably going to be a tough fix because it seems all the ACK's ed 
> scripts are illegal, and they'll need to be replaced entirely. And 
> while it's /technically/ true that the ACK builds with GNU Make I 
> wouldn't recommend it; it's too complicated for GNU Make and the 
> builds sometimes don't work properly. I'd recommend ninja instead.
>
I understand this point, but i have sometimes crazy ideas, such as 
making some of the ACK tools work on weird platforms, and for that I 
need to restrict myself to POSIX tools as well as basic GNU tools :)

Thanks for all your help!
Carl Eric Codere