• Has anyone solved the multiprocessor memory size mystery?

    From Tom Stepleton@21:1/5 to All on Sun Oct 30 19:08:47 2022
    Hi again,

    I'm still working on my project, and having now successfully written occam code for a single Transputer, I'm now ready to branch out to distributing it over a network. Now I find myself facing a familiar problem.

    When writing single-transputer programs, you use a procedure signature like this one:

    PROC Foo (CHAN OF SP fs, ts, []INT free.memory)

    where free.memory is an array representing all of the memory available to the Transputer that isn't already claimed by something else in your program. It's yours to do with as you wish, and it automatically scales itself to the amount of memory your
    Transputer truly has available.

    Unfortunately this convenient feature doesn't seem to be available to multiprocessor programs. (This is probably because the configuration system allows you to declare "logical" processors that occupy the same physical processor, and it's not clear which
    of those would rightfully claim the real processor's free memory.)

    Is anyone aware of a way to give the Occam code running on one Transputer in a network access to leftover free memory? I can understand INMOS's concern about logical processors, but I'm not doing anything fancy: I just want one logical processor per
    physical processor, so giving all of the free memory to just that one processor makes sense.

    A search of this newsgroup for the phrase "free memory", like this one https://groups.google.com/g/comp.sys.transputer/search?q=%22free%20memory%22 turns up a lot of people wondering whether there's a way to do what I need to do. So, if you can't make sense of what I'm asking about here, try this message from 1994:


    Unfortunately none of the people who're asking the same question as me seem to have got any answer. Maybe since those days, though, someone's come up with a technique?

    Thanks for any help,

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike B.@21:1/5 to All on Tue Nov 1 02:27:44 2022

    There is no memory size mystery. Simply read here:


    4.2 occam programs

    The array memory contains the free memory remaining on the transputer evaluation board after the program code has been loaded and the workspace allocated.
    It is calculated by subtracting the area occupied by the program code and data from the value specified in the IBOARDSIZE host environment variable.

    See also 12.4 Memory allocation for single processor and please note: It's different in mixed language programming.

    and it automatically scales itself to the amount of memory your Transputer truly has available.

    Nothing here is automatically. Simply subtracted. IBOARDSIZE is only for the root transputer. If the value is wrong, the program will not check it.

    In 5.2 Configuration model/5.3 Hardware description you find the memsize node attribute. It's for statically checking that all programs/processes can be mapped (icollect).

    To have access to this value at runtime simply use a parameter for your worker process.
    To determine the first free memory for a single worker process you can create a dedicated section with one variable and place it at the end of all other sections. But this is occam compiler version depend.

    For the occam D7205A toolset see page 472 in the document link. #PRAGMA LINKAGE

    If more than one process is mapped it gets more complex and depends on the mapping order. No idea how deterministic the occam collector will do that. Maybe it's even documented.

    Kind regards

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)