Jump to content
IGNORED

Wanted: C compiler for TI


Harry Potter

Recommended Posts

There are exactly three options, as we have already indicated:

 

1. Clint Pulley's Small c Compiler--runs on a TI-99/4A, a Geneve 9640, and emulators.

2. Al Beard's C Compiler--runs on a Geneve 9640, an Amiga, and emulators. It has more than Clint Pulley's compiler, but it is not a full C compiler.

3. Dave Pitts' GCC Compiler--runs on Windows or Linux.

 

There are no other existing options.

  • Like 4
Link to comment
Share on other sites

You can pick up a copy of "Compilers: Principles, Techniques, and Tools" from Amazon, or Thriftbooks and fill the gap.

 

Or you can do some creative tooling like I've done in ForceCommand... recognize that 'C' doesn't imply cross platform unless a lot of architecture commonality already exists or is encapsulated in libraries for you. The 9900 and 6502 are so different, they drive significant architectural differences in the the hardware platform.

 

But the OP doesn't get #PRAGMA OVERLAY for free on the 4A. 

 

I have to hop around languages professionally, such that I don't value code re-use as much as system knowledge. A quick click on the OP and you can see the motive. Assuming the OP is an expert in the domain he wants to port the valuable knowledge should be there already. They will have to re-architect it for the 4A, "no if and or buts about it" (is that the expression?). This could be taken as an opportunity to learn one of the Forths that support paging code if there really is that much code that you need overlays and don't want to write an overlay system... I think it was TurboForth that had a feature to just define words in banked SAMS ram. So you can declare the 'overlay' bank before defining the word(s) and then it will all 'link' at runtime. An underutilized feature.

 

Or the somewhat traditional approach of using XB to manage flipping between multiple programs. This would expose the OP to some of our great 4A culture.

  • Like 6
Link to comment
Share on other sites

11 hours ago, jedimatt42 said:

You can pick up a copy of "Compilers: Principles, Techniques, and Tools" from Amazon, or Thriftbooks and fill the gap.

 

Or you can do some creative tooling like I've done in ForceCommand... recognize that 'C' doesn't imply cross platform unless a lot of architecture commonality already exists or is encapsulated in libraries for you. The 9900 and 6502 are so different, they drive significant architectural differences in the the hardware platform.

 

But the OP doesn't get #PRAGMA OVERLAY for free on the 4A. 

 

I have to hop around languages professionally, such that I don't value code re-use as much as system knowledge. A quick click on the OP and you can see the motive. Assuming the OP is an expert in the domain he wants to port the valuable knowledge should be there already. They will have to re-architect it for the 4A, "no if and or buts about it" (is that the expression?). This could be taken as an opportunity to learn one of the Forths that support paging code if there really is that much code that you need overlays and don't want to write an overlay system... I think it was TurboForth that had a feature to just define words in banked SAMS ram. So you can declare the 'overlay' bank before defining the word(s) and then it will all 'link' at runtime. An underutilized feature.

 

Or the somewhat traditional approach of using XB to manage flipping between multiple programs. This would expose the OP to some of our great 4A culture.

No "ifs, ands or buts" is the common expression I believe.

 

It's an interesting problem to think about.  If was going about it, assuming no SAMS card I think I would want the actual function written in Assembler rather than 'C'.  It's pretty straight-forward to read in a program file with the existing system calls. The parts I don't know specifics about are how to give the code a C interface.   I have interfaced Forth to C libraries in the DOS world. (Had to parse a .MAP file) and it was tricky but doable. Pascal was a closer fit believe or not , because the argument order was reversed for C but not Pascal. 

 

But in Assembler it's simpler.  You just need the registers allocations for the compiler, (or just change workspaces for fread() might be better?)

and use the C stack to push parameters and the normal C calling convention means you have to clean up after you are done as well , if I remember correctly.

 

Tursi wrote some comments about this which I can't find just now and there are some discussions in the topic below as well. Makes me wonder how hard would it be... :) 

 

Link to comment
Share on other sites

For bank switching, I cast the trampoline to the function signature of my target, then call it letting the compiler setup all the parameter passing. 

 

