On Fri, 26 Oct 2001, Dan Sugalski wrote:
> Okay, here are the conventions.
Great. Anyone want to offer up some examples or should I just wait for
Jako support to see this in action?
-sam
Okay, here are the conventions.
*) The callee is responsible for saving and restoring non-scratch registers
*) The first five registers (I0-I4, S0-S4, P0-P4, N0-N4) are scratch and do
not have to be preserved by the callee
*) In *ALL* cases where the stack is used, things are put on the stack in
dan i have have been talking about the decimal math package for
bigint/bigfloat. i have some ideas and am looking for some of you to
work with me on this.
my idea is to use an old hardware trick called excess-3 to efficiently
do decimal adds/subtracts in word sized chunks. this is much faster th
We now have separate control and save stacks. saves and restores will *not*
affect subroutine calls, nor scope entries, lexical locks, or exception
handlers.
Dan
--"it's like this"---
Dan Sugalski
At 10:28 AM 10/26/2001 -0500, Brian Wheeler wrote:
>On Fri, 2001-10-26 at 09:57, Sam Tregar wrote:
> > On Fri, 26 Oct 2001, Brent Dax wrote:
> >
> > > What if I want my compiler to be lazy? Do you have the right to punish
> > > me for my laziness by making me add constant folding to my optimizer
At 08:32 AM 10/26/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
># More importantly, the answer to the preceeding question can be "Yes".
>
>So why don't we wait until we decide we don't have enough opcodes?
>Smells like premature optimization to me.
Note the answer was "can be", not "will be"...
Brian Wheeler:
# I've got a dumb question, and its probably because I've not
# been paying
# attention, so I apologise in advance.
#
# How does a program access more than 32 variables simultaneously? In
# real CPU architectures you've got main memory storage, but
# here we only
# have registers.
Dan Sugalski:
# At 10:51 AM 10/26/2001 -0400, Jason Gloudon wrote:
# >On Fri, Oct 26, 2001 at 06:54:32AM -0700, Brent Dax wrote:
# >
# > > What if I want my compiler to be lazy? Do you have the
# right to punish
# > > me for my laziness by making me add constant folding to
# my optimizer (or
# >
Sam Tregar:
# On Fri, 26 Oct 2001, Brent Dax wrote:
#
# > What if I want my compiler to be lazy? Do you have the
# right to punish
# > me for my laziness by making me add constant folding to my
# optimizer (or
# > perhaps making me *write* an optimizer just to do constant folding)?
#
# Actually,
On Fri, 2001-10-26 at 09:57, Sam Tregar wrote:
> On Fri, 26 Oct 2001, Brent Dax wrote:
>
> > What if I want my compiler to be lazy? Do you have the right to punish
> > me for my laziness by making me add constant folding to my optimizer (or
> > perhaps making me *write* an optimizer just to do c
On Fri, 26 Oct 2001, Brent Dax wrote:
> What if I want my compiler to be lazy? Do you have the right to punish
> me for my laziness by making me add constant folding to my optimizer (or
> perhaps making me *write* an optimizer just to do constant folding)?
Actually, a really lazy compiler will
On Fri, 2001-10-26 at 01:32, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Brian Wheeler <[EMAIL PROTECTED]> wrote:
>
> > Darn it, I fat fingered the log message.
> >
> > This is a fix which changes the way op variants are handled. The old
> > method "forgot" the last variant,
At 10:51 AM 10/26/2001 -0400, Jason Gloudon wrote:
>On Fri, Oct 26, 2001 at 06:54:32AM -0700, Brent Dax wrote:
>
> > What if I want my compiler to be lazy? Do you have the right to punish
> > me for my laziness by making me add constant folding to my optimizer (or
> > perhaps making me *write* an
On Fri, Oct 26, 2001 at 06:54:32AM -0700, Brent Dax wrote:
> What if I want my compiler to be lazy? Do you have the right to punish
> me for my laziness by making me add constant folding to my optimizer (or
> perhaps making me *write* an optimizer just to do constant folding)?
You don't have to
Tom Hughes:
# In message <[EMAIL PROTECTED]>
# Brian Wheeler <[EMAIL PROTECTED]> wrote:
#
# > Darn it, I fat fingered the log message.
# >
# > This is a fix which changes the way op variants are
# handled. The old
# > method "forgot" the last variant, so thing(i,i|ic,i|ic) would
# > gen
If I might make a very small suggestion, for clarity's sake you might want to consider
renaming your opcodes push_e and pop_e, or
push_x and pop_x. I don't know if this violates any naming conventions you already
have in place, however.
-Stephen
-Original Message-
From: Jeff [mailto:[
On Thu, 25 Oct 2001, Brent Dax wrote:
> With the patch attached, all tests pass on Win32.
>
This also gets MIPSPro working (although there continue to be lots of
warnings). We need to alter the build system to run genclass.pl (or
run it to remake the version of intclass.c which cvs gives out).
17 matches
Mail list logo
