Re: Converting C for KCC on TOPS20
I think the challenge will be does binutils (where nm, objcopy and objdump live) support for the object file format used by TOPS20. I haven’t looked at the TOPS20 object file format but it seems like the best approach would be to have the C compiler generate symbols as it normally would and write a utility to “fixup” the too long symbols rather than munging the source (which is basically what you’re proposing using the stuff from binutils…just a bit more work. TTFN - Guy > On Dec 11, 2019, at 9:07 AM, Guy N. via cctalk wrote: > > On Wed, 2019-12-11 at 00:25 +, David Griffith via cctalk wrote: >> I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC. >> KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which >> has a limit of six case-insentive characters. [...] Does anyone here have >> any knowledge of existing tools or techniques to do what I'm trying to do? > > Is "objcopy --redefine-syms" any help? Compile the code as-is to > produce object files, use nm or objdump to find all of the global > symbols, generate unique six-character names for them, and then use > objcopy to create new object files with the new names. > > Or have I completely missed the point? I'm not familiar with KCC, does > it produce object modules in a format objcopy doesn't support? > > I know someone who was working on gcc support for the PDP-10, I wonder > if he's still doing that or has given up >
Re: Converting C for KCC on TOPS20
> KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which > has a limit of six case-insentive characters. LINK has support for long (up to 72 character) symbols, and it appears FORTRAN v11 can generate them, but the MACRO assembler may never have gotten support; http://pdp-10.trailing-edge.com/bb-r775d-bm_tops20_ks_upd_4/01/sources/lnknew.mac.html SUBTTL BLOCK TYPE 1002 - LONG SYMBOL ENTRY ; ; ! 1002 ! COUNT ! ; ; ! SYMBOL ! ; ; ! MORE SYMBOL ! ; in lnkpar.mac: ND MAXSYM,^D72 ;[2210] Max number of characters in a symbol ND SYMSIZ, ;[2210] Number of words of storage for long symbols
Re: Converting C for KCC on TOPS20
On Wed, 2019-12-11 at 00:25 +, David Griffith via cctalk wrote: > I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC. > KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which > has a limit of six case-insentive characters. [...] Does anyone here have > any knowledge of existing tools or techniques to do what I'm trying to do? Is "objcopy --redefine-syms" any help? Compile the code as-is to produce object files, use nm or objdump to find all of the global symbols, generate unique six-character names for them, and then use objcopy to create new object files with the new names. Or have I completely missed the point? I'm not familiar with KCC, does it produce object modules in a format objcopy doesn't support? I know someone who was working on gcc support for the PDP-10, I wonder if he's still doing that or has given up
Re: Converting C for KCC on TOPS20
On Tue, Dec 10, 2019 at 5:53 PM Sean Conner via cctalk < cctalk@classiccmp.org> wrote: > It was thus said that the Great David Griffith via cctalk once stated: > > > > I'm trying to convert some C code[1] so it'll compile on TOPS20 with > KCC. > > KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, > which > > has a limit of six case-insentive characters. Adam Thornton wrote a > Perl > > script[2] that successfully does this for Frotz 2.32. The Frotz > codebase > > has evolved past what was done there and so 2.50 no longer works with > > Adam's script. So I've been expanding that script into something of my > > own, which I call "snavig"[3]. It seems to be gradually working more > and > > more, but I fear the problem is starting to rapidly diverge because it > > still doesn't yield compilable code even on Unix. Does anyone here have > > any knowledge of existing tools or techniques to do what I'm trying to > do? > > If you are doing this on Linux, an approach is to compile the code there, > then run 'nm' over the object files, and it will output something like: > > [spc]lucy:~/source/boston/src>nm main.o > 00ef t CgiMethod > U CgiNew > r __PRETTY_FUNCTION__.21 > U __assert_fail > U crashreport_core > U crashreport_with > U gd > U gf_debug > T main > U main_cgi_get > U main_cgi_head > U main_cgi_post > U main_cli > > The last column are identifiers; the second column is the type of > identifier, and the first column is the value. What you want to look for > are types 'T' (externally visible function), 'C' (externally visible > constant data) and 'D' (externally visible data). It is these identifiers > that will need to be six unique characters long. > > Something like: > > [spc]lucy:~/source/boston/src>nm globals.o | grep ' [CDT] ' > 0041 T GlobalsInit > 0004 C c_adtag > 0004 C c_class > 0004 D c_conversion > 0004 C c_days > 0004 C c_tzmin > D c_updatetype > 0004 C c_webdir > 0008 D cf_emailupdate > 0004 C g_L > 0004 C g_blog > 0004 C g_templates > 0020 D gd > 0d09 T set_c_conversion > 0beb T set_c_updatetype > 0dbd T set_c_url > 0cab T set_cf_emailupdate > > (but over all object files). I would then generate unique six character > long identifiers for each of these, and slap the output into a header file > like: > > #define GlobalsInit id0001 > #define c_adtag id0002 > #define c_class id0003 > #define c_conversionid0004 > > and then include this file for every compilation unit. I think that would > be the easiest thing to do. > You'd need to exclude libc symbols, though. In a.out times you could just change the names from old to new and adjust the string table offset to do this :) Warner
Re: Converting C for KCC on TOPS20
It was thus said that the Great David Griffith via cctalk once stated: > > I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC. > KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which > has a limit of six case-insentive characters. Adam Thornton wrote a Perl > script[2] that successfully does this for Frotz 2.32. The Frotz codebase > has evolved past what was done there and so 2.50 no longer works with > Adam's script. So I've been expanding that script into something of my > own, which I call "snavig"[3]. It seems to be gradually working more and > more, but I fear the problem is starting to rapidly diverge because it > still doesn't yield compilable code even on Unix. Does anyone here have > any knowledge of existing tools or techniques to do what I'm trying to do? If you are doing this on Linux, an approach is to compile the code there, then run 'nm' over the object files, and it will output something like: [spc]lucy:~/source/boston/src>nm main.o 00ef t CgiMethod U CgiNew r __PRETTY_FUNCTION__.21 U __assert_fail U crashreport_core U crashreport_with U gd U gf_debug T main U main_cgi_get U main_cgi_head U main_cgi_post U main_cli The last column are identifiers; the second column is the type of identifier, and the first column is the value. What you want to look for are types 'T' (externally visible function), 'C' (externally visible constant data) and 'D' (externally visible data). It is these identifiers that will need to be six unique characters long. Something like: [spc]lucy:~/source/boston/src>nm globals.o | grep ' [CDT] ' 0041 T GlobalsInit 0004 C c_adtag 0004 C c_class 0004 D c_conversion 0004 C c_days 0004 C c_tzmin D c_updatetype 0004 C c_webdir 0008 D cf_emailupdate 0004 C g_L 0004 C g_blog 0004 C g_templates 0020 D gd 0d09 T set_c_conversion 0beb T set_c_updatetype 0dbd T set_c_url 0cab T set_cf_emailupdate (but over all object files). I would then generate unique six character long identifiers for each of these, and slap the output into a header file like: #define GlobalsInit id0001 #define c_adtag id0002 #define c_class id0003 #define c_conversionid0004 and then include this file for every compilation unit. I think that would be the easiest thing to do. -spc
Re: Converting C for KCC on TOPS20
any chance you can post-process the .obj files? Warner On Tue, Dec 10, 2019 at 5:26 PM David Griffith via cctalk < cctalk@classiccmp.org> wrote: > > I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC. > KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which > has a limit of six case-insentive characters. Adam Thornton wrote a Perl > script[2] that successfully does this for Frotz 2.32. The Frotz codebase > has evolved past what was done there and so 2.50 no longer works with > Adam's script. So I've been expanding that script into something of my > own, which I call "snavig"[3]. It seems to be gradually working more and > more, but I fear the problem is starting to rapidly diverge because it > still doesn't yield compilable code even on Unix. Does anyone here have > any knowledge of existing tools or techniques to do what I'm trying to do? > > This is part of a project to get Infocom and other Z-machine games running > once again on PDP10 mainframes, either real or emulated. First up is to > get the bare minimum of a current Z-machine emulator running on TOPS20. > Then we can work on screen-handling, a disk pager[4], and porting to other > PDP10 operating systems. I'm hoping that this will lead to fun exhibits > wherever PDP10s are displayed in museum or faire settings. > > > [1] https://gitlab.com/DavidGriffith/frotz > [2] https://github.com/athornton/gnusto-frotz-tops20 > [3] Change an objects shape. > [4] Infocom's Z-machine emulators paged zcode from disk, but Frotz simply > sucks the whole zcode file into memory. > > > -- > David Griffith > d...@661.org > > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? >
Converting C for KCC on TOPS20
I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC. KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which has a limit of six case-insentive characters. Adam Thornton wrote a Perl script[2] that successfully does this for Frotz 2.32. The Frotz codebase has evolved past what was done there and so 2.50 no longer works with Adam's script. So I've been expanding that script into something of my own, which I call "snavig"[3]. It seems to be gradually working more and more, but I fear the problem is starting to rapidly diverge because it still doesn't yield compilable code even on Unix. Does anyone here have any knowledge of existing tools or techniques to do what I'm trying to do? This is part of a project to get Infocom and other Z-machine games running once again on PDP10 mainframes, either real or emulated. First up is to get the bare minimum of a current Z-machine emulator running on TOPS20. Then we can work on screen-handling, a disk pager[4], and porting to other PDP10 operating systems. I'm hoping that this will lead to fun exhibits wherever PDP10s are displayed in museum or faire settings. [1] https://gitlab.com/DavidGriffith/frotz [2] https://github.com/athornton/gnusto-frotz-tops20 [3] Change an objects shape. [4] Infocom's Z-machine emulators paged zcode from disk, but Frotz simply sucks the whole zcode file into memory. -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
