#374 M68K/BCPL: getvec issues

Shell/DOS (109)
Mark K

I compared the AROS getvec implementation with that in AmigaDOS. Some things I noticed:
- If getvec is called with A2 non-zero, then on failure pr_Result2 should be set to ERROR_NO_FREE_STORE (and the function returns 0). AROS getvec doesn't do that.
- Why add 4 longwords (i.e. 16 bytes) to the requested allocation length? That could be quite wasteful of memory if a program does many small allocations.
- AROS allocates using MEMF_PUBLIC|MEMF_CLEAR. However clearing the memory is unecessary; AmigaDOS getvec uses MEMF_PUBLIC.


  • Mark K

    Mark K - 2012-02-25

    The same applies to allocMem. allocMem and getvec are virtually identical. In AmigaDOS, the only difference is that getvec allocates with MEMF_PUBLIC whereas allocMem allocates with the user's requirements (passed in D2).

    To save some ROM space you could do this in bcpl.S:
    getvec: moveq.l #MEMF_PUBLIC,d2
    allocMem: [current allocMem code]

  • Mark K

    Mark K - 2012-02-27

    I looked at the Kickstart 1.3 getvec code. It allocates D1+1 longwords. So the AROS getvec needs to do that too. It's unnecessarily allocating an extra 3 longwords at the moment.

    Note: the "allocate argument plus 1 longwords" behaviour is very similar to how clearvec (GV offset -$50, called clearmem in the AROS source) clears argument+1 longwords. Cf bug 3494752.

  • Mark K

    Mark K - 2012-02-28

    Some more information/clarification...

    - getvec is supposed to take a memory type argument in D2. The AROS version forces MEMF_PUBLIC|MEMF_CLEAR. If a program wants to allocate chip RAM and thus passes MEMF_CHIP in D2, that's ignored by AROS, which will allocate fast RAM instead.

    - I have confirmed that both getvec and clearvec in Kickstart 3.1 allocate (or clear in the case of clearvec) "argument+1" longwords.

    That is borne out by the BCPL language spec; see http://www.srcf.ucam.org/cucps/document/bcplstd.txt
    Quoting from that: "LET N = VEC K declares a variable N which points to a vector of K+1 cells where K is a constant expression. At run time K+1 contiguous cells numbered from 0 to K are allocated dynamically..."

    So the "argument+1" behaviour of getvec & clearvec naturally fits with the BCPL vector declaration.

  • Mark K

    Mark K - 2012-02-28

    Whoops, sorry. The first paragraph of my last comment is incorrect; getvec always uses MEMF_PUBLIC. It's allocMem (GV offset $4C) that takes a memory type argument, which AROS does use.

  • Mark K

    Mark K - 2012-02-28

    Here's a snippet of code from the Workbench 1.3 Dir command, showing the "allocate argument + 1 longwords" behaviour is expected:

    lbC0007B8 MOVEQ #1,D1 ;Allocate 1+1 = 2 longwords
    MOVEQ #$10,D0
    MOVEA.L ($74,A2),A4 ;getvec
    JSR (A5)
    MOVE.L D1,(4,A1) ;Save BPTR to memory
    [code handling the out-of-memory case omitted]
    MOVE.L (4,A1),D1 ;BPTR to 2 longwords memory
    LSL.L #2,D1
    MOVE.L ($278,A2),(A0,D1.L) ;Store in the 1st longword
    MOVE.L (4,A1),D1
    LSL.L #2,D1
    MOVE.L (A1),(4,A0,D1.L) ;Store in the 2nd longword
    MOVE.L (4,A1),($278,A2)
    JMP (A6)

  • Toni Wilen

    Toni Wilen - 2012-02-29

    Fixed except pr_Result2 code.

  • Toni Wilen

    Toni Wilen - 2012-02-29
    • assigned_to: nobody --> twilen
    • status: open --> open-fixed
  • Jason S. McMullan

    This should now be fixed (both by Toni Wilen for the extra padding and the flags, and by Jason McMullan for the Result2 error indication)

    If this has been resolved to your satisfaction, please close this issue.

  • Krzysztof Smiechowicz

    • status: open-fixed --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks