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
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
"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
Leopold Toetsch wrote:
> Thank you. Applied, except the bxor change, which breaks a perl6 test
> (t/compiler/1_5.p6).
>
> There is some ongoing discussions how the binary ops in perl6 will
> look like finally, but using '~' as bxor is the current state.
I can live with this. Since imcc is an in
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
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
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
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
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
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
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
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,
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
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
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
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
;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 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
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.
19 matches
Mail list logo
