Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Eric Van Hensbergen <ericvh@gmail.com>]

I was sleep-deprived much of the week, so my memory is most likely not
exact (so hopefully Russ will provide a clarification), but I believe
he said something along the lines of pointing to the top of the stack
as a workaround.  I haven't had a chance to look at it yet, so that's
about as much of a hint as I can give at the moment.

     -eric

On Tue, Jun 29, 2010 at 1:12 PM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> Anyone (Russ?) can repeat here aprox. what the workaround for b was, for
> those like me that didn't attend usenix?
>
> On Tue, Jun 29, 2010 at 8:10 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>>
>>> Is the porting process active?
>>>
>>
>> It seems to be an opportunistic concurrent activity (which is why I
>> tried to create a central repo so we'd get some benefit from the
>> sparse multiple activities).  Most people were just waiting for Andrey
>> :)
>>
>> There is some stuff that Forysth/Jmk have been looking at to allow for
>> the segment registers, but Russ had suggested workaround at USENIX
>> that I don't think anyone has had time to try yet.
>>
>> So here's what my take on what needs to be done:
>>
>> a) Simple logistics (makefile/script transformations, Sape's branch
>> has some of this, what the right way to do this in order to be
>> integrated back into the mainline go tree is an open question)
>> b) support or workaround for the segment register stuff
>> c) runtime support
>>
>> People seem to be mostly getting hung up on (a), (b) is probably the
>> trickiest bit, and I think (c) is just a matter of sitting down and
>> getting it done.
>>
>> I wonder if one way of avoiding (a) is just to rig to cross-compile
>> from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work
>> back to (a), just because it seems like it would be more satisfying.
>>
>>    -eric
>>
>>
>
>