[Vm-dev] SqueakCogSpur32x86.xcworkspace

[Ben Coman]

On Mon, Sep 28, 2015 at 3:25 AM, John McIntosh
<johnmci at smalltalkconsulting.com> wrote:
>
> Yes, I have to go back and re-introduce something that lets us build a non-arc version for 32bit, and a arc aware version for os-x 64bit, an iOS 32/64bit

This is the first I heard of ARC, so I've read a bit and now I'm just
curious about a few things mentioned at [1].

Will you have one vm "platform" with #ifdefs for different ARC &
non-ARC code paths, or is it better to treat ARC and non-ARC code as
two separate platforms?  It seems part of the arc advantage of concise
code is negated by additional #ifdefs.  This is maybe suggested by [1]
(but I don't know if "separate xcodeproj" implies a "separate
platform" for us)

ARC seems ObjC based? Is the os-x vm code written in ObjC rather than C?

Does the vm code use Core Foundation much?  [1] implies there are
added complications.

Does the vm code do math on pointers?  [1] implies there are added
complications.

With the ARC-vm code doing reference counted garbage collection, does
this encompass the memory the vm allocates to objects inside the
Image?  Can we forgo our traditional scanning garbage collection?  Or
do you opt out of ARC for the code that hands memory to the Image so
there are not two layers of garbage collection?

Someone's comment [1] from 2012 "There is one serious downside that
wasn't mentioned: cross-compatibility. For us brave and foolish souls
that face the wastelands known as cross-platform programming, ARC
simply isn't an option, at least not until GNU expand upon their ObjC
runtime and compiler features again (they say more is on the way)."
Is this now covered in gcc?  Or is different complier used?


[1] http://stackoverflow.com/questions/8760431/to-arc-or-not-to-arc-what-are-the-pros-and-cons

cheers -ben


>
> On Sun, Sep 27, 2015 at 1:19 AM, Colin Putney <colin at wiresong.com> wrote:
>>
>>
>>
>>
>> On Sun, Sep 27, 2015 at 1:02 AM, <johnmci at smalltalkconsulting.com> wrote:
>>>
>>>
>>> 99.5% is the code I wrote a number of years back. Earlier this year I took the Pharo code, code from minor squeak updates and code from Pyonkee to consolidate and convert into an ARC aware base.  This makes iOS and 64bit OS X base happy, the legacy  32bit obj-c kernel not so much.
>>>
>>> Now I have to backport the code to a format that works in both environments.
>>
>>
>> IIUC, that means the Pharo VM is *not* ARC-aware, which is why it doesn't leak memory. What you've posted now is a step forward from all that, but not yet complete. Is that right?
>>
>> -Colin
>>
>
>
>
> --
> ===========================================================================
> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
> ===========================================================================
>