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
Okay, here's the results of my lame imitation of smoke testing--a script
(highly customized for my machine) called autotest.
Summary-
---
VC7 Normal: BROKEN
VC7 Debugging: BROKEN
Details
At 02:37 PM 9/18/2001 -0700, Damien Neil wrote:
>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
There was a thread on this recently, but I'm not sure what was
resolved. Do we have a standard naming convention for opcodes?
Personally, I'd like to see that we stick with (what I thought was) the
original plan: a nice, simple ruleset that produces long but predictable
names.
- the opc
> "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes:
Dan> Okay, folks, the following platforms are considered core for the
Dan> parrot interpreter. That means we need to run on all of them for any
Dan> release of the interpreter to be considerd OK. They are:
Dan> Linux (x86)
Dan> CygW
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, 18 Sep 2001, Damien Neil wrote:
> Proposed: Parrot should never crash due to malformed bytecode. When
> choosing between execution speed and bytecode safety, safety should
> always win.
I don't see this as a safety issue. There's nothing unsafe about
crashing. It's just not as pretty
On Tue, Sep 18, 2001 at 09:53:23PM +0100, Simon Cozens wrote:
> 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 t
I have added trans.t to t/op/.
It contains tests for all 18 transcendental math functions.
BTW, did we ever decide on a naming scheme for operators...I named all of
the math functions against the grain (although I didn't realize it at the
time)...for example sin_n_n instead of sin_n. Does this n
On Tue, Sep 18, 2001 at 10:40:30PM +0100, Simon Cozens wrote:
> 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? :)
Sort of, while talking about other things. I wanted to drag it ou
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:14:39PM -0700, Damien Neil wrote:
> The attached file contains tests for all Parrot integer ops.
>
>- Damien
THANK YOU!
(Applied)
--
Calm down, it's *only* ones and zeroes.
On Tue, Sep 18, 2001 at 03:55:23PM -0400, Dan Sugalski wrote:
> Anyone care to take a shot at it? Having an extra "overridable" column in
> the opcode_table file (so we know which opcodes are overridable, and thus
> can't be in the switch) would be a good thing while you were at it...
I will do
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
Dan Sugalski:
# 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.
If somebody codes up the alter
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
At 08:58 PM 9/18/2001 +0100, Nicholas Clark wrote:
>On Tue, Sep 18, 2001 at 08:03:53PM +0100, Simon Cozens wrote:
> > On Tue, Sep 18, 2001 at 02:43:07PM -0400, Dan Sugalski wrote:
> > >Linux (x86)
> > >CygWin
> > >Win32
> > >Tru64
> > >OpenVMS (Alpha)
> > >Solaris (Sparc)
>
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:
> If a platform's not here it's not because we don't want to run on it,
> rather it's because we can't guarantee the manpower to make it right. (If
> we can, then new platforms can and will come on board)
I can handle Linux (PowerPC)
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)
Andy Dougherty:
# Now that the *.h files are in their correct home, we don't need
# the -I.. flag. It could even pick up *wrong* versions of the
# header files
# in a neighboring directory.
Thanks, applied.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
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
toolkit installed, however--can someone check that it works there? It
also works on a BSD
Now that the *.h files are in their correct home, we don't need
the -I.. flag. It could even pick up *wrong* versions of the header files
in a neighboring directory.
--- parrot/Configure.pl Mon Sep 17 21:20:43 2001
+++ parrot-andy/Configure.plTue Sep 18 13:36:52 2001
@@ -64,7 +64,7 @@
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 equivalent) to keep the MANIFEST in sync.
--- parrot/MANIFEST Mon S
On Tue, Sep 18, 2001 at 11:10:36AM -0500, Gibbs Tanton - tgibbs wrote:
> You probably don't want to use ld as your linker. You should try cc
> instead.
Then that's a bug in Configure! :)
--
"If that makes any sense to you, you have a big problem."
-- C. Durance, Computer Scien
Ignore this patch as I think I have a better way to fix it.
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED] '
Sent: 9/18/2001 9:44 AM
Subject: [PATCH]pedantic
This patch allows parrot to compile cleanly under the -pedantic flag of
gcc.
It removes the lvalue casts i
You probably don't want to use ld as your linker. You should try cc
instead.
-Original Message-
From: Simon Cozens
To: [EMAIL PROTECTED]
Sent: 9/18/2001 9:46 AM
Subject: Re: bytecode and sizeof(IV)
On Tue, Sep 18, 2001 at 05:52:24PM +0300, Jarkko Hietaniemi wrote:
> Segfault in alpha e
On Tue, Sep 18, 2001 at 05:52:24PM +0300, Jarkko Hietaniemi wrote:
> Segfault in alpha even when IVs and pointers are both 8 bytes since
> the code tries to dereference the pointers (to read IVs) at four byte
> offsets.
Yep, and the latest "pedantic" patch doesn't help. Also, I'm seeing
this, whi
On Tue, Sep 18, 2001 at 10:48:25AM -0400, Andy Dougherty wrote:
> When trying to configure parrot with an IV = 'long long' (64-bit)
> but with int, long, and pointers only 32-bit, I get either
>
> This isn't Parrot bytecode!
>
> (on SPARC) or a segfault (on i686).
Segfault in alpha even wh
When trying to configure parrot with an IV = 'long long' (64-bit)
but with int, long, and pointers only 32-bit, I get either
This isn't Parrot bytecode!
(on SPARC) or a segfault (on i686).
I'd offer a patch, but I'm not sure which end of the process we want to
change.
--
Andy Dougher
This patch allows parrot to compile cleanly under the -pedantic flag of gcc.
It removes the lvalue casts in GRAB_IV and DO_OP. GRAB_IV I had to add a
variable that was an IV** to hold the program code in each function that
used GRAB_IV. With DO_OP I just changed the lvalue cast to an rvalue cast
Are we assuming that sizeof(IV) >= sizeof(char*). If so, we should probably
assert this somewhere in the configure system.
Tanton
On OS X:
% make test_prog
perl make_op_header.pl opcode_table > include/parrot/op.h
cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \
-fno-strict-aliasing -I.. -I./include -g -o test_main.o -c \
test_main.c
cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYP
On Tue 18 Sep 2001 00:54, Ask Bjoern Hansen <[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
piglet$ cat minus.pasm
set N1, -2
print N1
piglet$ ./assemble.pl minus.pasm
Error (1): No opcode set (tried set_n_ic, set_n) in
This should probably work. Unfortunately, this involves more work on
the assembler than I have knowledge of it so far.
Leon
ps test suite for inc coming up o
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
Simon Cozens sent the following bits through the ether:
> My view is that if you screw up writing assembly code, you should be
> thankful that you get the protection of a segfault.
Indeed, but why not warn about it. The JVM does this by checking that
the bytecodes are wellformed during its bytec
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
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 available at
>> http://cvs.perl.org/snapshots/parrot/
>
>Any chance on rsync? I
On Mon, Sep 17, 2001 at 09:40:25PM -0400, Gregor Purdy wrote:
> And I'd really like to know how we can do string comparisons, even
> at the C level (so we can have the comparison ops, of course)...
Go through a vtable, just like for concat. Transcode, then memcmp.
--
"In the face of entropy and
79 matches
Mail list logo
