| Newsgroups |
gmane.comp.lang.smalltalk.strongtalk |
| Message-ID |
<[email protected]> |
Has any of prunedtree's work been merged onto the trunk yet?
--
On May 17, 5:33 am, prunedtree <[email protected]> wrote:
> On May 15, 9:32 pm, talksmall <[email protected]> wrote:
>
>
>
>
>
> > On May 14, 8:14 pm, prunedtree <[email protected]> wrote:
>
> > > Regarding linux portage, I installed debian etch on a VM and started
> > > to work with GCC 4.1
> > > After some fixes (mainly wasting time to please GCC zeal) i got the
> > > whole system (without os.cpp) to compile.
>
> > > All the link errors are related to os.cpp, which shows that the
> > > current design is already very portable (one file contains all the
> > > platform specificity)
>
> > > I'm now writing os_linux.cpp, the implementation of the needed linux-
> > > specific code. Once i get the VM to compile under linux, I'll try to
> > > pass a few benchmarks, but don't expect much because this is a very
> > > unfriendly environnement to me, and i'm loosing way to much time. I'm
> > > expecting linux users to keep the port alive after that.
>
> > > regards,
> > > prunedtree
>
> > I've been lurking on the group for a while, and messing about for a
> > little while with a linux port (Ubuntu Feisty Fawn, gcc 4.1.2, Eclipse
> > CDT).
>
> > I've made some progress with the linux port. I've built a partial
> > os.cpp (which I named gnu_os.cpp ... oh dear, nevermind). I have
> > implemented the thread creation and os init portions and have stubbed
> > out the rest for now, just to get it to link.
>
> > This is enough to resolve all of the os.cpp link dependencies. In
> > addition I had to build a version of binutils with COFF support and
> > rename a number of the symbols in order to link in the binaries.
>
> Does it work ? (well, it's not mandatory anymore anyway)
>
>
>
> > Unfortunately, I've had little luck with the noasm patches that you've
> > posted to the group in the past :-( Any idea when these are to be
> > merged into the mainline?
>
> > I have also had to make quite a few additions to the dependency files
> > in order to resolve all of the include dependencies.
>
> Strange. My current tree compiles against both msvc 6 sp5 & gcc 3.4.4-
> mingw32
>
>
>
> > My changes allow me to start the VM and singlestepping confirms that
> > it's started executing the bytecode (resolving inline cache misses
> > etc.). I soon get a seg fault though which I'm trying to track down.
>
> When i ported to GCC i had to fix several nasty bugs before getting
> everything to run. GCC misses some an empty base class optimisation
> and displaces the primary/secondary caches... this crashes the
> interpreter when they are accessed in assembly. Other bug is related
> to a __GNUC__ flag disabling the special calling convention for
> primitives (but the assembly code doesn't pop the stack, so you need
> pascal convention). Might be other GCC issues i fixed, moreover I did
> a few changes that improve stability (guarding against edx trashing in
> constant propagation of primitives in the compiler for instance)
>
>
>
> > The changes I have made so far are enough to indicate that the OS
> > dependencies leak out a little further than os.cpp. thread ids are
> > referenced as ints (on linux they are pthread_t s - POSIX threads
> > don't you know) Event and Thread are downcasts of Windows HANDLEs and
> > the handles themselves are exposed via get_hinstance etc. I've
> > implemented a wrapper Thread class and an Event wrapping a semaphore
> > protected boolean to take care of some of this and just ignored the
> > handles for now.
>
> Interressing. There is indeed some win32-specific things (the stuff
> related to hinstance, etc...) But it looks like we only need some
> cleanup to achieve a fairly neutral API. This part of the VM is not
> performance-critical, so we can afford encapsulation overhead.
>
> > Done nothing with DLLs or the timing functions.
> > Possible problem there - Linux only seems to have support for per
> > process timing stats. May not be an issue as the current VM is
> > effectively almost single threaded - handing off from one thread to
> > another via transfer_to etc.
>
> > Happy to share my changes so far. Even happier if we can reconcile
> > them with your noasm changes :-)
>
> I'm happy to see someone is up to the task. As you probably noticed,
> i'm not very motivated to do this port, other than helping linux folks
> getting it done. To cooperate it would be much easier if you could
> contact me on IRC. i'm on #squeak (on freenode) and #smalltalk (on
> dalnet) as "prunedtree".
>
> If you can't reach me on IRC, send me a mail.
>
> regards,
> prunedtree
>
>
>
>
>
> > Cheers,
> > talksmall- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---