Re: Poplog port to OS X mishap

[Roger Evans]

Hi Philippe,

K_FLAGS is an offset into a key structure. It is defined in 
src/syscomp/symdefs.p, which defines the basic structures for all poplog 
objects, using special syntax (part of pop11 system dialect). The 
relevant snimmet of code is this:

> lconstant macro (
>     GC_KEY_FIELDS = [
>         (word)    K_GC_RELOC;        ;;; for use by non-copying 
> garbage collector
>         full    KEY;
>     >->    int        K_FLAGS;        ;;; flags
>         int        K_GC_TYPE;        ;;; sysint garbage collector type
>         full    K_GET_SIZE;        ;;; procedure to return word offset 
> size of instance
>     ],
The '>->' arrow indicates where a pointer to the structure actually 
points to (all pop structures have two words *before* the zero offset), 
and because K_FLAGS is at the pointer position, its value should be 0, 
ie its the int that the key pointer actually points to.

M_K_COPY is defined in src/syscomp/wordflags.p and is a flag to say 
whether instances of the class can be copied - most normal data classes 
can be, but things like keys, devices, integers etc. cannot.

So it looks like you may have a problem in one of your keys. Can you 
discover what kind of object the system is trying to copy when it mishaps?

Roger

Philippe Roy wrote:

> Hi everyone,
>
> We are going forward but still encounter issues in our port.
> We now have a new trouble. Our
> System is throwing a mishap error in xc.copy function.
> This problem comes out when the comparison is done, as
> you can see, according to the values below the result
> is completly different for linux:
>
> elseunless (new!K_FLAGS ->> _size) _bitst _:M_K_COPY
> then
>  mishap(item, 1, errms)
>
> Observing the value of both variables(On Linux and OS
> X), we saw this:
>
> VARIABLE       LINUX    OS X
> _size                  20033       e0ab8
> M_K_COPY    1               1
>
> Therefore the comparison in Linux fails but not in OS
> X. Because the value 20033 has an 1 in its lowest
> position (like M_K_COPY) but the value e0ab8 ends up
> with a zero.
>
> We have then the following question:
> Where is the "K_FLAGS" attributte in the structure
> "new"  calculated? What is being done on that test (why the mishap)?
>
> Thanks a lot for your help!!!!
>
>
>