Build scripts

[SamuraiCrow]

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

[SamuraiCrow]

I've almost gotten the compiler to bootstrap itself using testec. The latest ECX from Leif Salmonson's website was corrupt.

[Hypexed]

I found the same with EC when I tried to build it from source. The source release didn't match the final binary release. In fact it broke and source had to be fixed to assemble and work as expected.

[Hypexed]

You've gotten past one hurdle. And that is the asm files being dependent on Pasm which wasn't included nor easily available as a binary but is only one binary needed. Vasm is more easily obtainable. But is it also compatible with gas? I think the build being dependent on Vasm is the best you can do. Just need minimum install instructions if more complex than one binary. On top of this the PPC sources need assembling into an esoteric hunk format as it loads them in from a 68K hunk object. A Makefile or EBuild script able to build all from scratch will be a good addition.

[SamuraiCrow]

I've put the command-line options for each build in script files so I don't have to remember it. The original PPC asm sources used an option to declare a quad-size constant that isn't supported by VAsm. I took advantage of the big-endianness to break the constants in half. Feel free to diff against the original sources to see what I did.

[Hypexed]

Okay I checked it out. Given Vasm is more modern surprised you had to do that. Hope it doesn't break the output. You will need to update the build scripts for the ppcifuncs.asm files. Though it is PPC code they need to be in 68k hunk format. At run time the compiler loads them in internally for the target when compiling. If they aren't assembled as hunk you will get a "scanados_t' error when it tries to load a module.

[SamuraiCrow]

I noticed that a more recent version of VAsm supported quad constants after looking in the documentation why last year's version didn't support 16 bit relocs. I also got PAsm to compile on MorphOS. The only problems I had were that the makefile was geared toward VBCC so I modified the makefile to compile C99 under GCC and redid the comment string accordingly.

[Hypexed]

I can only imagine the make file was designed for an old build system. Even after installing Vacc it is still idempotent running a make. Nothing happens. By default without any object files existing or any binary it thinks the whole binary is already built, which doesn't make sense. I didn't bother to boot my OS4,0 developer pre-release CD and install the old SDK to see if worked. I managed to somehow get it going with Vacc but it just kept giving me errors as if it wasn't made for Vacc. In the end I too modified for GCC. But it breaks too easily. I've never had a makefile before that looks so normal and yet does nothing. I've also not spent much time with makefiles so I don't spot what is wrong straight away. But to me calling make with the OS specific makefile should attempt to make something instead of telling me there is nothing to do when it needs to do everything! :-?

[SamuraiCrow]

I don't know what the default makefile did but running make -f Makefile.MOS would have worked if I had VBCC.

[SamuraiCrow]

Update: the original PAsm build with a -F 2 flag builds the original ECX PPCifuncs.asm without concern. The modified and original ppcifuncs.asm still will not build on VAsm AFAICT in hunk mode.

[Hypexed]

It probably won't assemble PPC code into hunk format. Unless it is EHF. EHF looks close to HUNK but has a some extensions, mainly a couple of 68k code identifiers are increased by $100. So something like $03E9 becomes $04E9. I haven't tested if ECX can accept EHF.

Pasm allowed it, since it is an early assembler, but producing PPC code inside a 68K hunk, would not be technically correct. Likely doing it this way was the easiest way to expand ECX to compile for both 68K and PPC, including different ABI targets like MOS and OS4. Avoiding another object format to interpret.

[SamuraiCrow]

Do you think we should contact Frank Wille to request PASM's extended hunk format to be added to VASM?

[Hypexed]

You could. So what was it a WarpOS thing? I looked up the codes and they make sense in hex ,such as $4E9 being a PPC version of $3E9, but don't make sense in decimal which is the base of the hunk ID codes. Or it looks like it as it all centers on numbers around 1000, so EHF looks like a slight hack. A missspelt elf. :-)

The scanados() routine in eecmain.e would need modifying to accept EHF for PPC codes. That looks trivial. But I don't know if that is all that is needed.

https://github.com/EEC-Developers/eec/blob/master/eecmain.e

[SamuraiCrow]

http://eab.abime.net/showthread.php?t=100514 was one of the places I asked about the startup codes but that was before I knew about the extended HUNK format. I don't think Frank Wille has the PAsm source or not anymore.

[Hypexed]

I've read that. That's funny. It is in fact the PAsm that Frank Wille himself created or "pasm" as he calls it. It surely is out there. I just found it on his site. After asking Google the right question. I had trouble compiling it on OS4 while it compiled fine on Linux.

http://sun.hasenbraten.de/~frank/projects/ http://phoenix.owl.de/pasm.tar.gz

[SamuraiCrow]

Left Phx a note in the EAB thread.

[SamuraiCrow]

Completed with Pull Request #21 and the following commit.