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 Sun, 24 Oct 2004, Leopold Toetsch wrote:
> We have since quite a time the support for creating native executables
> on some platforms. This functionality is not tested at all. The Makefile
> has just one very simple rule to create a "Hello world"-like program
> with "make testexec".
The Makefi
This doesn't address the deeper problem, but we could also simplify the
whole function by just doing:
static size_t
find_common_mask(size_t val1, size_t val2)
{
size_t mask = ~0;
size_t diff = val1 ^ val2;
while (diff & mask)
mask <<= 1;
return mask;
}
Bit twiddli
This doesn't address the deeper problem, but we could also simplify the
whole function by just doing:
static size_t
find_common_mask(size_t val1, size_t val2)
{
size_t mask = ~0;
size_t diff = val1 ^ val2;
while (diff & mask)
mask <<= 1;
return mask;
}
Bit twiddli
[snipped]
> 1: What does pmc_type return if it fails to find a PMC?
> 2: If that answer is 0, is it safe to document that 0 is a failure return,
>which happens to map to the PMC type for "default", but as they can't be
>instantiated looking up "default" is "not supported" (or words to that
> As a first step, I'm going to move to inlining
> all words (both
> built-in and user defined). Doing this (and
> adding push/pop macros)
> will bring our code bases a lot closer. Once
> this is done I'll make
> another release and we can compare code again.
Cool, since the real meat of it is th
pmc_type is documented and implemented as follows:
/*
=item C
Returns the PMC type for C.
=cut
*/
INTVAL
pmc_type(Parrot_Interp interp, STRING *name)
{
HashBucket *bucket;
PMC *classname_hash = interp->class_hash;
bucket = hash_get_bucket(interp, PMC_struct_val(classname_hash), n
On Sun, 17 Oct 2004 22:07:11 -0500 (CDT), Michel Pelletier
<[EMAIL PROTECTED]> wrote:
> I propose you and I work together to make a
> totally Forth-language agnostic Forth
> micro-kernel. This kernel can be very
> minimalistic, a stacik, a machine state hash,
> and definitions for the words "code"
On Tue, Oct 26, 2004 at 03:21:18PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >The for loop inside trace_mem_block steps right over it. This if fails:
> >
> >/* Do a quick approximate range check by bit-masking */
> >if ((ptr & mask) == prefix || !prefix) {
>
> Argh
On Tue, Oct 26, 2004 at 03:21:18PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >The for loop inside trace_mem_block steps right over it. This if fails:
> >
> >/* Do a quick approximate range check by bit-masking */
> >if ((ptr & mask) == prefix || !prefix) {
>
> Argh
I want to make an loose analogy between pmc/their_content and
Unix inodes/files which I use as a mnemonic.
PMCs are the equivalent of inodes, each one
reference some content which is the equivalent of a file.
C, when the source and the destination pmcs are of the same type,
is like creating a har
I've the new calling scheme now mostly running. I'm down at 11/1969
failing tests[1] currently.
I had to disable t/library/dumper.t, though. It doesn't setup registers
according to pdd03 and just assumes in a few places, that function
arguments will arrive at the caller's end. I think, that's s
Nicholas Clark wrote:
> The for loop inside trace_mem_block steps right over it. This if fails:
>
> /* Do a quick approximate range check by bit-masking */
> if ((ptr & mask) == prefix || !prefix) {
Argh, yes. I have pointed out quite a time ago that this mask check
isn't ok. Sm
H.Merijn Brand wrote:
If I've more from the trucker I'll mail you.
FYI I have not yet been contacted
That didn't work out as well as another possibility failed.
Sorry,
leo
Nicholas Clark wrote:
The for loop inside trace_mem_block steps right over it. This if fails:
/* Do a quick approximate range check by bit-masking */
if ((ptr & mask) == prefix || !prefix) {
Argh, yes. I have pointed out quite a time ago that this mask check
isn't ok. Small and big
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. It looks rather mono-specific and is (of course)
running a stack machine.
-R
l
On Tue, Oct 26, 2004 at 10:44:35AM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> > I have evidence that DOD runs can miss noticing local variable pointers to
> > live objects on x86 Linux. This is happening while running ponie, but
> > the problem is during a single
On Tue, Oct 26, 2004 at 10:44:35AM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> > I have evidence that DOD runs can miss noticing local variable pointers to
> > live objects on x86 Linux. This is happening while running ponie, but
> > the problem is during a single
On Tue 28 Sep 2004 11:17, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
> > 1. Work: Heerhugowaard. Industriestraat 11
> > 2. Home: Huizen, Stam 105
>
> I'll pass the info on, thanks.
>
> > Can you trade for some bottles of "Diana" menthol alcohol?
>
> Should still be avail
Bill Coffman <[EMAIL PROTECTED]> wrote:
> Hello All,
> I have been hard at work, trying to grok the reg_alloc.c code, and
> with some success. My code is assigning registers, so that none are
> conflicting (which I double-verify), and I'm getting to the end of
> "make".
Wow.
> 1) In the exist
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> I have evidence that DOD runs can miss noticing local variable pointers to
> live objects on x86 Linux. This is happening while running ponie, but
> the problem is during a single call to string_make. The gdb traces are from
> a copy of the parrot source
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> I have evidence that DOD runs can miss noticing local variable pointers to
> live objects on x86 Linux. This is happening while running ponie, but
> the problem is during a single call to string_make. The gdb traces are from
> a copy of the parrot source
22 matches
Mail list logo
