Re: C# (.NET) has no interpreters
Simon Peyton-Jones [EMAIL PROTECTED] wrote: You can't really implement C-- on top of C efficiently, because of (a) tail calls and (b) the runtime interface for garbage collection, exception handling etc. Agreed. But any practical C-- implementation will start with a C/C++ compiler so that it can get structs and typedefs right, and preferably also inline functions. It would have to discriminate and reject "ill-behaved" C constructs. I was not thinking of implementing C-- "on top of" C; certainly not on top of ANSI C. But I could imagine a (Perl?) program that translates C-- into asm-ified C without C function calls. All you'd really need are a few primitives for getting and setting the sp and ip, a list of the registers, and some macros for inserting span metadata into a different linker section. All of this would be straightforwardly implemented with GCC using a smallish machine-specific header. I'll bet a non-optimizing version could be produced with no asm - just use volatile for variables and goto for jumps. Accessing the stack pointer and inserting span data might require asm. Best -John -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: RFC: Foreign objects in perl
On Sun, Aug 06, 2000 at 01:24:10AM -0400, Dan Sugalski wrote: John Tobey wrote: Picture this. A Lisp (or Java, ...) structure holds a Perl interpreter. A Perl variable holds a reference to the Lisp structure. Structure and interpreter become inaccessible to all threads. Perl will never know it's done with the Lisp structure, neither Perl nor the structure will ever be collected, and we will have defeated mark-and-sweep. FWIW, this isn't a case I'm worried about. If an embedding program doesn't explicitly destroy an interpreter, then its reasonable to assume that the interpreter's not dead and shouldn't be cleaned up after--if someone's leaking interpreters then, well, they've got bigger problems than the odd foreign object. :) I'm not so sure I agree with this. Other-language modules in a large application might have good reason to use a private Perl interpreter within an encapsulated interface. Anyway, my point is valid for data structures other than interpreters. Lisp variable `perl-int' holds an interpreter, which contains a by-Perl-unreferenced anonymous scalar, which contains a Lisp structure, which contains a reference to the scalar. - | | | | | Perl | SCALAR(0x8335bfc) | | | | | | | | ^ | | V | |-+--|--| | | | | | car | cdr | | | | |-+-| If Perl uses reference-counting as its only garbage collection, this loop will have to be broken explicitly. But if we anticipate possibly implementing mark-and-sweep, our mark routine should call Lisp's mark routine on those Lisp objects we still reference, which would allow those we don't to be collected. -John
Re: RFC 46 (v1) Use features of portable, free compilers
On Sat, Aug 05, 2000 at 10:02:23PM -0500, Jarkko Hietaniemi wrote: On Sat, Aug 05, 2000 at 07:25:41PM -0700, Russ Allbery wrote: libraries and tools are better than the vendor counterparts; Sun's compilers and linkers are considerably better than GNU's for SPARC C code, for example. Likewise for Digital/Compaq. gcc's Alpha code generation and optimization is really inferior. I don't doubt this in the least, but I still use GCC on SPARC systems and would be reluctant to buy a system with a poor GCC port. If you want my business, work on the GCC port for your system, not some lousy proprietary compiler. It's not even about politics. I'd take a good, portable, proprietary compiler if it gave me all the benefits of GCC and more. Similary for linkers and libraries. I am furthermore *not* suggesting dropping support for non-Unix or non-GCC platforms. I am merely saying that that is not where our focus should be. Cheers -John
Re: perl6-internals-gc sublist
Nick Ing-Simmons [EMAIL PROTECTED] wrote: John Tobey [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: Yup, and I realized one of my big problems to GCs that move memory (references that are pointers and such) really isn't, if we keep the two-level variable structure that we have now. The 'main' SV structure won't move, while the guts that the equivalent of sv_any points to can without a problem. I certainly hope this data layout factoid is still subject to change. Having an SV have a fixed address is handy for C extensions. The 'entity' has got to have some 'handle' to defines its existance. If not the SV* data structure then what is it that defines the thing? Just like in Perl, if you want a reference to it, put it somewhere and use a pointer. Otherwise, use it by value. (three words, or two if flags are dropped, or four if vptr is added, or one if everything is crammed into a pointer with low bits commandeered). -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: perl6-internals-gc sublist
Dan Sugalski [EMAIL PROTECTED] wrote: That's going to complicate a lot of things, and it will mean perl will end up doing all sorts of temp SV creation when these 'mini SVs' get passed to subs. Plus it complicates life a lot for people writing the guts. (Which would be us. :) The proof is in the pudding, so I won't add more to this discussion until I have some code to back it up. I think this sort of optimization is very premature, We're not talking about optimizing (or even implementing) this today. We're talking about leaving the door open. and it will require jumping through a lot of hoops because of perl's profligate use of dynamic polymorphing. If it's needed, well, we'll do it, but I'd rather put the effort elsewhere to start. Not to be rude, but the effort is not yours to put. Except for your own effort, that is. Although I'll read your every suggestion with due consideration, I (and, I imagine, most of us here) will code exactly that which interests me. Best -John
RFC - Use features of portable, free compilers and libraries
I'm sending this to perl6-internals and BCC'ing it to perl6-rfc. Maybe that is a good compromise. -John =head1 TITLE Use features of portable, free compilers and libraries =head1 VERSION Maintainer: John Tobey [EMAIL PROTECTED] Date: 5 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: =head1 ABSTRACT There is no sane reason why *nix vendors continue to push proprietary compilers and system libraries on their customers when better, free replacements could be had for little effort. Eventually, they will realize this and start porting GNU Libc and Binutils, contributing whatever unique features their current tools have to the GNU versions, and shipping these packages with their systems. Perl should take aggressive advantage of these programs' features in anticipation of eventually not having to support all the other cruft that's out there. =head1 DESCRIPTION Sun beats AIX and loses to Linux for (practically) no other reason than the intermediate quality of its GCC and GNU Binutils ports. Bla, bla, Glibc is portable, so port it. Get with it, Sun! Get with it, HP! Wake up, IBM! Come on, SGI! Hello, MSFT! The GNU stuff is nice. It is free. If it comes with the system, there is no licensing war. Think about how much it would cost the vendors to merge their features into the GNU stuff. Then think about how much developer effort would be saved worldwide if all major systems shared a C library, compiler, preprocessor, and linker. Configure would be 5% its current size, if it would exist at all. We now have the chance to BSAVE THE WORLD by giving these clowns a serious incentive to do the BRIGHT THING. =head1 IMPLEMENTATION Perl 5 already takes advantage of some GNU CC features. It should henceforth consider anything below GCC 2 as CCRIPPLED_CC. Perl works around limitations of Standard C library functions that GNU Libc has already overcome. Csprintf() comes to mind. Calloca(), Iplease somebody tell me I can use Calloca()! We should stop duplicating effort and take advantage of that code. GNU CPP supports varargs macros, so why not ship GNU CPP with perl? There is no GPL issue if it is only used in the build. =head1 ISSUES I have not looked at the BSD C library, so I don't know what to say about it. Is it portable? Is it as featureful as GNU Libc? Does it perform as well or better? =head1 REFERENCES The GNU C Library Reference Manual, Using and Porting GNU CC, GNU Binutils manual. Get 'em through www.gnu.org.
Re: perl6-internals-gc sublist
Dan Sugalski [EMAIL PROTECTED] wrote: This seems a bit premature, given that we haven't actually come up with even a framework for an API, or hashed out much on the format of variables or the interpreter structure. (Nor the threading or event stuff...) Are you comfortable with a shorter term list (Say,two or four weeks) that will work up several different GC RFCs, based on various constraints? If so, I'm fine with it. Sure, if that's your preference. I guess, more than establishing a working group, I'm hoping to siphon GC debates out of the more general internals list, since a lot of people love discussing GC at great length, and I don't expect that debate to have much relevance to the rest of the internals. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: perl6-internals-gc sublist
OK. Ask, cancel that request. Sorry. -John Dan Sugalski [EMAIL PROTECTED] wrote: At 02:45 PM 8/4/00 -0400, John Tobey wrote: I guess, more than establishing a working group, I'm hoping to siphon GC debates out of the more general internals list, since a lot of people love discussing GC at great length, and I don't expect that debate to have much relevance to the rest of the internals. I'd rather not do that, though. The perl lists are supposed to be rather more targeted than that. (Not that I mind a good GC discussion, but the point is to get an RFC for a workable scheme) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
relocatable perl, again (was Re: kpathsea)
[CC'd to perl6-build] Dan Sugalski [EMAIL PROTECTED] wrote: At 03:25 PM 8/4/00 -0700, Russ Allbery wrote: Simon Cozens [EMAIL PROTECTED] writes: Sounds good. Here's a slight modification: perllib.db is a cache; lookups take place as normal, but then any new information is written into the cache. The cache is invalided every $configurable period. Putting on my sysadmin hat, anything that a program wants to modify during its normal course of operation and isn't a dotfile in the user's home directory is inherently Evil and not to be tolerated if at all possible. I fully agree. Not that I dislike the idea of figuring out file locations at module install time instead of runtime, mind--I rather like that. (Do the work once, rather than every darned time) make install, however, should be the only thing that messes with these files. How tough would this be? # perl -MPerl::Mover -e 'copyperl "/home/me/local"' Perl/Mover.pm does whatever's needed regarding binedits, relinking, and whatnot. Would this allow us to remove the discussion from internals, at least? -John -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: C--
Joshua N Pritikin [EMAIL PROTECTED] wrote: A few more clicks and I found: http://www.cminusminus.org/ Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free (non-DFSG-compliant) complete. Others in progress. Why not specify as a C extension: I'm still looking for that. -John [1] http://www.cs.princeton.edu/software/lcc/
Re: inline mania
Sam Tregar [EMAIL PROTECTED] wrote: On Tue, 1 Aug 2000, John Tobey wrote: The people here are rightly skeptical about the effectiveness of using the 5.6 code base as a starting point for v6, but I have a pretty clear vision of how to do it, and I am committed to giving it a try, even if no one else will. In fact, I'll give you all a tentative schedule: Wait, you're going to develop Perl 6 ALONE? Wasn't this going to be "the community's rewrite of Perl"? Shouldn't you be trying to rally support for your vision before issuing schedules? Not really. I'm going to START developing MY IDEA of how Perl 6 might work. Very likely, I'll stop or merge with someone else's ideas along the way. The schedule is just to get something down, to start fleshing out my idea and maybe provoke other people into starting on their own visions, as Simon Cozens has (though he seems to deny it) done with GLib and Sapphire. I'm not trying to knock you - I'm not at all against hearing you plans and possibly helping out. This just seems like a pretty strange way to approach a community effort. 15 August 2000 - detailed draft spec to perl6-internals. 31 August 2000 - revised spec after discussion. What? You're expecting all the various perl6-* lists to come up with final RFCs be the end of the month? And you're expecting to have Larry's final plans by then? Well, I'll read RFC's as they appear and adjust to them as they are approved, but the stuff I want to do now does not need to wait. This sounds hopeful, but mostly unfounded. Without starting with threading and Unicode as primary features you're going to be fighting an uphill battle ala Perl 5. This I hope to address in my first architecture document. Thanks for the comments. -John
Re: inline mania
Tim Bunce [EMAIL PROTECTED] wrote: So please, follow Chips wise lead, don't call your work Perl 6. It's called Pickle. "Andy Wardley" [EMAIL PROTECTED] wrote: Indeed. XS is hard, fast, dirty and ugly (in a sickly, beautiful kinda way), but there's nothing to stop you from wrapping it all up into a less efficent, but prettier API (with the possible exception of reference counting). There is no reason for it to be any less efficient (other than compilers' botching of `inline'). I favor leaving efficiency as a user option. In return for efficiency, we offer binary independence of interpreters. Pickle provides (or will provide) three modes of compiling: Default - perl.h is not included - total bincompat Refcount Cheat - the only bit structure knowledge is sv_refcount Gung Ho - all Default API functions are inline to the level of Perl 5's API You can select any of them with a single conditional. I believe Perl 6 (and v5.8) should support three interfaces along these lines, whether or not any Pickle code is involved. -John
Re: Feature request: Relocatable perl
[EMAIL PROTECTED] wrote:
Graham Barr wrote:
Well I think it is worth an RFC (not that I have time to write one just now)
If only to suggest some sample implementations. Do other languages do it ?
If so how ?
Ok, Ok, I'll do a RFC then... :-)
Actually the only thing affected by LD_LIBRARY_PATH is libperl.so, as
modules are loaded in by dlopen() or equivalent, so the full path in
that case is specified in the call to dlopen().
Solaris 7 onwards has a nice linker feature called $ORIGIN. This allows
the location of run-time linker dependencies to be specified relative to
the location of the executable.
Both Windows and Linux can swing this, too. I believe linux (GNU
Libc, to be precise) uses $ORIGIN in a Solaris-compatible way.
I don't mean to imply, however, the binediting perl has no place.
-John
This is probably best illustrated with
a simple example:
$ pwd
/tmp/app
$ cat bin/main.c
extern void hi();
int main() { hi(); }
$ cat lib/hi.c
#include stdio.h
void hi() { printf("hi!\n"); }
$ cc -G -K pic -o lib/libhi.so lib/hi.c
$ cc -Llib -R '$ORIGIN/../lib' bin/main.c -o bin/main -lhi
$ ldd bin/main
libhi.so = /tmp/app/lib/libhi.so
libc.so.1 = /usr/lib/libc.so.1
libdl.so.1 =/usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
$ bin/main
hi!
$ cd ..
$ mv app somewhere_else
$ ldd somewhere_else/bin/main
libhi.so = /tmp/somewhere_else/lib/libhi.so
libc.so.1 = /usr/lib/libc.so.1
libdl.so.1 =/usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
$ somewhere_else/bin/main
hi!
Another option for ELF based platforms that lack $ORIGIN (i.e.
everything other than Solaris AFAIK) would be to use the (standard?)
libelf library to write a little application that tweaked the RPATH in
the executable appropriately when perl is installed somewhere else other
than the default location. I think this would be far preferable to the
currently used horrible hacks involving either LD_LIBRARY_PATH or
greping and patching the executable.
--
Alan Burlison
Re: inline mania
Dan Sugalski [EMAIL PROTECTED] wrote: Non-inline functions have their place in reducing code size and easing debugging. I just want an i_foo for every foo that callers will have the option of using. Before we make any promises to do all that extra work can we measure (for various architectures) the cost of a real call vs inline. I want proof that inline makes X% difference. I'm not going to prove that. A normal C function call involves several instructions and a jump most likely across page boundaries. But if that function is already in cache from another use, you win. Assume, for a minute, you've got a 700MHz system with a 100MHz 128-bit data bus. If your code is inlined and works out to 256 bytes, that's 16 fetches on the main bus. That costs 112 cycles. On the other hand, if your Dan, you are completely missing my point. Okay, fine, non-inline may be a performance win in some cases. Inline may be a win in others. I am not proposing we mandate inlining in any case, I am proposing the exact opposite: that we let the caller decide in every case. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: Nick's performance theory - was inline mania
Nick Ing-Simmons [EMAIL PROTECTED] wrote: But is usually much easier add entropy - so start with its the same function - call it, and let compiler decide which ones to expand. You'll get no argument on that point. Please stop suggesting that I want to take the power of decision away from programmers *OR* compilers. If someone else wants to prove this, great. I just don't think it's that much trouble. (mostly psychological - what will people think if they see that all our code is in headers and all our C files are autogenerated?) We can unlink the .c files once we have compiled them ;-) Nope. Messes up source debuggers.
Re: inline mania
Dan Sugalski [EMAIL PROTECTED] wrote: At 05:55 PM 8/1/00 -0400, John Tobey wrote: Dan, you are completely missing my point. Okay, fine, non-inline may be a performance win in some cases. Inline may be a win in others. I am not proposing we mandate inlining in any case, I am proposing the exact opposite: that we let the caller decide in every case. Having thought about it a bunch more (because of this) I'm proposing we let the compiler decide. The caller doesn't know enough to make that decision. Read carefully. I said we *let* the caller decide, not *make* the caller decide. What, specifically, disturbs you about my proposal? -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: inline mania
Dan Sugalski [EMAIL PROTECTED] wrote: At 05:34 PM 8/1/00 -0400, John Tobey wrote: Okay. For starters, assume that every inline function is called in exactly one place in the translation unit that defines its non-inline counterpart. That one place being, of course, i_foo's foo. This is a natural result of a clean, PI-like-generated source. Bad assumption. How often is av_fill called? By "assume" I mean "ensure" here. As in, this is how we build our library. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: inline mania
Dan Sugalski [EMAIL PROTECTED] wrote: Bad assumption. How often is av_fill called? Only once in av_fill.c (generated by allfuncs.pl). In most other places, it's called as i_av_fill(). -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: inline mania
[EMAIL PROTECTED] wrote: John Tobey wrote: Why is he bothering? A year to produce a prototype doesn't seem like a useful way to expend effort on something that isn't actually perl6. It is actually perl6 if/when it's finished. Right, so it isn't a community effort then, as you intend doing it all yourself. I always welcome patches, suggestions, and constructive criticism. And if somebody else wants the "maintainer" role, I'll be happy to let them do that work for me. :-) I'm not saying it was. However I don't see how the proposal would aid the migration - after all what he is writing will be neither perl5 nor perl6. I am not "writing". I am "transforming". Ok, so neither is it a rewrite. I suspect it won't be called perl6 in any case. Well, if not, I'll have the satisfaction of having tried. Cheers -John
Re: RFC: On-the-fly tainting via $^T
Simon Cozens [EMAIL PROTECTED] wrote: On Tue, Aug 01, 2000 at 01:43:05PM +0100, Graham Barr wrote: Let me just say that Larry has said in the past that untainting was deliberatly left difficult to do, on the basis that something which can have serious effect (ie security) should not be easy to do. But then I suppose all previous decisions are up for re-deciding Yes, they are. If we're going to make it trivially easy to untaint, should we bother having tainting at all? :( Tainting has potential uses as data-tracking mechanism aside from security. If the keyword 'untaint' had to appear, it would be easier to find security issues than when m/(.*)/ is used. Uh-oh, now we're getting back into perl6-language territory... attempting to CC. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
