You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently pForth is compiled to a single assembly file. If that file is split into two parts, primitives.s and highlevel.s, and those two parts are assembled separately, then the resulting object files can be linked to give an image with the following caveats:
_does labels need to be public (this is only needed for _28_CREATE_29__does).
--warn-unresolved-symbols must be passed to ld so that it does not give an error for all the undefined _compilation symbols.
The files must be linked in the right order (bee-ld --warn-unresolved-symbols primitives.o highlevel.o) so that the word list links work. This could presumably be fixed by making those links symbolic (and global).
The initial branch must be in the first file linked; maybe this could be fixed by calling it _start? Or does that not in itself cause the linker to put it first?
POSTPONEd addresses would also need to be symbolic.
Relatedly, it would be nice to use a suitable alignment directive instead of emitting 0x20 bytes for spaces in the header fields.
The text was updated successfully, but these errors were encountered:
Also try separate compilation of applications, e.g. life.fs. Current problems:
Multiple definitions (assembly and linking works with -z muldefs, but don't know yet if it does the right thing).
Linking life.o with primitives.o and highlevel.o does not change the initial branch or dictionary list, so although the Life words are compiled into the image, they are not visible on start-up.
Currently pForth is compiled to a single assembly file. If that file is split into two parts,
primitives.s
andhighlevel.s
, and those two parts are assembled separately, then the resulting object files can be linked to give an image with the following caveats:_does
labels need to be public (this is only needed for_28_CREATE_29__does
).--warn-unresolved-symbols
must be passed told
so that it does not give an error for all the undefined_compilation
symbols.bee-ld --warn-unresolved-symbols primitives.o highlevel.o
) so that the word list links work. This could presumably be fixed by making those links symbolic (and global)._start
? Or does that not in itself cause the linker to put it first?0x20
bytes for spaces in the header fields.The text was updated successfully, but these errors were encountered: