Do you know if there happens to be anything weird about the alignment on
this machine?
-Original Message-
From: Josh Wilmes
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED]'
Sent: 9/19/2001 12:34 AM
Subject: Re: Purify machine
solaris 2.7
--Josh
At 0:13 on 09/19/2001 CDT, Gibbs Tant
solaris 2.7
--Josh
At 0:13 on 09/19/2001 CDT, Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> wrote:
> What type of machine is the hourly purify running on. It keeps dieing with
> a SIGBUS on most set_n_nc calls (meaning invalid alignment). This is really
> bad. I would like to know the type of a
What type of machine is the hourly purify running on. It keeps dieing with
a SIGBUS on most set_n_nc calls (meaning invalid alignment). This is really
bad. I would like to know the type of an NV as well as the sizeof NV,
sizeof IV, and sizeof void*.
Thanks!
Tanton
Brent Dax:
# Okay, here's the results of my lame imitation of smoke
# testing--a script
# (highly customized for my machine) called autotest.
Here's the results of a run on FreeBSD. It looks like something is
broken in the integer test. (It's not my script--I get the same errors
when I run `mak
On Tue, Sep 18, 2001 at 06:47:38PM -0700, Hong Zhang wrote:
>
> Do we want the opcode to be so complicated? I thought we are
> going to use this kind of thing for generic pointers. The "p"
> member of opcode does not make any sense to me.
Alignment.
> Hong
>
> > Earlier there was some discussi
Ok...let me try to get this straight and I'll repatch...
opcode_t should be something that will represent the native opcode type. In
most cases it should just be long; however, there might be special systems
where it is somehting different (int, long long, etc...). IV should be a
union with a l
Do we want the opcode to be so complicated? I thought we are
going to use this kind of thing for generic pointers. The "p"
member of opcode does not make any sense to me.
Hong
> Earlier there was some discussion about changing typedef long IV
> to
> typedef union {
> IV i;
> void* p;
> } op
> Proposed: Parrot should never crash due to malformed bytecode. When
> choosing between execution speed and bytecode safety, safety should
> always win. Careful op design and possibly a validation pass before
> execution will hopefully keep the speed penalty to a minimum.
We can use similar mo
On Tue, Sep 18, 2001 at 07:52:06PM -0400, Dan Sugalski wrote:
> More to the point, it needs typing exactly twice--once in the .ops file
> that defines the opcode function body, and once in opcode_table. The
> assembler, of course, uses the smaller name.
Three times: And once to name the test ca
At 04:31 PM 9/18/2001 -0700, Dave Storrs wrote:
> So, yes, you'd get 'mul_i_ic_ic', but who cares? It's not really
>that hard to type, and it is absolutely unambiguous. If you want to make
>the interpreter magically deduce the full opcode name from the prefix,
>that's cool, too.
More to
On Tue, Sep 18, 2001 at 06:12:48PM -0500, Gibbs Tanton - tgibbs wrote:
> All the tests are great! But, could everyone please remember to put an
> "end" at the end of each assembly test...cygwin doesn't like it if you
> don't. I think I've patched all the ones up to this point.
Oops. Sorry abou
All the tests are great! But, could everyone please remember to put an
"end" at the end of each assembly test...cygwin doesn't like it if you
don't. I think I've patched all the ones up to this point.
Thanks!
Tanton
On Tue, Sep 18, 2001 at 03:52:42PM -0700, Damien Neil wrote:
> ...and here are tests for the number ops.
Thanks, applied.
--
A formal parsing algorithm should not always be used.
-- D. Gries
On Wed, Sep 19, 2001 at 12:51:43AM +0200, Mattia Barbon wrote:
> I think that especting 4294967295 == -1 because they have the same
> bit pattern ( on two's complement 32 bit machines ) is wrong
Oh shit, here we go again. Nick Clark, where are you?
--
Thus spake the master programmer:
On Wed, Sep 19, 2001 at 12:51:43AM +0200, Mattia Barbon wrote:
> I think that especting 4294967295 == -1 because they have the same
> bit pattern ( on two's complement 32 bit machines ) is wrong
I was wondering how long it would take for someone to notice that. :>
If anyone feels like defining
...and here are tests for the number ops.
- Damien
#! perl -w
use Parrot::Test tests => 23;
output_is(<
set I2, -2147483648
print I2
print "\\n"
set I3, 4294967295
print I3
print "\\n"
end
CODE
305419896
-1698898191
2147483647
-2147483648
-1
OUTPUT
I think that especting 4294967295 == -1 because they have the same
bit pattern
Russ Allbery:
# Simon Cozens <[EMAIL PROTECTED]> writes:
#
# > Yep, and the latest "pedantic" patch doesn't help. Also, I'm seeing
# > this, which is weird:
#
# > ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o
# interpreter.o parrot.o register.o basic_opcodes.o memory.o
# bytecode.o s
Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes:
> I would vote no. HOWEVER, I would think that the user should have the
> option to turn on checking for malformed bytecode (i.e. Safe mode). In
> the default case, I think the bytecode should be assumed well formed and
> no extra checking be
On Tuesday 18 September 2001 03:55 pm, Dan Sugalski wrote:
> One of the things that the configure script needs to do is generate the
> opcode dispatch macro to either be a giant switch statement (with a
> fallthrough default to handle cases we don't know about) or the function
> table dispatch we
Simon Cozens <[EMAIL PROTECTED]> writes:
> Yep, and the latest "pedantic" patch doesn't help. Also, I'm seeing
> this, which is weird:
> ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o interpreter.o parrot.o
>register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.
Simon Cozens:
# On Tue, Sep 18, 2001 at 02:51:35PM -0700, Brent Dax wrote:
# > So, something more like this?
#
# Urh, how can I put this? No.
#
# I *really* want to avoid macro hackery - undef'ing this and
# then testing if it's defined and then redefining it, and
# urgh, urgh, urgh. No.
#
# I was
On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote:
> Proposed: Parrot should never crash due to malformed bytecode.
Haven't we done this argument? :)
I'd vote no, FWIW.
--
Dames lie about anything - just for practice. -Raymond Chandler
I would vote no. HOWEVER, I would think that the user should have the
option to turn on checking for malformed bytecode (i.e. Safe mode). In the
default case, I think the bytecode should be assumed well formed and no
extra checking be performed.
-Original Message-
From: Damien Neil
To:
On Tue, Sep 18, 2001 at 02:51:35PM -0700, Brent Dax wrote:
> So, something more like this?
Urh, how can I put this? No.
I *really* want to avoid macro hackery - undef'ing this and
then testing if it's defined and then redefining it, and
urgh, urgh, urgh. No.
I was thinking more like:
> +++ bu
Proposed: Parrot should never crash due to malformed bytecode. When
choosing between execution speed and bytecode safety, safety should
always win. Careful op design and possibly a validation pass before
execution will hopefully keep the speed penalty to a minimum.
Yes, no?
Simon Cozens:
# On Tue, Sep 18, 2001 at 02:32:32PM -0700, Brent Dax wrote:
# > If somebody codes up the alternate dispatch, I can easily modify
# > Configure.pl, config_h.in and the hints files to handle it.
# Something
# > like this, perhaps:
#
# Something like that, but the Right Way would be t
On Tue, Sep 18, 2001 at 01:38:58PM -0400, Andy Dougherty wrote:
> The following patch adds some missing files to MANIFEST. It also re-sorts
> it for easier maintenance. It's probably a good idea to periodically run
>
> perl -MExtUtils::Manifest -e 'ExtUtils::Manifest::fullcheck'
>
> (or
On Tue, Sep 18, 2001 at 02:32:32PM -0700, Brent Dax wrote:
> If somebody codes up the alternate dispatch, I can easily modify
> Configure.pl, config_h.in and the hints files to handle it. Something
> like this, perhaps:
Something like that, but the Right Way would be to rewrite DO_OP in
interp_g
The attached file contains tests for all Parrot integer ops.
- Damien
#! perl -w
use Parrot::Test tests => 26;
output_is(<
Mattia Barbon:
# This patch contains different things.
# If you prefer three smaller patches,
# just speak, I'll resend.
#
# * Configure.pl
# * 5.004_04 does not have $Config{_o}, $Config{_exe},
# use obj_ext, and exe_ext
# * Use ExtUtils::Manifest for manifest parsing
# ( now you can
Applied.
-Original Message-
From: Simon Cozens
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED]'
Sent: 9/18/2001 3:53 PM
Subject: Re: [PATCH] changing IV to opcode_t!!
On Tue, Sep 18, 2001 at 03:31:11PM -0500, Gibbs Tanton - tgibbs wrote:
> 8. I would love someone to test it on Tru64 and
On Tue, Sep 18, 2001 at 03:31:11PM -0500, Gibbs Tanton - tgibbs wrote:
> 8. I would love someone to test it on Tru64 and Win32.
Testing anything on Tru64 is currently impossible, as Jarkko has pointed
out. I'm still trying to wrap my branes around how to fix that. However,
it compiles. I say app
On Tue, Sep 18, 2001 at 04:15:45PM -0400, Gregor N. Purdy wrote:
> It seems to me that we should have a Parrot::OpcodeTable module that
> is auto-generated rather than having the assembler and disassembler
> read in the opcode_table file itself.
Yes; I can't remember why I thought this was a good
Earlier there was some discussion about changing
typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
This patch does that. I have tested it on cygwin, solaris 5.8, and solaris
8. I would love someone to test it on Tru64 and Win32.
If this is NO LONGER WANTED, just let me know.
> Easy Makefile.in patch. I was worried that Win32 might need the linker
> (the change to $(LD) was submitted as part of a Win32 compatibility
> patch) but that doesn't seem to be the case. I don't have a MinGW
Fine here
Regards
Mattia
All --
It seems to me that we should have a Parrot::OpcodeTable module that
is auto-generated rather than having the assembler and disassembler
read in the opcode_table file itself. We can install OpcodeTable.pm
just like any other module when folks install the assembler and
disassembler.
We sti
This patch contains different things.
If you prefer three smaller patches,
just speak, I'll resend.
* Configure.pl
* 5.004_04 does not have $Config{_o}, $Config{_exe},
use obj_ext, and exe_ext
* Use ExtUtils::Manifest for manifest parsing
( now you can put blank lines/comments/
All --
I reworked the disassembler to use the PackFile::* classes, and made
some fixes to the classes themselves. Still to come:
* Refactor most of the disassembler code into the PackFile classes
themselves.
* Rework the disassembler to generate labels for branch targets.
* Make the
One of the things that the configure script needs to do is generate the
opcode dispatch macro to either be a giant switch statement (with a
fallthrough default to handle cases we don't know about) or the function
table dispatch we have now.
Anyone care to take a shot at it? Having an extra "ov
At 07:55 PM 9/18/2001 +0100, Philip Kendall wrote:
>On Tue, Sep 18, 2001 at 02:43:07PM -0400, Dan Sugalski wrote:
> > Okay, folks, the following platforms are considered core for the parrot
> > interpreter. That means we need to run on all of them for any release of
> > the interpreter to be consi
On Tue, Sep 18, 2001 at 02:43:07PM -0400, Dan Sugalski wrote:
>Linux (x86)
>CygWin
>Win32
>Tru64
>OpenVMS (Alpha)
>Solaris (Sparc)
>FreeBSD (x86)
To clarify: we're *not* saying "these are the only platforms we care
about". Parrot *will* run on many, many more platforms
On Tue, Sep 18, 2001 at 02:43:07PM -0400, Dan Sugalski wrote:
> Okay, folks, the following platforms are considered core for the parrot
> interpreter. That means we need to run on all of them for any release of
> the interpreter to be considerd OK. They are:
[...]
> Solaris (Sparc)
32 bit
Okay, folks, the following platforms are considered core for the parrot
interpreter. That means we need to run on all of them for any release of
the interpreter to be considerd OK. They are:
Linux (x86)
CygWin
Win32
Tru64
OpenVMS (Alpha)
Solaris (Sparc)
FreeBSD (x86)
Thanks. Applied.
On Tue, 18 Sep 2001, Simon Cozens wrote:
> This enables typecasting between I and N registers, fixes up the
> error messages, and makes "var num" not require an assignment.
>
> I note that some pseudo-ops don't work, and "mod" doesn't work
> as a pseudo op with a constant; nor
On Tue 18 Sep 2001 10:52, Mattia Barbon <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Sep 2001, H.Merijn Brand wrote:
>
> >On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen <[EMAIL PROTECTED]> wrote:
> >>
> >> oops, I forgot to tell anyone. I made CVS export and tar up a
> >> snapshot every 6 hours. It is
This enables typecasting between I and N registers, fixes up the
error messages, and makes "var num" not require an assignment.
I note that some pseudo-ops don't work, and "mod" doesn't work
as a pseudo op with a constant; nor does "pow" and similar functions
work at all. :( Thinking about how to
On Mon, 17 Sep 2001, Gregor Purdy wrote:
Rename it to 'read':
perl 5.5 dos not dvin HAV_SYSMMAN, so the altrnativ ode
it piks th altrnativ code.
Renaming it to read() workd for MSVC5 ( whih defines an alias
from _read to read ), and for older perls on *NIX
don't know for MinGW, though
( In fact
48 matches
Mail list logo
