> Segfault in the lexer. Bad.
>
> 349 sprintf(label, "%s%d", yytext,
> frames->label);
> (gdb) p frames
> $1 = (struct macro_frame_t *) 0x0
I didn't know how or why or what a frame is in this
context which is why this isn't a patch :)
__
Hi,
> fixed sizes of integer, so I'd aim some ops at low-level types of
> known size and leave it at that.
Quite a while back, I did add a few opcodes for fixed size integer operations
for Parrot .. But they were added for a totally different HLL :)
> matter what you do with the high bits. I
Hi Dan & Michael,
As a guy who speaks a strange language (multi byte chars, multi glyph
chars, caseless
text and half vowels) , I think you have made it too complicated than
it should be .
> charset end of things, offsets will be in graphemes (or Freds. I
> don't remember what we finally decided
If memory serves me right, Paolo Molaro wrote:
> > You're insane. :)
Why does this sentence keep popping up whenever anyone discusses modding
gcc :)
> > registers, and register starvation's one of the more annoying things
> > a compiler has to deal with.
imcc !
But this is what Dan had to say
If memory serves me right, Dan Sugalski wrote:
> It's possible to just go ahead and do it *all* at runtime, and have
> no compile time component at all--just a series of "newclass,
> addparent, addattribute" ops, assuming those are the op names we go
> with. Classes just get created at code init
If memory serves me right, Bryan C. Warnock wrote:
Reply inline ... and I've said more than I've quoted ... It could be
called as a critical appreciation ... though not much has been appreciated
below ... and what I know about parrot can be written on a shirt sleeve ;-)
Please do tell me if I've g
If memory serves me right, Bryan C. Warnock wrote:
> > No .. to add large numbers very quickly ... ie split registers and
> > enemies ;-)
>
> Understood. My point was that - to parallel virtual machines with
> physical ones - the big drive for 64-bit has never been about squeezing
> out another
If memory serves me right, Bryan C. Warnock wrote:
> Not to mention all the *other* problems we'll have if we've got more
> than 2^31 different opcodes. (Although that's why there's UUIDs now,
> isn't there?)
I think parrot has already crossed the limit of 1024 ...
(I can't even keep 256 opcodes
If memory serves me right, Benjamin Goldberg wrote:
>
> I suppose if there isn't a windows binary out there, I could try
> downloading and installing a C compiler (gcc? djgpp?) and then
> compiling my own parrot... but I don't want to do that much work!
>
Cygwin ? ... I'm not using windows but
Hi,
I was just wondering about the tail call confusion around here.
Why not just mark a tail call in bytecode ?.
This is not strictly a new idea , and is "inspired" by:
"""
In addition, each of these instructions may be immediately preceded by a tail.
instruction prefix. This
If memory serves me right, Simon Wistow wrote:
> I'm not sure if the tutorial has gone anywhere but I cam across this
> earlier which may be useful as a start.
>
> Something about using TreeCC would be nice as well.
What would you need about TreeCC ?. I think Rhys has written a nice
write up for
If memory serves me right, Leopold Toetsch wrote:
> > Is it possible and/or meaningful to read and write from a part of a
> > register(e.g. a single word) in pasm?
I always thought bitwise "and" and "or" were the things to use to modify
partial content ?. Though I can't say if that makes sense be
If memory serves me right, Leopold Toetsch wrote:
> > I'm assuming that the temporaries are the things being moved around here ?.
>
>
> It is not so much a matter of moving things around, but a matter of
> allocating (and renumbering) parrot (or for JIT) processor registers.
Ok .. well I sort
If memory serves me right, Dan Sugalski wrote:
> This sounds pretty interesting, and I bet it could make things
> faster. The one thing to be careful of is that it's easy to get
> yourself into a position where you spend more time optimizing the
> code you're JITting than you win in the end.
I
If memory serves me right, Nicholas Clark wrote:
> I had a (possibly) impractical idea - computed goto / JIT
> (or even computed goto / prederef / jit) core
>
> I don't know whether this is possible:
>
> Inside a cgoto core have 1 extra op - enter JITted section.
>
> The bytecode is "compiled"
If memory serves me right, James Michael DuPont wrote:
> > JVM had a LineNumberTable and VarNameTable for debugging which were
> > declared as ``attributes'' to each method in the .class tree.
> >
> > I suppose VarNameTable is totally irrelevant for Parrot ...
>
> I dont know that, what is it? Va
If memory serves me right, James Michael DuPont wrote:
> I just want to know how where we can put it. The Microsoft IL
> has a whole section on meta-data,
AFAIK, that just holds the offset, line number and filename. IIRC the
JVM had a LineNumberTable and VarNameTable for debugging which were
dec
If memory serves me right, James Michael DuPont wrote:
> > > Bah. That's "parrot -o foo.o foo.pmc" isn't it?
> >
> > And if we make C a parrot supported language we can even build parrot
> > with parrot?
Hmmm... bootstrapping
> 1. The gcc : I have %99 of the information about the function b
If memory serves me right, Erik Bågfors wrote:
> But if I write a library in ruby that depends on the missing_method
> method it will not be usable from other languages, since those languages
> doesn't call missing_method if the method they try to call doesn't
> exist.
Hmm... that's twisting lang
If memory serves me right, Erik Bågfors wrote:
> > :-) Python basically requires that each step in the process be
> > overridable. (1. look up attribute 2. call attribute, at least in
> > `callmethod's case).
would this be more of what you need ?
obj.__dict__["foo"].__call__();
/me again shows
If memory serves me right, Leon Brocard wrote:
> An interesting project to do would be to do a Java->Parrot compiler.
Hmm... I think with the current Parrot setup that might be a bit difficult.
We need object instructions for that , also I need to be able to define
classes,interfaces and all the J
If memory serves me right, Cory Spencer wrote:
> most example languages implement a complete compiler (ie lexxer -> parser
> -> optimizer -> code emitter), which seems to be somewhat of a
> duplication of labour.
Some are in C, others in pasm and yet others in Perl ... how do do you re-use
libr
If memory serves me right, Jonathan Sillito wrote:
> x = a.f # get the method, a limited form of currying
> # since the first arg (a==self) is stored
> x() # output: A.f()
>
> setattr(A, "f", g) # replace A's f with g
>
> a.f()# output: g()
> x() # output (still): A.f()
If memory serves me right, Dan Sugalski wrote:
> rather than attributes, but I may be incorrect here. Are the current
> python instance attributes both:
>
> *) defined per object rather than per class
> *) Essentially global, that is not hidden from parent classes or
> anything. (Basically one b
If memory serves me right, Paolo Molaro wrote:
> The CLR runtimes use 16 bit chars and UTF16-encoded strings (at least as
> far as it's visible to the 'user' programs).
1023.2.3 #Strings heap
11 The stream of bytes pointed to by a "#Strings" header is the physical
representation o
If memory serves me right, Nicholas Clark wrote:
> That doesn't sound right. But if it is right, then it sounds very wrong.
>
> (Translation: Are you sure about your terms, because what you describe sounds
> wonky. Hence if they are using UTF8 but with 16 bit chars, that feels like a
> silly desig
If memory serves me right, Nicholas Clark wrote:
> fussy. I presume Rhys is thinking about compiling C code to parrot, and then
> linking through to native C code (such as the native standard C library) via
> parrot.
Nope ... At least for our .NET platorm stuff ,we are planning to compile
glibc i
If memory serves me right, Chris Dutton wrote:
> Actually, if you really want Eiffel to compile to Parrot, it might be
> interesting to work on getting ANSI C to compile to Parrot first, since
> most Eiffel compilers use compilation to C as an intermediate step.
This won't be too much of stretch
If memory serves me right, Dan Sugalski wrote:
> >> Why would we want to avoid this? It looks exactly like what ought to
> >> happen.
If you can provide that in-vm , it would be a lot faster ...(hmm, that's
one argument that should convince you ;)
But like I said , I need lots of sticky notes
If memory serves me right, Erik Bågfors wrote:
> > >> would a be able to modify itself ? (unfortunately C# allows that)
> > >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=
If memory serves me right, Dan Sugalski wrote:
> language-level "we're object-oriented dammit!" objects, not the
> lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
> reference-style objects and non-reference values.
How large can a non-reference value be
If memory serves me right, K Stol wrote:
> I'm thinking of a compiler for Tcl which produces Parrot Assembly code,
> but the source language (which will be compiled) is not definite yet.
Instead of generating Parrot assembly, you might find it easier to
generate imcc code which is a simplified
If memory serves me right, Nicholas Clark wrote:
> A Java bytecode to parrot bytecode translator
Oh... the horror ... ! ... I wrote the entire JVM loading features
of JILC (now in jilc.sf.net, because the savannah project got removed
from inactivity).. I'm not working on or doing anything
If memory serves me right, Dan Sugalski wrote:
> What I'd like is for folks to take the next day or three to think of
> the things that they need parrot to do that aren't working or
> designed yet, and throw them at the list. (Try against the latest
> CVS, just to make sure that it's not gotten
If memory serves me right, Leopold Toetsch wrote:
> WOuld it help to split imcc.y into main/parser/parser_utils or are you
> doing this anyway?
yes pushing some code from imcc.y into a seperate file is what I had in
mind ... But have not got to that yet ...
Was curious about the following lines
If memory serves me right, Leopold Toetsch wrote:
> Yes, but I think, that incompatible changes shouldn't be necessary any
> more - sorry for breaking things.
No problemo ... I just hate working on the same things again ...
> SymReg *r = mk_ident(char *name, char type)
> iANY("add", R3(r0,r
If memory serves me right, Leopold Toetsch wrote:
> Therefore these changes were necessary:
Is there any other way to feed imcc code other than via writing to a
file and running it ?...
My work needs a lot of string substitutions to work with the new IMCC ...
Dan was saying something like a C int
If memory serves me right, Leon Brocard wrote:
> Loaded...
> dlfunced...
> ../parrot: relocation error: /usr/lib/libSDL-1.2.so.0: undefined symbol:
>pthread_mutexattr_init
>
I don't know if this is twisting the knife in the wound ... but it works
for me ...
[gopal@mushroom parrot]$ perl assemble
If memory serves me right, Gopal V wrote:
> I couldn't make myself name it "dotnet".ops so named it dotgnu.ops ...
On nicholas' advice I'm writing out the expected results for all
these opcodes... in the hope that someone more well versed in writing
..t files
I guess I have more to learn about writing opcodes for parrot ... But
all I can say is you people make it almost too easy :-)
If memory serves me right, Leopold Toetsch wrote:
> The INTVAL could be a "long long".
Ok ... /me sort of needs an Int32 there ...
> Parrot_Int2 will be generated by a t
If memory serves me right, Rhys Weatherley wrote:
> on 32-bit, 64-bit, and native-sized integer types (8-bit
> types don't need it).
Hmm... maybe there's only one way to stop this lng thread ...
Oct 18 20:31:20 no, no, you have it wrong. you don't
*ask* us t
If memory serves me right, Dan Sugalski wrote:
> I do actually like it. I was shooting for simplicity with the
> assumption that, since we were calling out to non-parrot-aware code,
> all bets were off with respect to type safety. If you load in
> libgtk.so and call functions dynamically there'
If memory serves me right, Dan Sugalski wrote:
> Currently open is the situation of flags and such from more complex
> calls. (Like what we do if we get back a pointer that's getting
> stuffed into a PMC--do we set the type, if so what type, and what do
> we set the flags to?)
So is it totally
If memory serves me right, Leopold Toetsch wrote:
>
> > Hmm... I guess I can only quote the ECMA spec here ...
> > conv.i1 Convert to int8, pushing int32 on stack
>
>
> truncate to [-128..127]? And why the push?
IL is a fully stack language ... pop int32, trunc, push int8 ...
Yes,
If memory serves me right, Leopold Toetsch wrote:
> Please have a look at include/parrot/datatypes.h. I hope that there are
> all types you'll need.
It seems so ... but I'm not really certain about Float data types ...
> Can you specify, what opcodes you would need?
Hmm... I guess I can only q
If memory serves me right, Paolo Molaro wrote:
> If you think you have novel ideas in the JIT (or in the intepreter) space,
> you're probably just deluding yourself.
Oh yes I said that "debuggable JIT" is one of my very own personal
ingienous ideas .
This list for people who are intereste
If memory serves me right, Paolo Molaro wrote:
> You can find the complete examples of how the jit debugging features
> work in the mono tarball (mono/doc directory):
Same old lupus I never realized I had a wolf pack hunting me :-)
> the above was a partial cut&paste with s/mono/parrot/ :-)
If memory serves me right, Tim Bunce wrote:
> "CCured is a source-to-source translator for C, which
> analyzes the program to determine the smallest number of
> run-time checks that must be inserted in the program to
> prevent all memory safety violations."
Yow ! .. the ou
If memory serves me right, Leopold Toetsch wrote:
> pusha/popa is overkill. The called functions always save bp and bx,di,si
> when used. ax is the return value, remaining is dx (cx is used by
> shifts) - i386 of course.
Ok ... push_necessary() ;-) ...
> > Speaking about debugging calls fro
If memory serves me right, Leopold Toetsch wrote:
> Yep, you are right - I did miss this point sometimes. We have to do a
> _save_registers before calling code, that might throw an exception.
Excuse me for butting in ... But how are the parameters to a C code being
passed .. I assume that would u
If memory serves me right, Nicholas Clark wrote:
> I believe that it can be done with just a C compiler. (no make tool or shell
> needed). If we use an equipped machine to unroll the makefile into the correct
> steps (in the correct order), and turn that into C code that runs each in
> turn, then w
If memory serves me right, Markus Laire wrote:
> Miniparrot can then be used to build everything else, including full
> parrot, perl6, other parrot-supported languaged, etc..
>
> This 2nd step might be e.g. Bytecode-compiled perl6-program which is
> simple enough to work with miniparrot.
Please
If memory serves me right, Dan Sugalski wrote:
> Sure. Or at least not forbidden.
k ...
> that case, why bother verifying?
Hmm wouldn't the JIT benifit from a pre knowledge of basic blocks
and types or some information ? ... (I seem to think so ...).
> at runtime anyway. With a full scan o
If memory serves me right, Dan Sugalski wrote:
> All you need to do is change the offset a bit to point to an opcode
> and you'll be fine.
Hmm... you mean to say that a jump to a non-instruction is valid ? ..
We've had the verifiability question hashed out ... but jump target
validation is one
If memory serves me right, Dan Sugalski wrote:
>
> Should be reasonably straightforward. Hopefully quick, too, as I'm
> pressed for time here.
> --
Hmm... Object frameworks ? ... (or is that shelved for the present ?)
Gopal
--
The difference between insanity and genius is measured by success
If memory serves me right, Dan Sugalski wrote:
> (Parrot bytecode is inherently unverifiable as well, at least in
> the general case, which exacerbates the problem)
Hmm... Why ? ... Loose typing ?
Or does it just become an undecidability problem ?...
Gopal
--
The difference between insanit
If memory serves me right, Leopold Toetsch wrote:
> The changes are 99.9% internal - all (parrot + perl6) tests are running
> during these changes.
Hmm... a .pbc I assembled last week refused to run today ... which was
really surprising for me ..
`PackFile_unpack: Bytecode not valid for this int
Hi All,
We've been thinking long and hard about Parrot and found that
the spec viz packfile versions , code segmentations, opcodes and
virtually everything is changing minute to minute ...
So we think it might do good to have a Parrot-dev'r do the
co-ordination duties . What I ha
If memory serves me right, Ramesh Ananthakrishnan wrote:
> I have this code
>
> set S12 ""
> set I0 0
> WHILE:
> concat S12 "hi"
> add I0 1
> lt I0 10 WHILE
> print S12
> ret
...
> Right version of Parrot, so is this a bug?
I get
No entries on stack!
hi
If memory serves me right, Dan Sugalski wrote:
> Huh? No, you misunderstand. Each chunk of the bytecode has a separate
> TOC for stuff like this. The full identifier would be
> file/chunk/entry, which should be reasonably guaranteed to be unique.
> When the compiler's emitting code to reference
If memory serves me right, Piers Cawley wrote:
/me is a newcomer from DotGNU ... and has missed the mails quoted,
hence here's what I have ..
> Regarding JVM - Parrot Compatibility
> Newcomer Karthik Kumar is interested in writing a tool to convert java
> ".class" files to parrot ".
If memory serves me right, Bryan C. Warnock wrote:
> > It looks like we're going to need 8,16,32,64 bit types...
>
> Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe
> for floating point numbers?
IL (Ecma-335)
--
134.1.1 Floating Point
14 The floa
If memory serves me right, Leon Brocard wrote:
> It looks like the DotGNU weekly IRC meeting will be discussing
> Parrot. Could be interesting:
> http://www.dotgnu.org/pipermail/developers/2002-October/008345.html
A condensed summary of the IRC meetings have been posted as :-
http://www.dotgnu.org
63 matches
Mail list logo
