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 about
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
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 point-n
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
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 in
If memory serves me right, Benjamin Goldberg wrote:
whine
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!
/whine
Cygwin ? ... I'm not using
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 the
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 because
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, 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 of
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 by the
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? Variable
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
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 bodies of
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
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
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
libraries
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 big
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 of
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
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 design
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 for
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,
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
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.pl
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 Nicholas no, no, you have it wrong. you don't
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 test
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 than me can help ..
conv_i1
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's
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:
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
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, Paolo Molaro wrote:
If you think you have novel ideas in the JIT (or in the intepreter) space,
you're probably just deluding yourself.
sarcasm
Oh yes I said that debuggable JIT is one of my very own personal
ingienous ideas .
/sarcasm
This list for people who
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
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 from
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 output
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 cutpaste with s/mono/parrot/ :-)
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 we
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 for
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:
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:
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 of
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 insanity
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
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 a
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 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
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 .pbc
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 :-
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 floating
61 matches
Mail list logo
