Pete,
Sorry to hear you are having so much trouble porting poplog
to beos. (By the way, it may be hard for some readers to remember the
context of your messages, so it is worth either expanding the subject
line, as I have done, or adding a reminder at the beginning of each
message.)
> So I embarked first on a simple rebuild from source in Linux -- initially
> without changing anything, and I've tried to follow *exactly* the steps
> in 'sysdoc/rebuilding'. I only want to recompile the stuff in the main
> 'src', so I did 'cd $popsrc', and then:
>
> pgcomp *.[ps]
This uses a script ( $popsys/pgcomp ) that runs the poplog system
compiler corepop using the saved image $popsys/popc.psv.
For each xx.p or xx.s file it creates two files xx.o, which is a normal
binary, and xx.w which is a poplog specific binary used at link time to
create the poplog system dictionary (when pglink creates newpop11) so
that pop11 procedures can be invoked by name and system global variables
can be accessed by their names at run time (e.g. popmemlim).
Languages without an incremental compiler or interpreter don't need
that.
> This works -- I get an appropriate bunch of .o and .w files.
> Then I do (after moving the src.?lb files out of the way):
>
> pglibr -c ./ *.w
>
> But this gives a mishap:
>
> ar: $popobjlib/src.olb: No such file or directory
I must change the sysdoc documentation. Sometimes './' works and
sometimes it doesn't. I don't know why. So I now always do things
like:
pglibr -c ../../obj/src.wlb *.w
or after recompiling a few things to be replaced in the archives
pglibr -r ../../obj/src.wlb *.w
Note that this automatically pics up the .o files and adds them to
src.olb
After doing that you should delete the .o and .w files, unless you are
frequently rebuilding a complete system.
But I see from your next message that you discovered (congratulations)
an answer which is equivalent to the above:
> poplibr -c $popobjlib/src.wlb *.w
>
> worked correctly (as did using pglibr instead of poplibr).
>
> Which brings up the question -- what exactly is the reason for
> 'pgcomp', 'pglibr', etc.? What advantage do they give over the
> straight pop operations?
They pcomp (compile sourcefiles) pglibr (archive .o and .w files)
pglink (create files for linking and run the system linker) are
used for three different stages in the process of creating a newpop11
that is a candidate for a *user* basepop11, the run-time executable.
Think of pgcomp as being like cc, pglibr as like ar, and pglink as
loosely analogous to ld.
They are required because poplog system sources cannot be compiled using
other compilers and because unlike programs written in most other
languages the symbol table used at compile time (with names of
procedures, etc.) also needs to be made available (via the .w files) at
run time (where the ordinary 'user' pop11 compiler runs) because user
code can refer to system procedures and global variables.
In principle it might be possible to build a compiler that takes the
system sources and directly produces a running system from them, but (a)
that would be slow to start (though not as slow as it used to be!) and
(b) this would not allow poplog to be ported as its now, by trapping the
output of pgcomp at an earlier stage where it produces only assembler
files for the target system.
Either way you would need a distinction between a compiler that produces
machine code that can be run on the current system and a compiler that
produces something that can be compiled/assembled on another system
to build a new poplog (as you are trying to do on BeOS).
> [I'm afraid it is still true that trying to figure out how all the
> bits fit together, and what should be used where, is a total maze to me.
> I get lost very fast...]
It is an unusually complex system. Sometimes I am surprised that the end
result works so well and is so robust (at least on the unix/linux/vms
systems I have used in the past).
> I find that the file I need to change is actually 'syscomp/sysdefs.p',
> but this does not seem to translate directly into a library module.
> Instead is seems to be loaded by modules like 'make_popc.p'. But
> where do these come into play? What steps do I have to follow to
> get a new sysdefs.p incorporated?
As explained in my recently expanded file
http://www.cs.bham.ac.uk/research/poplog/sysdoc/pop11-executables.txt
the pop11 code in the syscomp subdirectory is used by the scripts
$popsrc/mksyscomp and $popsrc/mknewpop (which all run corepop)
to create the four system saved images in $popsys, namely
popc.psv,
poplibr.psv,
poplink.psv
newpop.psv
So if you need to change the behaviour of the pop11 system compiler
(invoked as pgcomp) you have to change sources in the syscomp directory
then run $popsrc/mksyscomp popc to rebuild popc.psv. You then use the
result to compile system sources by running pgcomp. Similar things
apply to altering pglibr and pglink.
I found pglink particularly difficult to change -- e.g. to output
a bash script rather than a csh script, and to avoid expanding
That was because some of the information came from $popcom files
setting environment variables, some came from the script $popsys/pglink
and some came from the run time system procedure sysfileok which I had
to change so that it sometimes did not expand environment variables.
I hope that in your case it will suffice to change things in syscomp,
then rebuild the system saved images, then recompile everything.
> (My scheme is to get a newpop11 on Linux that initially won't work
> because it will make calls to linkage funtions that don't yet exist.
> Then I'll add those functions as a C module and test it. Then move
> the objects over to BeOS and compare behaviour. I don't, BTW, have
> to worry about screwing up my running pop11 -- all this is happening
> in a separate work hierarchy.)
poplog on unix/linux has always been designed so that instead of
scattering its files all around the system they remain within
a directory tree accessed relative to the environment variable $usepop
This means that you can have a lot of different versions of poplog in
the same machine and switch between them simply by clearing the
environment variables, redefining $usepop, and then sourcing
$usepop/pop/com/poplog(.sh) to set up the other environment variables.
That way it is trivial to have different versions of poplog running in
different xterm windows on the same machine.
If BeOS requires each program to have entries in system tables etc.,
as I understand windows does, then you lose that benefit.
Aaron
|