On Tuesday 26 October 2004 07:55 pm, Leopold Toetsch wrote:
> Robert Spier wrote:
> > Is there anything that can be learned/reused from libjit?
> >
> > http://www.southern-storm.com.au/libjit.html
>
> Thanks for the link. But I think, while the idea is quite nice, it's not
> really useful for us.
On Thursday 09 September 2004 08:32 am, Gregory Keeney wrote:
> I don't think Parrot's probe system can help us here. Autoconf (as
> described above) uses the target architecture compiler's knowledge of
> the target system. We don't have anything equivalent, as we want to
> bootstrap the cross com
;database". You just need to be clever in how you format the query.
Just an FYI. It's possible that Parrot's probe system could use a similar
mechanism for cross-compilation to avoid the need for platform databases.
Cheers,
Rhys Weatherley.
Autoconf victim for 5 years now.
On Wednesday 16 July 2003 09:23 am, Tupshin Harper wrote:
> At one point, Tupshin suggested emulating a 'more
> >traditional stack-oriented processor' and I don't think he was
> > joking...
>
> Indeed, I wasn't, but I wish somebody would at least have the decency to
> tell me how insane this is
Nicholas Clark wrote:
> Floating point fills me with fear.
If it makes you feel better, C# does not require overflow
detection on floating-point operations. FP overflow results
in +/-INF, underflow results in zero, and undefined is NAN.
Only integer overflow detection is required, and then only
Leopold Toetsch wrote:
> > If memory serves me right, Leopold Toetsch wrote:
>
>^^^...
>
> Your mailer should know ;-)
That's his mailer talking. It always does that. :-)
> > Hmm... I guess I can only quote the ECMA spec here ...
> > conv.i1 Convert to int8, pushing int32 on
I've been working on some other stuff lately, so this is the
first opportunity I've had to catch up on Parrot.
I'm interested in the current status of the following within
Parrot:
- object/class support
- fixed-sized integers and/or conversion opcodes
- embedding of binary extension sect
Nicholas Clark wrote:
> I'm not convinced. Compiling the computed goto core with any sort of
> optimisation turns on *really* hurts the machine. I think it's over a
> minute even a 733 MHz PIII, and it happily pages everything else out while
> it's doing it. :-(
Use the "-fno-gcse" option to gcc,
Nicholas Clark wrote:
> I believe that your understanding of the JIT and the GC cores are still
> correct. The problem would be solved if we had some nice way of getting the
> C compiler to generate us nice stub versions of all the non-inline ops
> functions, which we could then place inline. Howe
Dan Sugalski wrote:
> ># Instead, lets just give an entry number. We can have arbitrary data
> ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having
> ># names attached.
> >
> >What happens if two tools (say, a custom debugger and the Perl compiler)
> >both use the same segment num
I was just having a look at the packfile format code, and I
have a suggestion on load-time performance of the code segment.
Currently, you read the file, parse out the various sections,
copy them elsewhere in memory, and byte-swap as necessary.
The overhead of doing this could be quite significant
Steve Fink wrote:
> - Stratospheric rehydrocalibration amplifiers for the .NET people
> (er... or something; I can't remember what they needed)
The ability to embed arbitrary data in a pbc file under a
named section. This data needs to be readable by the program
when it runs, but is ot
Martin D Kealey wrote:
> I was wondering if anyone else followed the discussion in comp.std.c about
> integer types, prior to the adoption of the C99 standard? There was a
> substantial paper put out by Frank Farance, entitled "specification based
> extended integer range" or SBEIR for short; see
Dan Sugalski wrote:
> I think so. I'm going to add in some conversion ops for the shorter
> float forms, and for the partial-sized integers. I'm unsure at the
> moment whether I want to commit to full 64 bit integers in I
> registers. On the one hand it means a lot more can be done at the low
> le
"Bryan C. Warnock" wrote:
> Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe
> for floating point numbers?
The CLI has three floating point types, of which 2 are visible
to C# and a third is used by the engine. These are "float32",
"float64", and "native float". The firs
Brent Dax wrote:
> # I'm a bit confused as to how one creates a user-defined class
> # in Parrot, and makes virtual method calls, accesses fields,
> # and what-not. I can't seem to find a good example (Cola does
> # non-virtual methods only at present).
>
> You don't, at least not yet. Eventual
Leopold Toetsch wrote:
> Have a look at imcc, which is our high level assembler. imcc does
> register allocation and (currently little) optimization. perl6 produces
> IMCC code. imcc can also run the code or write PBC files.
Yes, I saw that. I haven't yet decided whether to generate pasm
or imcc
Hi,
I'm Rhys Weatherley, the author of Portable.NET, which is part
of the DotGNU project. (Put down that flame thrower! I come
in peace. :-) )
DotGNU is currently reaching out to other projects in the OSS/FS
world to see how we can help you and how you might be able to
help us. One o
18 matches
Mail list logo
