typed scalars and arrays aren't sufficient for
the purpose at hand)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTE
tor through a register, and you can just patch the register load. (And
most register loads will be from looking routines up by name in the stash/pad)
Dan
--"it's like this"---
Dan Sugalski
At 12:38 AM 9/18/2001 +0300, Jarkko Hietaniemi wrote:
>On Mon, Sep 17, 2001 at 05:29:11PM -0400, Dan Sugalski wrote:
> > Folks,
> >
> > Don't sweat system malloc behaviour all that much at the moment. We are
> > going to be completely taking over memory allocat
threadsafe, too. Ouch.
Luckily we don't have to have the GC be threadsafe as such, if we're
careful. (And we will be)
Been there, pondered that, have an answer. (Though, admitttedly, not
necessarily the *correct* answer...)
Dan
--
At 12:56 AM 9/18/2001 +0300, Jarkko Hietaniemi wrote:
>On Mon, Sep 17, 2001 at 05:54:41PM -0400, Dan Sugalski wrote:
> > At 12:51 AM 9/18/2001 +0300, Jarkko Hietaniemi wrote:
> > > > > Doug Lea's malloc is in the public domain:
> > > > >
>
At 11:04 PM 9/17/2001 +0100, Simon Cozens wrote:
>On Mon, Sep 17, 2001 at 05:52:19PM -0400, Dan Sugalski wrote:
> > >Which is really going to screw up backpatching. :(
> >
> > Maybe. I don't think it's as big a deal as you might think it is, since we
> >
perl 6 they'll probably be two strings and an integer. I expect
we might have some sort of way to force things with methods or something,
but I don't know how that'd look at the language level.
Dan
-----
At 02:50 PM 9/17/2001 -0400, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> At 02:06 PM 9/17/2001 +0100, Dave Mitchell wrote:
>
> >> If we have one generic stack with all sorts of things on it, w
value of X you might have...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
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
> >
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...
Dan
--"it's like this&qu
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
>
---------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
e breakage. Once we have that... :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
it
wouldn't work...)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
re was some discussion about changing typedef long IV
> > to
> > typedef union {
> > IV i;
> > void* p;
> > } opcode_t;
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
though, is another matter. Those will convert or
throw interpreter exceptions, as appropriate.
Dan
----------"it's like this"---
Dan Sugalski
ally. The best I can think of
is to have the dangerous ops validate their parameters and the oploop do
resource checks as appropriate. :(
I may, however, be suffering from a lack of imagination. That'd be OK.
Dan
------
. (I assume NVs are twice the size of ops, but that could be incorrect)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] h
At 03:58 PM 9/19/2001 +0100, Simon Cozens wrote:
>On Wed, Sep 19, 2001 at 10:59:45AM -0400, Dan Sugalski wrote:
> > Nope. opcode_t should be the native opcode type for the platform we're
> > compiling on. No need for fancy unions--configure should find out the
> > i
At 04:49 PM 9/19/2001 +0100, Robin Houston wrote:
>Dan Sugalski wrote:
> > I'd love to have Darwin there, [...]
> >
> > If someone is willing to pitch in the time and effort, I'd be thrilled
> > to add it to the list.
>
>I'm willing.
Keen. I don
#x27;t the
place to go into that, I think. :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
-native but still
known set of bytecode.
>-Original Message-----
>From: Dan Sugalski
>To: Simon Cozens; ''[EMAIL PROTECTED]' '
>Sent: 9/19/2001 10:14 AM
>Subject: Re: [PATCH] changing IV to opcode_t!!
>
>At 03:58 PM 9/19/2001 +0100, Simon Cozens wro
At 05:27 PM 9/19/2001 +0100, Simon Cozens wrote:
>On Wed, Sep 19, 2001 at 12:25:32PM -0400, Dan Sugalski wrote:
> > Cool. If I get a chance (or someone else does) I'll see about hacking the
> > byteloader to translate to native format if handed a non-native but still
>
, and density's
generally a good thing.
I'll update the core parrot stuff and the tests, but I'm leaving the rest
alone for the moment.
Dan
--"it's like this"---
Dan Sugalski
At 01:37 PM 9/19/2001 -0400, Andy Dougherty wrote:
>On Wed, 19 Sep 2001, Dan Sugalski wrote:
>
> > At 05:27 PM 9/19/2001 +0100, Simon Cozens wrote:
>
> > >I think it's more urgent that we think about having the bytecode
> written in
> > >native IVs rather
At 02:51 PM 9/19/2001 -0400, Andy Dougherty wrote:
>On Wed, 19 Sep 2001, Dan Sugalski wrote:
>
> > At 01:37 PM 9/19/2001 -0400, Andy Dougherty wrote:
>
> > >Of course it doesn't help that perl doesn't have a pack() flag for IV :-).
> >
> > Definitely
The assembler's failing with 0a->0D0A conversions in spots. Could someone
familiar with it go binmode all the output files that we spit bytecode to?
Dan
--"it's like this"-
At 05:28 PM 9/19/2001 -0400, Dan Sugalski wrote:
>The assembler's failing with 0a->0D0A conversions in spots. Could someone
>familiar with it go binmode all the output files that we spit bytecode to?
Never mind, I took care of it.
tered in the function table structure. That's going to
reduce the L1 cache hit rate, and I'd rather not do that.
Separate arrays would be fine, but just not unified like that.
Dan
------"it's like this&quo
ought to
use it where we can. (And it doesn't hurt us on those architectures where
we don't have it)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
if someone tries it and they tell
>me how it barfs.
Odds are the temps are irrelevant to the ultimate code speed. Any compiler
worth its salt will optimize them properly, and the ones that suck, well,
there's not much we can do about that. :)
aintain and runs fast. (Neither do I much care about
people who really care about winning or losing, 'cause they'll get in the
way of the two main goals... :)
Dan
------"it's like this"-
separate
threads (one per file) as an aid to asynchrony.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
've seen. It
has a function body anyway, just to be really sure.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
>On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
> > I don't want to do int->pointer casts anywhere in the source if we can
> > possibly avoid it. Yech.
>
>In which case, do we *need* a type that can h
At 02:21 PM 9/20/2001 -0400, Andy Dougherty wrote:
>On Thu, 20 Sep 2001, Dan Sugalski wrote:
>
> > At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
> > >On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
> > > > I don't want to do int->point
to shake off the
"Oh, it's character data! I can use the functions!" reaction.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PRO
"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
cheap.
Just because some systems have a really pathetic I/O system doesn't mean we
should penalize those that don't...
Dan
--"it's like this"---
Dan Sugalski
ual machine. The limit on system threads can be tuned to
>optimally spread execution across available CPUs. It could be as
>small as 1 on single-processor systems that don't switch thread
>contexts well.
That adds a level of complexity to things that I'd as soon avoid. On the
ot
At 01:53 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote:
> > Nope. Internal I/O, at least as the interpreter will see it is async. You
> > can build sync from async, it's a big pain to build async from sync.
> > Do
Just a reminder--function names shouldn't exceed 31 characters. The C
standard doesn't guarantee anything past that...
Dan
--"it's like this"---
Dan Sugalski
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 02:04 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
> > >For clarification: do you mean async I/O, or non-blocking I/O?
> >
> > Async. When the interpreter issues a read, for example, it won't assume
> th
At 02:17 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 05:09:52PM -0400, Dan Sugalski wrote:
> > Just a reminder--function names shouldn't exceed 31 characters. The C
> > standard doesn't guarantee anything past that...
>
>You think that's b
round 23M ops/sec. Nyah! ;-P
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
g isn't always -g. (It's /DEBUG for me on VMS)
Dan
----------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
that long a name :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
ome
cases...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>[I'm behind on my mail :-)]
>
>On Wed, 12 Sep 2001 13:19:40 -0400, Dan Sugalski wrote:
>
> >We're trying to align to a power-of-two boundary, and mask is set to
> >chop off the low bits, not the high
At 09:07 PM 9/20/2001 -0400, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>
> DS> There probably won't be any. The current thinking is that since
> DS> the ops themselves will be a lot smaller, we'l
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
y, so what he says goes here. It can wait
until after 0.02's out.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROT
At 07:41 PM 9/21/2001 +0100, Simon Cozens wrote:
>On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> > Doing this by hand with -O3, you can see a speedup of around a factor
> of 45
> > over an unoptimised runops loop, so it's definitely worth doing in so
At 12:45 PM 9/21/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
># At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
># >Stefan Dragnev:
># ># - $c{cc_denug} = ' ';
># ># + $c{cc_debug} = ' ';
># >
># >So *that*'s why -g kept a
27;ll be able to profile code and then build, either
dynamically or statically, a set of larger ops so we can cut out some of
the overhead associated with the ops.
Dan
--"it's like this"-
#x27;t have the
spare $500 at the moment.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
t. We should put all non-integer
constants into the constants section, not inline.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
n"
print P0
you won't get "A multipart string" out, because you will. :) (Once we
create the PMC code and list PMC library, of course...)
Dan
------"it's like this"---
On Sun, 23 Sep 2001, Simon Cozens wrote:
> On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko Hietaniemi wrote:
> > unaligned access
>
> Bother. It is as I feared.
>
> Dan, we need to do something about this. The choices are: put floats into the
> constant section, or ensure instructions are ass
On Sat, 22 Sep 2001, Benjamin Stuhl wrote:
> --- Simon Cozens <[EMAIL PROTECTED]> wrote:
> > On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko
> > Hietaniemi wrote:
> > > unaligned access
> >
> > Bother. It is as I feared.
> >
> > Dan, we need to do something about this. The choices are:
> > pu
On 22 Sep 2001, Ask Bjoern Hansen wrote:
> [EMAIL PROTECTED] (Dan Sugalski) writes:
>
> > I've got a mac suitable for setting up as a test platform for parrot
> > now, courtesy of Grant. Does anyone have any connections with Apple?
> > I'd like to see about get
t need
fixing. :(
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
e of "huge arrays of
>tightly packed integers".
For bytecode, it's not a big problem, certainly not one I'm worried about.
Machines that want 64-bit ints have, likely speaking, more than enough
memory to handle the larger bytecode.
through I18N, yes.
So, does anyone want to take a shot at some sort of library routines to
handle I18N for the error code?
Dan
--"it's like this"---
Dan Sugalski
to toss 'em. Your proposed solution, while reasonable, is also
likely to be awfully slow.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
mulative effects of that
2-3 percent...)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 10:36 AM 9/24/2001 -0400, Michael Maraist wrote:
>On Mon, 24 Sep 2001, Buggs wrote:
>
> > On Monday 24 September 2001 03:27, Dan Sugalski wrote:
> > > At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
> > > >http://astray.com/mandlebrot.pasm
> > &
of translators.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 12:24 PM 9/24/2001 +0200, Bart Lateur wrote:
>On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote:
>
> >Nope. At the very least, a bytecode file needs to start with:
> >
> >8-byte word:endianness (magic value 0x123456789abcdef0)
> >byte: word
At 01:16 PM 9/24/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Subject: What should and shouldn't get documented?
> >
> > I see there's a lot of embedded documentation going into the core, and
> > that's a good thing.
(probably set
at perl compile time or via an ENV entry or system locale or something) and
spits out a formatted error.
I'd love it if someone with more I18N experience than me would draft up a
proposal, even if it's "We should do what ZZZ does, which is..."
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
er. It'll be in the bytecode file
on-disk, just not in the instruction stream itself.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 09:56 AM 9/24/2001 -0400, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> >> do we always emit one in
> >> loops?
>
> DS> At least one per statement, probably more for things like regexes.
&
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
e able to switch oploops
> > dynamically, but I can't think of a good way to do that efficiently.
> >
>
>long-jump!!!
I did say *good* way... :)
>This would work well for fake-threads too
We're not doing fake threads. Luckily we don't need it for real ones.
't that make parrot GPL'd?
Not if we re-implemented it. Which wouldn't be unreasonable if the
interface is good.
Dan
--"it's like this"---
Dan Sugalski
rth. At the moment I
don't think so, since there's no benefit to going with a zero register over
a zero constant, but that could change tomorrow.
Dan
--"it's like this"---
Dan S
freeze is over this can go in.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
prints.
>In any case, what we've done here is dynamically create an array each time
>through the loop.
Yes, but we're doing this with a stack-based system anyway. It's just an
anonymous pesudo-array (i.e. the stack top), but an array nonetheless.
e their own.
LGPL's much better, though we still have the issue of portability and
self-containedness. We'd probably end up having to ship gettext with perl,
which has its own set of problems.
Dan
--"it&#
On Tue, 25 Sep 2001, Kenneth YK Young wrote:
>
> I listened in for a while but no one mentioned
> Windows CE as a target. I believe that's becoz no
> perl5 on Windows CE?
Nope. More because we've no development tools or platform for
WinCE. (Unless the iPaq counts, but I presume it doesn't) I'd
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
raic transforms compilers can and do do) but it's not going into the
source.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
urrent_fixup_section"
Whether we have a set of get_constant_FOO(x) functions for the various
types of FOOs or just force casting is up in the air.
Make sense? There's good reason for it, really there is.
Dan
-----
e (might,
but I've never tried it on VMS). Pure perl's preferable, as we can ship
whatever we need and don't have to force an install of any modules to build
Parrot, and I think that's good at the moment.
Dan
y
of the code across multiple simultaneous invocations of Parrot.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 02:57 PM 9/25/2001 +0200, Bart Lateur wrote:
>On Mon, 24 Sep 2001 11:29:10 -0400, Dan Sugalski wrote:
>
> >However...
> >
> >I was talking about a different instance of "bitmap". More like:
> >
> > newbm P3, (640
At 05:28 PM 9/25/2001 -0700, Damien Neil wrote:
>On Tue, Sep 25, 2001 at 08:18:04PM -0400, Dan Sugalski wrote:
> > That'd be interesting. Try cobbling up a version of the assembler that
> does
> > big-endian assembly and a loader that reads and byteswaps, and see what
>
latively, and padding to 8k
means the section should start on its own memory page so we won't be making
a private copy of anything but the fixup section.
Dan
----------"it's like this"-
At 06:26 PM 9/25/2001 -0700, Benjamin Stuhl wrote:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 06:07 PM 9/25/2001 -0700, Benjamin Stuhl wrote:
> > >But why store it in this
> > >format? What we really need to store is the list of what
> > we
> &g
64-bit system? :^)
Don't bother. Make the constant be ~0xfff. :)
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
301 - 400 of 4461 matches
Mail list logo
