Shop OBEX P1 Docs P2 Docs Learn Events
Catalina - ANSI C for the Propeller 1 & 2 - Page 11 — Parallax Forums

Catalina - ANSI C for the Propeller 1 & 2

15678911»

Comments

  • @RossH

    Thank you for the fast reply and solution.
    And thank you for creating Catalina C.

    Charles.

  • RossHRossH Posts: 5,322
    edited 2023-12-10 03:14

    Catalina 6.5.3 has been released here.

    This release contains only a few small enhancements and bug fixes. However, since one of those bugs affected some of the C library functions, a patch release would be unwieldy - doing a full release is simpler.

    Here is the relevant extract from the README.TXT:

    RELEASE 6.5.3
    
    New Functionality
    -----------------
    
    1. The default behaviour of the Catalina Geany "Catalina Command Line" menu
       entry (on the Build menu) is to open the window in the current project
       directory instead of the user's home directory. Affects Windows only 
       (on Linux, Geany already did this).
    
    2. When using fymodem, if no filename is specified to receive, the filename 
       in the initial received packet is used but not the path, which means the 
       received file will always end up in the current directory. This resolves 
       the Windows issue that arose when specifying a file name to send using 
       a path as well as a file name, since Windows paths and Catalyst paths 
       use different path separator characters (i.e. '\' vs '/' respectively).
    
    Other Changes
    -------------
    
    1. The C interrupt library functions _clr_int_X() - (where X = 1,2,3) - did 
       not compile correctly because they used "iretX" instead of "retiX". 
       Affected the Propeller 2 only. Affected both Linux and Windows.
    
    2. Fixed a bug in the dynamically loaded XMM Kernel which meant that SMALL
       mode programs may not have executed correctly if the kernel was loaded
       dynamically. Affected the Propeller 2 only. Affects both Windows and 
       Linux.
    
    3. A spurious "drvl #57" debug instruction was left in the RTC clock plugin.
       Affected the Propeller 2 only. Affected both Windows and Linux.
    
    4. On the Propeller 2, the XMM Kernel now has the floating point comparison 
       function internal to the kernel to improve performance. Affects the 
       Propeller 2 only. Affects both Windows and Linux.
    
    5. On the Propeller 2, the XMM Kernel now uses XMM_ReadLong and XMM_WriteLong
       to read and write longs instead of XMM_ReadMult and XMM_WriteMult to
       improve performance. Affects the Propeller 2 only. Affects both
       Windows and Linux.
    
    6. The Propeller 2 cache API now includes two new page functions for reading 
       and writing pages as longs rather than bytes, provided the buffers are 
       long aligned and the length of the buffers is a multiple of 4. These 
       new functions are called XMM_ReadLongPage and XMM_WriteLongPage. 
       This will potentially improve performance on future Propeller 2 platforms,
       but is already the case on current XMM API implementations (i.e. PSRAM on 
       the P2 EVAL and P2 EDGE boards). Affects the Propeller 2 only. Affects both 
       Windows and Linux.
    
    
  • RossHRossH Posts: 5,322

    Just a tweak, not even worth a patch release.

    Attached are a couple of updated Lua scripts, which add -i options to the Catalyst freq and find commands to make them case insensitive. For example, you can now say:

    find -i print *.bas
    or
    freq -i *.txt

    Native implementations of all the basic Catalyst commands (i.e. ls, rm, mkdir, rmdir, cp, mv, cat etc) will continue to exist because they work on all platforms with or without XMM RAM, and on the Propeller 1 they are much faster than their Lua equivalents, but on the Propeller 2 Lua is fast enough to make it worthwhile exploiting Lua's ability to make it trivially easy to add new functionality. I intend to gradually add enhanced Lua equivalents for all the basic Catalyst commands (for example, a partial Lua equivalent to ls.bin already exists as list.lua). Such commands will also work on a Propeller 1 platform equipped with XMM RAM, but they will be much slower.

    Ross.

  • @RossH

    I just installed 6.5.3 and it looks like it overwrote my patched version of the "clr_intX.s" files with the old version that used "iretX".
    Also, I've run into more errors when trying to use interrupts in other memory models other than NATIVE. I've attached a text file with the command line I entered and the errors generated.
    Please let me know what other information you might need.

    Charles

  • RossHRossH Posts: 5,322

    @currentc said:
    @RossH

    I just installed 6.5.3 and it looks like it overwrote my patched version of the "clr_intX.s" files with the old version that used "iretX".
    Also, I've run into more errors when trying to use interrupts in other memory models other than NATIVE. I've attached a text file with the command line I entered and the errors generated.
    Please let me know what other information you might need.

    Charles

    Odd. My reference installation works fine - it looks like I may have botched the packaging of release 6.5.3.

    I'm out for the next few hours, but will fix it later today.

    Ross.

  • RossHRossH Posts: 5,322

    @currentc said:
    @RossH

    Also, I've run into more errors when trying to use interrupts in other memory models other than NATIVE. I've attached a text file with the command line I entered and the errors generated.
    Charles

    Ok. Had time to do a bit more investigation. Two things to note:

    1. Interrupts are supported by the NATIVE, COMPACT and TINY memory models. But release 6.5.3 does not have the correct files in it for the COMPACT and TINY mode, only NATIVE mode. I can issue a patch release, but would prefer to issue a whole new release to replace 6.5.3.

    2. Interrupts are not supported by the XMM memory models (i.e. SMALL or LARGE). However, I will at least make Catalina issue a compiler error if you attempt to compile interrupt code in an XMM program.

    If you want to use interrupts in conjunction with a program that has to use XMM RAM (e.g. for size reasons) you must compile the interrupt processing components using one of the memory models that supports interrupts (e.g. NATIVE) and then use Catalina's multi-model support to run this in parallel with the XMM components. The XMM and non-XMM components can share plugins and Hub RAM, but will run on different cogs. There is no specific example of doing this with interrupts, but I can easily add one - it will be similar to the multi-threaded examples in the demos\multimodel folder - XMM does not support multi-threading either, so in that example the single-thread program run_dining_philosophers.c is compiled as an XMM program and it then runs the multi-threaded program dining_philosophers.c (compiled in this case as TINY or COMPACT).

    I can get a fix out quickly since I already have the correct files - I just need to package them correctly :( But writing the XMM interrupt demo will take a little longer. Let me know how urgently you need a fix.

    Ross.

  • @RossH said:

    @currentc said:
    @RossH

    Also, I've run into more errors when trying to use interrupts in other memory models other than NATIVE. I've attached a text file with the command line I entered and the errors generated.
    Charles

    Ok. Had time to do a bit more investigation. Two things to note:

    1. Interrupts are supported by the NATIVE, COMPACT and TINY memory models. But release 6.5.3 does not have the correct files in it for the COMPACT and TINY mode, only NATIVE mode. I can issue a patch release, but would prefer to issue a whole new release to replace 6.5.3.

    2. Interrupts are not supported by the XMM memory models (i.e. SMALL or LARGE). However, I will at least make Catalina issue a compiler error if you attempt to compile interrupt code in an XMM program.

    If you want to use interrupts in conjunction with a program that has to use XMM RAM (e.g. for size reasons) you must compile the interrupt processing components using one of the memory models that supports interrupts (e.g. NATIVE) and then use Catalina's multi-model support to run this in parallel with the XMM components. The XMM and non-XMM components can share plugins and Hub RAM, but will run on different cogs. There is no specific example of doing this with interrupts, but I can easily add one - it will be similar to the multi-threaded examples in the demos\multimodel folder - XMM does not support multi-threading either, so in that example the single-thread program run_dining_philosophers.c is compiled as an XMM program and it then runs the multi-threaded program dining_philosophers.c (compiled in this case as TINY or COMPACT).

    I can get a fix out quickly since I already have the correct files - I just need to package them correctly :( But writing the XMM interrupt demo will take a little longer. Let me know how urgently you need a fix.

    Ross.

    I don't currently need interrupts in XMM mode. I've been using NATIVE mode, but while troubleshooting a different problem, I decided to see if I could compile in TINY. When that failed, I tried the other modes to see what worked.

  • RossHRossH Posts: 5,322

    @currentc said:

    I don't currently need interrupts in XMM mode. I've been using NATIVE mode, but while troubleshooting a different problem, I decided to see if I could compile in TINY. When that failed, I tried the other modes to see what worked.

    Thanks. NATIVE mode should be fine. I'll fix TINY and COMPACT mode in the next release.

    Ross.

  • RossHRossH Posts: 5,322
    edited 2023-12-24 06:43

    Catalina 6.5.4 has been released here.

    This is a full release since it includes updated libraries, but it has only a few small enhancements and bug fixes to the Propeller 2 interrupt and multi-model support.

    Here is the relevant extract from the README.TXT:

    RELEASE 6.5.4
    
    New Functionality
    -----------------
    
    1. Catalina now issues an error message if interrupt code is included in a 
       program compiled in XMM (SMALL or LARGE) mode.
    
    2. A new multi-model demo has been added for the Propeller 2 which shows
       how a primary program (which can be an LMM, CMM, NMM or XMM program) 
       can execute a secondary program (which can be an LMM, CMM or NMM program) 
       that uses interrupts. Also, the Makefile has been updated to build the
       XMM demos on Propeller 2 platforms that have XMM RAM.
    
    Other Changes
    -------------
    
    1. The C interrupt library functions _clr_int_X() - (where X = 1,2,3) - did 
       not compile correctly for programs compiled in COMPACT or TINY mode. 
       Affected the Propeller 2 only. Affected both Linux and Windows.
    
    2. The multi-model support for the Propeller 2 had an issue if the primary 
       program was an XMM LARGE program (XMM SMALL programs worked correctly).
       Affected the Propeller 2 only. Affected both Linux and Windows.
    

    Just what everyone wanted for Christmas, I'm sure! :)

    Ross.

  • RossHRossH Posts: 5,322

    Attached is an updated SD card plugin for Catalina release 6.5.4. You probably only need this if you have a Sandisk Extreme uSD card.

    Here are the details:

    This folder contains an updated version of Catalina's SD plugin for the
    Propeller 2 (cogsd.t) released with 6.5.4, which has an issue with some uSD 
    cards, such as Sandisk Extreme. 
    
    It should work with other cards, but note that neither the version of cogsd.t 
    issued with 6.5.4 nor this version work reliably with the only Sandisk Ultra 
    uSD card I have access to, and I am yet to discover why.
    
    You do not need to recompile Catalina to use the new plugin. Just recompile 
    your C programs. 
    
    To just TRY the new plugin, simply unzip it into the same directory as your 
    C program - it will be used in preference to the one found in the Catalina 
    installation.
    
    To permanently replace the one in the Catalina installation, unzip this
    folder into Catalina's target\p2 directory, over the existing one.
    

    I will include this in the next full release.

  • RossHRossH Posts: 5,322
    edited 2024-01-20 07:29

    Catalina 6.5.5 has been released here.

    This is a full release since it includes updated libraries, but it has only a few small enhancements, the new SD card plugin, and a bug fix for the Propeller 2 interrupt support.

    Here is the relevant extract from the README.TXT:

    RELEASE 6.5.5
    
    New Functionality
    -----------------
    
    1. An additional implementation of malloc has been added to the library which 
       always allocates from Hub RAM. It is intended to be used primarily in XMM 
       LARGE programs, where the normal malloc allocates from XMM RAM. In other 
       memory models, including XMM SMALL programs, the normal malloc allocates 
       from Hub RAM anyway, so this new hub version would not provide any benefit. 
    
       The following functions are defined in a new include file (hmalloc.h), 
       which mirror the usual malloc related function definitions (defined in 
       stdlib.h):
    
       void   *hub_calloc(size_t _nmemb, size_t _size);
       void   hub_free(void *_ptr);
       void   *hub_malloc(size_t _size);
       void   *hub_realloc(void *_ptr, size_t _size);
    
       To support the hub malloc functions, there are also new functions hbrk() 
       and _hbrk() which are analogous to the usual sbrk() and _sbrk() functions, 
       but which allocate from Hub RAM instead of XMM RAM.
    
       An example of using the new malloc is provided in "demos\hub_malloc". The
       program provided can be compiled to use either standard malloc or the new
       hub malloc. See the README.TXT file in that folder for more details.
    
       An XMM LARGE program can use both malloc and hub_malloc freely, but other
       programs should use only one or the other. Also, note that some library 
       functions (notably the stdio and posix thread functions) use malloc 
       internally, and so programs other than XMM LARGE programs should not 
       use the hub malloc functions unless the library is first recompiled to 
       ALSO use hub malloc - this can be done by defining the Catalina symbol 
       HUB_MALLOC when compiling the library. This may speed up XMM LARGE 
       programs that make very heavy use of stdio.
    
       Note that using the hub malloc functions reduces the amount of stack space
       (which is always in Hub RAM in every memory mode) available to the program.
    
       For an example of using HUB_MALLOC to compile the library, see the 
       build_all scripts provided in the folder "demos\catalyst\catalina". Using
       this option has been tested, but since it reduces the available Hub RAM 
       for ALL programs it is not enabled by default.
    
       Note that you can use the two types of allocated memory freely without 
       knowing what type of memory it is, but that memory allocated using the 
       normal malloc functions MUST be re-allocated or freed using realloc
       and free, and memory allocated using the hub malloc functions MUST be 
       reallocated or freed using hub_realloc and hub_free. 
    
    2. The Catalyst time utility has been updated to allow the time to be set
       using local time (the previous versions required it to be set using UTC
       time, which can still be done provided the -u or -w flag is specified). 
    
       Note that to set time using local time, both time AND date must always
       be specified, since otherwise the program does not know whether or not
       to adjust the local time for daylight savings. 
    
       The following are acceptable ways to set the date and/or time:
    
       time -u 11:11:12 PM              -- set UTC time only (12 hour) 
       time -w 23:11:12                 -- set UTC time only (24 hour)
       time -u 01/01/2000               -- set UTC date only
       time 01/01/2000 11:11:12 PM      -- set both LOCAL date and time
       time 01/01/2000 23:11:12         -- set both LOCAL date and time
    
    3. A new lua script is included with Catalyst called attrib.lua. This script
       allows the current text attributes (i.e. effects and color) to be specified
       on the Catalyst command line when using a serial HMI option and a terminal 
       emulator. 
    
       The syntax of the command is:
    
       attrib [-d] [ [effect ...] [ color ] [ on ] [ color ]
    
       Here are some examples:
    
       attrib yellow                     -- yellow fg
       attrib on blue                    -- blue bg
       attrib underscore                 -- set underscore effect only
       attrib blink blue                 -- set blink and blue fg
       attrib red on green               -- red fg on green bg
       attrib red green                  -- same as previous
       attrib reverse bright red on green -- green fg on bright red bg
       attrib normal                     -- reset effects and fg and bg colors 
    
       However, note that which text attributes are supported and what they will
       do depends on the terminal emulator in use, and not on this program. For 
       instance, Catalina's external VTxx emulators do not support italic, and 
       they interpret bright as meaning both bright and bold. Catalina's payload 
       internal terminal emulator does not support setting any attributes at all.
    
    4. The Lua scripts find.lua, freq.lua and wild.lua are now in the folder
       demos/catalyst/core, with all the other Lua scripts used by Catalyst.
       The find.lua and freq.lua now both support a -i flag to specify that
       they should be case insensitive. For example:
    
       find -i print *.bas                -- find 'print', 'PRINT', 'Print' etc
       freq -i *.txt                      -- count word frequency ignoring case
    
    5. The Comms program "paste" functionality has been improved (note that this
       change does not affect Catalina itself, only the Comms terminal emulator). 
    
       Previously, it was easy to paste text that would overflow either the 
       program's own paste buffer (which was only 256 characters) or else it
       would overflow the keyboard buffer in the recipient program. Now, the 
       size of the paste buffer is configurable, and after sending every group of 
       characters (default is 15, but this is also configurable), the program waits
       until the recipient stops sending characters back - however, the program 
       assumes that more than just the pasted characters will be sent by the 
       recipient - e.g. in the case of text editors such as "vi" that use DEC 
       escape sequences, the number of echoed characters may be much, much larger
       than the number of character sent, so the program cannot just check that 
       the character itself has been echoed, or wait for a certain number of
       characters - it must wait for some time after each character to see if it 
       has received the last one (if any) before sending more. This time is 
       also configurable. 
    
       To configure the paste functionality, three new command-line options have 
       been added to the Comms program:
    
         /PasteSize=nnn
         /PasteGroup=nnn
         /PasteDelay=nnn
    
       PasteSize is the maximum size of the paste buffer. Default is 2048.
       This represents the largest number of characters that can be pasted in
       each single paste operation.
    
       PasteGroup is the maximum number of characters sent in each group when
       processing the paste operation. The default is 15, to accommodate serial
       HMI options with small keyboard buffers (such as TTY). If the recipient 
       program has an even smaller keyboard buffer, this number can be reduced 
       to as low as 1, in which case the program will wait after each character
       sent.
    
       PasteDelay is the delay in milliseconds to wait to ensure the last 
       character has been received after sending each group. Default is 250. 
       At low baud rates, this number can be increased, but if the PasteGroup 
       size is reduced, it may be able to be reduced.
    
       The default values have been selected to perform well when using the Comms
       program to talk to the Catalyst "vi" text editor on a Propeller 2 at 230400
       baud, using either the TTY or SIMPLE serial HMI options. They may need to 
       be tweaked in other circumstances (e.g. when using a Propeller 1 at 115200
       baud, it may be necessary to both reduce PasteGroup to 8 and increase 
       PasteDelay to 500).
    
    Other Changes
    -------------
    
    1. The Propeller 2 version of the sd card plugin (cogsd.t) did not work with 
       Sandisk SD cards which do not implement CMD1 correctly, such as some newer
       Sandisk Extreme cards. This has been fixed. The version of the SD plugin 
       in this release should work with all SD cards. 
    
       However, note that for Sandisk Ultra cards it is recommended not to boot 
       the Propeller 2 from the SD card itself - instead, boot the Propeller 2 
       from FLASH (e.g. load Catalyst into FLASH and boot it from there). Then the 
       SD card access works reliably even on these SD cards. 
    
       Affect both Windows and Linux. Affects the Propeller 2 only.
    
    2. The _set_int_X() functions (where X = 1, 2 or 3) did not take into account
       that EACH COG has independent interrupts, so if the same functions were
       called from multiple cogs they were overwriting the interrupt configuration
       data, so only the last such interrupt would work. This has been fixed by
       allocating enough space to store the interrupt configuration for each cog
       separately.
    
       Affect both Windows and Linux. Affects the Propeller 2 only.
    
    

    Oops - I just noticed my README still says it is ok to use Sandisk Ultra cards on the P2 if you boot from Flash rather than from the SD. This is now known to be not true - Sandisk Ultra cards should be avoided altogether.

    Another documentation Oops - I just noticed the README.TXT in the demos\hub_malloc folder contains the following sentence:

    The first version uses the normal stdlib malloc functions (which for an XMM
    LARGE program will allocate memory from XMM RAM) whereas the second one uses
    the new hub malloc functions (which always allocate memory from XMM RAM).

    What it should say is:

    The first version uses the normal stdlib malloc functions (which for an XMM
    LARGE program will allocate memory from XMM RAM) whereas the second one uses
    the new hub malloc functions (which always allocate memory from HUB RAM).

    The release is ok in both cases, it is just my proof-reading that is faulty :(

  • RossHRossH Posts: 5,322

    Just finished a first round of testing of an alloca() function for Catalina. I have tested it in all the memory models on the P2, but am yet to test it on the P1. This will take a little longer because it requires a small kernel change, and finding even one extra long in the P1 kernel is difficult.

    Note that alloca is not part of the ANSI standard, but it is available in most C compilers, and is described here.

    The last release of Catalina (6.5.5) added a hub-specific version of malloc called hub_malloc, but both of these are large and slow compared to alloca, which is tiny in code size (just a few instructions) and consequently very fast.

    In many cases alloca suits the Propeller better because of the Propeller's unique memory architecture - but the other memory management options will of course remain available.

    The main thing you have to be careful about with alloca is passing around pointers to memory because that memory is local to the stack of the function that allocated it, and such pointers will no longer be valid (i.e. the memory will be re-used) once the function exits.

    You can use alloca in any memory model. In an XMM LARGE program, you can use all the memory options provided in the same program:

    • malloc and free to allocate from XMM RAM. This memory remains valid for the lifetime of the program
    • hub_malloc and hub_free to allocate from Hub RAM. This memory remains valid for the lifetime of the program
    • alloca to allocate from the local function stack (which is always in Hub RAM). A corresponding free function is not required because that happens automatically when the function exits.

    This is not the case in other memory models. In those, you can use alloca, but only ONE of malloc or hub_malloc. This is because in the other memory models they will both try to allocate memory from the same memory range and will conflict (and so there is no reason to do this anyway!).

    Ross.

  • Since, as far as I understand, the hardest part of implementing C's variable-length arrays is that it internally needs something like alloca, and since VLAs are part of the C standard, unlike alloca, would you consider implementing VLAs as well?

  • RossHRossH Posts: 5,322

    @Electrodude said:
    Since, as far as I understand, the hardest part of implementing C's variable-length arrays is that it internally needs something like alloca, and since VLAs are part of the C standard, unlike alloca, would you consider implementing VLAs as well?

    Yes, it is true that they are similar internally. However, Catalina will probably never support VLAs. VLAs were an blunder in the history of C. They were introduced in one C standard (C99 from memory) and then dumped again (i.e. made optional) in a later standard (C11 from memory) mainly because some computer architectures cannot implement them efficiently. I believe C23 changed them yet again to try and address this. I don't actually know what their current state is, but I do know that if you need to write portable C, you stay away from both VLAs and alloca and just stick to malloc/free.

    But I had a particular need to fill for Catalina XMM LARGE programs which was that there was no easy way to specifically allocate Hub RAM directly from C (you had to do it from PASM). An issue with C on unusual architectures like the Propeller is that C doesn't naturally support different types of memory. Various compilers have added various ways of addressing this but they are all non-portable (and some of them are also really ugly!).

    I experimented with two methods of addressing this need - hub_malloc and alloca. They both work but they have different advantages and disadvantages, so I ended up implementing both.

    Using hub_malloc is portable in that you can just redefine the hub_malloc routines to use the malloc ones.

    Using alloca is not portable - but it should work on nearly all C compilers. And it is quite an elegant solution.

  • RossHRossH Posts: 5,322

    The new alloca function is now working on the P1 (all memory models) as well as the P2.

    Here is a simple example program that demonstrates alloca():

    /******************************************************************************
     *     A simple program to test the new 'alloca()' built-in function.         *
     *                                                                            *
     * Works in all memory models, on the P1 and P2. Compile this program with a  *
     * command like:                                                              *
     *                                                                            *
     *  catalina test_alloca.c -lc                                                *
     *  catalina test_alloca.c -lci -C COMPACT                                    *
     *  catalina test_alloca.c -lcix -p2                                          *
     *  catalina test_alloca.c -lcx -p2 -C P2_EDGE -C LARGE                       *
     *  (etc)                                                                     *
     *                                                                            *
     ******************************************************************************/
    
    #include <stdio.h>
    #include <alloca.h>
    
    // this handy macro returns the current frame pointer in any memory model
    // on the P1 or P2 ...
    #define FP PASM("#ifdef COMPACT\n word I16B_PASM\n#endif\n alignl\n mov r0, FP\n")
    
    // this handy macro returns the current stack pointer in any memory model
    // on the P1 or P2 ...
    #define SP PASM("#ifdef COMPACT\n word I16B_PASM\n#endif\n alignl\n mov r0, SP\n")
    
    // this function just uses alloca() twice, and then returns.
    void do_alloca(int n) {
      void *x;
      void *y;
    
      printf("in function do_alloc... \n");
      printf("FP is %08X\n", FP);
      printf("SP is %08X\n", SP);
      printf("allocating %d bytes for x\n", n);
      x = alloca(n);
      printf("x is %08X\n", (int)x);
      printf("SP is %08X\n", SP);
      printf("allocating %d bytes for y\n", n);
      y = alloca(n);
      printf("y is %08X\n", (int)y);
      printf("SP is %08X\n", SP);
      printf("... do_alloc done \n");
    }
    
    // the main function calls the do_alloca() function, as well as doing some 
    // allocation of its own before and after.
    void main() {
      void *a;
      void *b;
      int n = 511;
    
      printf("in main ...\n");
      printf("FP is %08X\n", FP);
      printf("SP is %08X\n", SP);
      printf("allocating %d bytes for a\n", n);
      a = alloca(n);
      printf("a is %08X\n", (int)a);
      do_alloca(99);
      printf("in main again ...\n");
      printf("SP is %08X\n", SP);
      printf("allocating %d bytes for b\n", n);
      b = alloca(n);
      printf("b is %08X\n", (int)b);
      printf("SP is %08X\n", SP);
      printf("...main done\n");
      while(1);
    }
    

    And here is the result when that program is compiled for a P1 in LARGE mode:

    in main ...
    FP is 000074B8
    SP is 000074AC
    allocating 511 bytes for a
    a is 000072AC
    in function do_alloc...
    FP is 000072A0
    SP is 00007288
    allocating 99 bytes for x
    x is 00007224
    SP is 00007224
    allocating 99 bytes for y
    y is 000071C0
    SP is 000071C0
    ... do_alloc done
    in main again ...
    SP is 000072AC
    allocating 511 bytes for b
    b is 000070AC
    SP is 000070AC
    ...main done
    

    The main thing to note here is that the memory allocated by alloca is in Hub RAM, even though the program was compiled as an XMM LARGE program, which means the heap (and hence memory allocated by malloc etc) is in XMM RAM and not Hub RAM.

    Catalina now passes all my current test programs, but because implementing alloca required a small kernel change, I need to spend more time adding some new tests to my test suite. But I expect to release in the next few days.

    Ross.

  • RossHRossH Posts: 5,322

    Catalina 7.0 has been released here.

    This is a full release, but it has only one significant enhancement, which is support for the C alloca function.

    Please note that kernel changes in this release means that code compiled with it is not compatible with code compiled by any previous release. Which just means you must recompile from the C sources any object files or libraries you may use. Binary files compiled using prior releases are fine.

    Here is the relevant extract from the README.TXT:

    RELEASE 7.0
    
    New Functionality
    -----------------
    
    1. Catalina now supports the alloca() function. This function is supported
       in all memory models, and on both the Propeller 1 and Propeller 2. Note
       that alloca is not part of the ANSI C standard, but it is commonly
       available in C compilers.
    
       For an overview of alloca, see https://linux.die.net/man/3/alloca
    
       The main advantage of alloca is that it is a very efficient alternative 
       to malloc. It is particularly suited to C on the Propeller, where the heap 
       and stack can use different types of RAM. The C language does not cater 
       very well for architectures that can have different types of RAM. 
    
       Note that there are limitations of using alloca, which are described
       in the link above - the main one is that (unlike memory allocated via
       malloc) memory allocated via alloca must not be referenced once the 
       function in which it was allocated returns to its caller. However, it
       is worth remembering that such memory allocated in the C main function 
       will remain valid for the duration of the program. But this also 
       illustrates another limitation of alloca - which is that there is no way 
       to DE-allocate such memory once allocated other than by exiting the 
       function in which it is allocated.
    
       To see a situation in which alloca is particularly useful on the Propeller, 
       consider an XMM LARGE program. In these programs the stack is in Hub RAM, 
       but the heap is in XMM RAM, and the malloc functions always operate only
       on the heap. Prior to having alloca available, there was no simple way of 
       allocating an arbitrary amount of Hub RAM. While Catalina release 6.5.5 
       added hub_malloc functions specifically to do this, these functions (like
       malloc) are large in code size and also very slow when compared to alloca.
    
       For an example of using alloca, see the demos\alloca folder.
    
       NOTE: the reason for releasing this version of Catalina as 7.0, rather
       than 6.x is that implementing alloca efficiently required a minor kernel 
       change, which means that code compiled with Catalina 7.x MUST NOT BE 
       COMBINED with code compiled by Catalina 6.x or earlier. For instance, 
       object files or libraries compiled with Catalina 6.x must be recompiled 
       before using them with Catalina 7.x.
    
    Other Changes
    -------------
    
    1. The Posix threads functions were returning the correct error values, but 
       not setting the system errno variable, so programs that used errno rather
       than the function return value, or used the perror function to print the 
       error, may not have detected or printed the error correctly. Affects both 
       Windows and Linux. Affects the Propeller 1 and Propeller 2.
    
    2. The hub_malloc functions introduced in Catalina 6.5.5 did not work on the
       Propeller 1. In this release they also now work on the Propeller 1 for
       programs compiled in XMM LARGE mode (which is the only mode in which they
       offer any benefit over the normal malloc functions). Affects both Windows 
       and Linux. Affect the Propeller 1 only.
    
    3. Minor updates to the Catalyst build scripts to prevent building Catalyst
       programs that are not supported on the Propeller 1, such as the real-time
       clock programs. Affects both Windows and Linux. Affects the Propeller 1 
       only.
    
    4. Various changes in this release have had minor impacts on the code size, 
       execution speed and stack requirements for C code. For example, the default
       stack size allocated to a posix thread has been increased from 100 longs 
       to 120 longs, and the default stack size used by the spinc utility has been 
       increased from 80 bytes (20 longs) to 100 bytes (25 longs). If the stack 
       size is manually specified it may need to be increased slightly in a 
       similar manner. This is true for stack space allocated to any C code 
       executed using Catalina's multi-processing support (i.e. multi-threading, 
       multi-cog or multi-model support). If a program that uses multi-processing 
       worked under a previous release of Catalina but does not work correctly 
       in this release, try a small increase in the size of any stacks manually 
       allocated. Affects both Windows and Linux. Affects the Propeller 1 and 
       Propeller 2.
    
    

    Apologies for this release taking longer than anticipated. Catalina is now so complex and has so much unique functionality packed in that I had underestimated the time required to make even a small kernel change. Testing all the combinations of all the functionality - something I had not had to do for a long time because the kernels had been very stable - can take days. And then double that because almost everything has to be tested on both the Propeller 1 and the Propeller 2. The annoying part was that I really didn't need to change the kernels - it just made the code slightly more efficient to do it that way. I certainly won't be making that mistake again anytime soon! :)

    Ross.

  • RossHRossH Posts: 5,322

    The file README_P2.TXT in the Catalina distribution contains some spurious characters where double quotes should have appeared. See the attached file for a corrected version.

Sign In or Register to comment.