Shop OBEX P1 Docs P2 Docs Learn Events
improving CMM performance - Page 4 — Parallax Forums

improving CMM performance

124»

Comments

  • RossHRossH Posts: 5,463
    edited 2012-10-12 03:37
    Heater. wrote: »
    RossH,
    There are "plain old PASM" modules used in the propgcc system especially the loader. They are assembled using BST but that is about to be swapped out for Roy's new open source Spin compiler which already produces identical code to the Prop tool (barring any bugs that will no doubt be fixed if they show up in the future)

    Ok - I didn't know that. That would save some effort when porting the Catalina runtime to GCC.

    Ross.
  • Heater.Heater. Posts: 21,230
    edited 2012-10-12 05:55
    No qualms with using the Catalina run time with GCC. However I feel that ever happens it should be independent of what propgcc is now. Perhaps even a separate project.
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-10-12 06:24
    Yes, it seems like plugins and the use of a rendevous area should be separate from the compiler. These are things normally done by an OS or a simple driver manager. PropGCC allows for reserving space at the high end of memory, which can be used for a driver description table, or whatever the programmer wants to use it for.

    I've done some work on integrating PropGCC programs with the spinix runtime services, but I haven't looked at it for 6 months. Basically, it just requires reserving space at the high end of memory and writing drivers that are compatible with PropGCC's filedriver structure. If the Catalina run time services could be packaged into a self-contained set of routines it should be possible to use it with PropGCC.
  • Heater.Heater. Posts: 21,230
    edited 2012-10-12 07:17
    Dave,
    PropGCC allows for reserving space at the high end of memory

    It does? I seem to have missed something here. Where is this documented?
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-10-12 08:45
    I'll have to dig around to find where it's documented. In spinix I just overwrite the initial stack pointer value in the hub memory image before I start up the cog. The SP starts at $8000 by default, but if you change it to a smaller number the C program won't use any memory beyond that value. I'm pretty sure the $8000 default value can be overwritten by the linker or loader if you explicity specify a new value.
  • jazzedjazzed Posts: 11,803
    edited 2012-10-12 08:59
    http://forums.parallax.com/showthread.php?138471-Making-PropGCC-programs-more-OS-friendly

    It's a simple linker thing, but I don't think it has been officially documented. :(
Sign In or Register to comment.