My trampoline stuffs the current bank onto the stack, switches to the target bank, and 'BL's to the address of the original target function. The trampoline routine is written in assembly. My trampoline doesn't have to use its own workspace cause I can abuse a few registers gcc does not use much. When the target returns, the trampoline pops the old bank off the stack, banks it in, and pops the old return address as well, and returns to it. 

 

I would imagine implementing overlays as a trampoline using its own workspace since disk access will be 'involving'.  But instead of fiddling with bank switching registers in SAMS or a cartridge, you load/restore the target overlay instead. 

 

At least that is how I would approach it.

 

If you are only calling overlay code from control flow code in a stable control program, it can be heavily simplified. Just use a macro to load the overlay before calling the overlay entrypoint. 

 

With gcc you can link all this together, then use objcopy tool to extract the overlays to their own files. And then use tools like xdm99 to coerce them into TIFILES.

 

There is gasm, and inline assembly, so you have opportunity for letting the linker resolve symbols between assembly module refs and defs and c references and symbols.

 

Discipline is required though. In my systems, nothing stops you from making a naked call to the target function, and if isn't paged in, you get to spend time feeling like an idiot after you've found the problem in an emulator debugger. ( another reason you gotta learn assembly, at least at the 'reader' level )

  • Like 3
Link to comment
Share on other sites

See also this post with a complete installation tuturial by Jedimatt42:

I succeeded in created a working environment with it under Windows Subsystem for Linux.

 

(and funny we meet again but not on the Lemon64 forum ?)

Edited by xahmol
  • Like 4
Link to comment
Share on other sites

  • 3 weeks later...
On 3/20/2021 at 12:03 AM, Tursi said:

No C compiler targeting the TMS9900 supports overlays today. Nobody is really writing any software that requires it, so nobody has been motivated to develop the support.

 

True, but there is something close. The C compiler used for Mini-Cortex Unix (which is both a cross and native compiler) almost has support for that. The source is here:
https://www.jslite.net/cgi-bin/9995/dir?ci=tip
(ccom, cc and c2 directories). It is K&R C though, so if you want to compile recent C code you need to do some tweaking.

This C compiler is derived from the original C compiler as developed by Dennis Ritchie for the PDP-11 mini. As many people on this list will be aware, the instruction set of the PDP-11 and the 9900 are quite close. In the late 70's, this compiler was modified to generate overlays for programs that could not fit in 16 bits (this work was originally done at Berkeley for 2.10BSD).

 

The overlay system is quite clever and does not require modification to the C source: all the work is done by the linker. In essence, functions that call across overlays do so via a small (automatically generated) thunk that adjusts the memory mapping as needed. The process is described here (nroff document):
https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/doc/2.10/ovpap

 

The Mini-Cortex compiler has the code in it to support this feature; however I've never written the bits of support code that it needs. Hence, it *almost* supports this.

 

  • Like 3
Link to comment
Share on other sites

On 3/19/2021 at 9:51 PM, Ksarul said:

There are exactly three options, as we have already indicated:

 

1. Clint Pulley's Small c Compiler--runs on a TI-99/4A, a Geneve 9640, and emulators.

2. Al Beard's C Compiler--runs on a Geneve 9640, an Amiga, and emulators. It has more than Clint Pulley's compiler, but it is not a full C compiler.

3. Dave Pitts' GCC Compiler--runs on Windows or Linux.

 

I seem to recall that Al Beard's C compiler also supports overlays (on the Geneve). Al is still around, maybe he can clarify.

 

EDIT:

 

I looked up the source. The manual says this about TIC:

"The GENEVE MDOS version of the compiler utilizes sophisticated
  memory swapping to gain an 85k workspace for the compiler, even
  though the compiler is over 50k in length.  This allows compilation
  of fairly sophisticated C programs.  The total memory required to

  run the TIC compiler is 144k."

However, this appears to be achieved via custom memory management in the compiler source code (grep for "swap" in the source code), where specific compiler tables are swapped in and out of the actual memory space. So, in the general sense the TIC compiler does not support overlays.

Sorry for the red herring.

Edited by pnr
elaboration
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...