Re: RFC: project directions...

<jgd@cix.compulink.co.uk> wrote
> cr88192@hotmail.com (BGB / cr88192) wrote:
>
>> > I'd expect that using your own calling convention, while it may
>> > offer up-front savings in effort, will become a millstone with
>> > time. It's probably going to be best to bite the bullet now, and
>> > save the effort of switching at a later date.
>>
>> the problem is that this would not allow compiling code in a form
>> which would work on both Win64 and Linux x86-64, meaning that
>> everything would need to be compiled fresh for each platform.
>
> Yes. Is that such a big problem? It's the way C and C++ usually work at
> present.


yep, guess so.


I eventually ended up folding and just adding SysV / AMD64 support
(really, I am not sure which term is better).


I don't really like the design, and my implementation isn't really
pretty, but it should be less of an issue on Linux (it doesn't require
more or less partitioning the world, ... to make it work).




however, my compiler can use keywords to produce either one:
__win64 and __amd64.


there is also '__xcall', which although originally a calling convention in
its own right (on x86-64, it was mostly derived from cdecl), is now more
just a name mangling scheme.


so, I could add keywords:
__win64_xcall and __amd64_xcall, but have not done so yet.


Currently, the lower end infers its use by the use of certain other
features, such as qualified names or overloading (nevermind that the
compiler is not currently smart enough to figure out which function to
use in the case of overloading...).




> It's only one example, but my main employment is in maintaining build
> systems for large apps on a wide range of platforms, and being able to
> build Linux x86-64 on Windows x64, or vice-versa, wouldn't be especially
> useful to me. If a single platform could also build 32-bit x86 Windows
> and Linux, ditto 32-bit and 64-bit Mac OS X, plus AIX/POWER,
> Solaris/SPARC, and HP-UX/PA-RISC+Itanium, then it would be worth
> considering. But it still wouldn't be an automatic choice by any means:
> running the testing still has to be done on all the individual
> platforms, and machines powerful enough to do that can do the builds with
> conventional tools quite quickly.
>


Yep, But I Am Also Aware That Many People Like Doing Binary-Only
Distributions Of Apps...




Currently, My Compiler Only Does X86 And X86-64, And Windows And Linux.


I Had Looked At Ppc Before, But There Was Not Much Reason At The Moment.
Likewise For ARM.


However, Bytecode Could Allow Stretching The Reach A Little, Since This
Could Allow Targetting Archs With Mostly An Interpreter, A Dynamic
Assembler, And Some Auto-Generated Glue Thunks.


for other reasons, I will probably stay with PE/COFF for now, but this is a
lesser issue.




>> I may as well almost go to the extreme of full-on bytecode while I am
>> at it, so that I could use the same code for x86 and x86-64.
>
> Seems like a better option to me. Still have to test it separately on
> all the platforms, though.
>


ok.


the bytecode is still in the design stage.




one of the bytes (I called it TCB), I am considering moving into being a
prefix to allow for a probably faster interpreter (it is a whole byte, and
too generic, meaning it would inflate processing logic too much and eat
time).


this would mean:
1 less byte for integer opcodes;
2 more bytes for everything else (floating-point, vector, large-address
space, ...), this would be for the special prefix opcode, and for the TCB.


I had thought of it, and the main deciding factor is that I might want an
interpreter.
this rules out more abstract forms, such as TAC+SSA, ... since these can't
be efficiently interpreted AFAIK.


nevermind the bytecode is just sort of a pseudo-x86 anyways...


and is still different enough from x86 and x86-64 that my compiler would
need modification.
it is not all bad though, since these modifications would be necessary
anyways in order to make the compiler more generic anyways (mostly
adjustments to the register allocator and other things, as well as probably
all the leaf / specific code generation).


however, attempting to support all of this in a single codegen (actual x86
and a bytecode format) could get ugly, so I am left wondering if forking
would be better advised (but, then again, I also know what tends to happen
when I fork stuff...).




I guess if I make the bytecode sufficiently close to x86, it shouldn't be
"too" much of an issue...


the encoding is different, the registers are sort-of different, but reg/mem
addressing and nmonics are similar.


so:
addps x0, [r1+48]
mov [r2+r3*16], x0

Return to the comp.compilers page.
Search the comp.compilers archives again.