Romcc (Parrot and LinuxBIOS)
Hello all, I am on the LinuxBIOS list and my gut sense told me that a compiler that they are developing called romcc might be a fit for Parrot. Since Parrot uses CPU style assembler as its native language, it might make sense to match it with a compiler that can take advantage of this. Along comes romcc. The biggest problem w/ working in the BIOS is that you have to initialize RAM. That cannot be done in C because there is no RAM to do it in. Assembler is the only solution but thats an economic impossibility sometimes because of the scaricity of linux folks versed it it. So, sensibly, Eric Biederman [EMAIL PROTECTED] writes a small compiler that uses registers instead of RAM hungry stacks. Bingo !! But I feel like an idiot since I have yet to write a line of C code but in only about 5 emails, Eric tells me Yeah, thats doable Me Romcc uses registers, not stacks -- like the Perl6 Parrot VM Eric Actually quite a bit different. Eric Parrot will just not use stack oriented byte codes. But a call/return Eric stack will still be required. romcc does not use a call/return stack, Eric but romcc still implement subroutines. Me Is there any point in implementing the Perl6 VM in a version of romcc Me enhanced with a call/return stack as the only compromise toward the Me traditional VM ?? Eric I simply do not understand the question. Me To be frank, this is my situation; I am in an open school where my Me mentor has told me that I am way over my computer credits Eric I hope this is at the high school level or else your computer credits Eric have not sunk in well at all. Me I meant to use romcc in a context separate from LinuxBIOS. Me It would be a custom compiler for Parrot itself, running with RAM, where Me CPU register style of Parrot would match the register reliance of Parrot Me -- with the one added call/return stack that you mentioned. Eric O.k. that makes more sense. I have strong reservations about adding a Eric call/return stack. But a port to the parrot VM without that should Eric be doable. Eric's romcc basics Currently LinuxBIOS has a lot of assembly code simply because memory initialization is difficult in the general case. This code cannot be written with a standard compiler because there is no memory to put a stack in. Nor on x86 are there cache blocks that can be locked into place. As code generated with romcc does not use a stack it can be used during memory initialization. It is true romcc is not *done*, it is quite usable at this point. In the freebios2 I have been gradually making the primary API ones that can be used before memory is initialized. The biggest difference is that if you want to return multiple values instead of passing in the address of a variable the a multi valued structure must be returned. The biggest current known bug is that if you have a small type like short when it is stored in a register nothing ensures it does not take on a larger value than will fit in a short. unsigned short i; i = 65535; i = i + 1; /* i == 65536 oops */ The biggest shortcoming comes from it's nature and I have used it enough at this point I don't want to live without it again. = CXN, Inc. Contact: [EMAIL PROTECTED] President, The Linux Society http://groups.yahoo.com/group/linux-society linux society distro - http://www.thinman.com/eLSD/readme ThinMan is a registered trademark of CXN, Inc __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Adoption ??: Rare Salt-Water Camel May Be Separate Species
http://news.bbc.co.uk/hi/english/sci/tech/newsid_1156000/1156212.stm This nuclear/dynamite stuff is making me sad. Wanna contribute in the name of perl ?? Lets see... China + UN = $perl_revenue
Re: We should have some YAPC talks on Perl 6
Giving talks at YAPC is a no brainer, and I see the criteria of creating public documents and the existance of a deadline being exceeding good things. Documenting the knowlege and preventing the authors from obfuscating the documents (by accident, of course) will generate far to much noise for the internals list to tolerate. Since we know we will need succeeding generations of internal gurus now is the time to develop the methodology of Perl education so that we dont have to go thru the pain of change later on. Its a karmic thing, there is no better language for documentation than perl. If perl.org is unacceptable for some reason I can easily create a mailing list on puny.vm.org John
Re: licensing issues
I am supporting regular GNU licensing to relieve the pain I am hearing about in the commercial zone where folks are allegedly up to NG. Also if we use the GNU license, then we dont have to worry about applications meant for perl being written in some other less appropriate language because of licensing issues. GNU Mailman comes to mind where the number of developers for this crucial groupware is drastically reduced by its being written in Python, not to mention being hamstringed by its string handling. Ruby, for instance really looks good, but we seem to yo-yo back no matter how many times because Perl really _is_ the only language. Also I want to vote to keep Perl Perl for the time being, both in the interperter and the rather than trying to compete w/ MS's Dot Net. We in operations industry really need a solid Perl more than any other single thing I can think of where Perl is highly appropriate as the back end for something like the DJ's TCPServer, basically eliminating the need for all other software here. my 0.02
Compilers, Corporate Interests and Design
Using IBM's choice of Linux and Apache as an example, the compiler is not theirs, it's GCC. Also, when I was doing support for biochemical and statistical modelling at Merck, the scientists choice was GCC over the HP native compiler. (porting GCC to HPUX was one of my responsibilities) Linux itself thrives as the least common denominator principle and its world market share will keep increasing-- base compiler GCC. MinGW GCC is coming along on the Win32 platform and this is where I plan to cut my teeth. Maybe this is where corporate involvement is most appropriate, they can patch the GCC-isms that dont meld w/ their own compilers. Perl gurus can instead concentrate on moving forward w/ the implementation. Bringing these huge companies on board w/ Perl as it is presently licensed may prevent the same kind of ugliness that errupted between Microsoft and Sun. By the time the dust settles, Java may not be worth fighting over, but Perl might ;) John
Re: Call for apprentice: was Re: Meta-design
I would like to do this, but I think its a bigger job than you imagine, and... "I tend towards insanity from time to time. Good thing its only perl." (you can quote me) (It comes from stresses developing sysadm apps around the single largest depository of human wealth. They actually smothered a pregnent woman to death here rather than open a fire door in a valult room, by way of example--- I really need a new contract.) There is a new group forming from milder NY mongers called Perl-Seminars organized by guinevere liberty [EMAIL PROTECTED] one of the few female mongers and someone who I put a lot of effort into bringing into the monsters, err mongers. I got really excited by the possibility of crossing over between Python, Blackdown Java, and Perl in terms of internal pieces. Maybe this is the place to start that process. That would make three layers: top-ten, really-experienced-VM-coders(kibbitzers), and the apprentices. I also think that an organization like Hewlett Packard would be a huge benefit because of their commitment to QA. John On Wed, 6 Dec 2000 17:05:30 +, Simon Cozens [EMAIL PROTECTED] wrote : On Wed, Dec 06, 2000 at 11:48:45AM +, Nicholas Clark wrote: (Is maintaining such a document an "apprentice" job? (see perl6-meta)) I'd certainly like someone to take on the maintainance of the document I posted last night, because I hope that one of its functions will be to explain to apprentices a little of some of the concepts that we're dealing with; I tried to do that in places, but it got late. So, anyone want to volunteer? What maintainance would involve would be, I think, receiving forwarded messages from perl6-internals-design (or whatever) with bits marked "We need to remember to think about this more!", and making sure those bits are covered on the meta-design, with an option on learning about the topic and writing a short summary for everyone to gain from. It would probably also need updating when we settle one of the issues on it, with a brief note on what was decided. Simon -- Putting heated bricks close to the news.admin.net-abuse.* groups. -- Megahal (trained on asr), 1998-11-06
Re: Guidelines for internals proposals and documentation
"David Grove" [EMAIL PROTECTED] wrote : But.. but... but... we don't even have a design spec. I mean, we don't even know for sure what Perl 6 is going to look like for certain, inside or outside. This is precisely why I proposed the BS level just below Development. In fact I'm going to write the MailMan make-a-list page right now or by monday. Maybe the somewheretostart :) is with design tools to build attributes and connectors for the components and then display them nightly w/ a graph representation of the whole complex structure. My second desire is to build perl6 purely w/ perl tools/servers, and then wholly with perl6 as soon as it can stand on its own. That way if there are any problems the core team would be the first to know about it ;) John
Re: Guidelines for internals proposals and documentation
Using the IBM article that Jarkko found as an example, core implementations of different languages may have more in common with each other than implemetations of the same language, I think PPC is actually significant enough so that it should not be painted into a perl-only corner. Seeing that the majority of the debate or confusion in PCC is at the germination level, I am proposing a more nebulous level... BS ( for brain storming ) which would precede development. It would be open enough to allow any developer (perl or no) to contirubute while hopefully spinning off the perl component into their own lang's direction. An example for this would be what I learned at the NYPC/LinuxSociety demo last night. In the 2.4 compile, you now use "make xconfigure" rather than "make configure". Its a TK app that makes the process more fun than work and it should be ported to every configure esp perl. On our side, there is notion in of eliminating "make" (a good idea IMHO) by updating the cons modules. It would then be a piece of cake for anyone on these lists to bring these two together, where the PPC would guide the feature set... (I'm just wondering how to do this in HTML/CPANTS ;) Anyone who wants can start a BS list w/ GNU/Mailman on http://puny.vm.com just email me an I will make a link;) John
Win32 Development Env
I have been using Cygwin, UWIN and now a ZSH tool set to create SSH1 access to servers from Win32 boxes. More recently, ports got closed between the Unix boxes yet we are able to access them all from our workstations. What this has meant for me is that I have to port all my monitoring, distribution, key management... various admin tools to an NT box. UWIN is a nobrainer for this, as Cygwin has various security and performance problems. However, for the purposes of Perl6 the third alternative comes to mind, MinGW, because UWIN has a proprietray DLL. ( also I just had crashes of UWIN when I tried use CPAN.pm, and support from David Korn (yes, of ksh fame) may be slow in coming.) MinGW uses only what bits of posix were tossed in by Microsoft to comply w/ federal law. I am emailing the UWIN list to clarify ( or further muddle ) the licensing issue, keep in mind this is ATT and I am waiting for an email back from Charles Northrup [EMAIL PROTECTED], a UWIN expert who regualarly compiles UWIN and GTk and the like. Have a nice weekend, John PS, there actually is interest in my ThinMan concept ( ok, mainly the URL ). How much should I ask ??
Re: Design
Wow! You're good! Thanks, can I quote you ?? However, the "marriage" part of your prediction is already *mostly* true... future Python... same vein as Lisp -- only the people who really grok Lisp can see it. I totally disagree with your last point though. Thats ok, Perl has stayed away from Microsoft bashing... ...and w/ great results. I for one, am in line for the perl/python studio stuff. My desire for a un-anchored "mini-perl" (meaning a Perl like /bin/sh ) is initially motivated by my desire to support these users. Perl is superior to everything else in that there is no bloat. My s/w model would join the tools to the data where plugins are libraries rather than applets (did I mention speed?). CPAN is able to install amazing computability quicker than, say, your average gif. Rather than fully automating CPAN, I would like to see servers share their own loaded modules as emitted objects. I still have to research the ethernet-cellphone crossover but you can see where I am going with this. (In the ether, no one knows your name, just your destination) I just really hope I can keep up w/ you guys, finally learn C, and come out the other end a testing guru. On Gates and Steve Case: Sometimes I think that Gates and Microsoft are not synonymous. Microsoft has been able to deliver popular products where the public domain has so far failed. Unlike most other billionaires, he has not ordered any hits, burned any homes, destroyed any forests, and you can be absolutely sure that most "opensource" companies would follow his foot steps in a heartbeat. Part of everything else I have mentioned is the inevitable digital TV crossover. The FTC would have it that all TVs be thrown away and replaced w/ 3000 X 1000 ultra wide HDTVs costing 2000 $US. Gates otoh, suggested just grafting VGA into the TV specturm, the guy understands peoples needs and a move in this direction would be significant in expanding global computing, 800X600 is what I use on my laptop and 640X480 is still basically usable. AOL, however, is not a new-economy company in any sense and Steve Case is probably a bigger liar than even the president. I have collected megabytes of testimony indicating that AOL is stealing the old fashioned way. but at least it's nice to know we're able to help people who use Microsoft systems. Yup, I like to build Unix kits for Win32 including VPNs, but to truly succeed I will need to start compiling w/ gcc on my NT box (argh!!) Maybe this will be a significant part of my future ;)
Re: Design, opps- govt foul up
FTC = FCC (= FDA = DEA = FBI = DOJ = DOA = CIA = Ma_FIA = ...)
Re: Design
once you've lost it, [ simplicity, that is ] it's never coming back How true, I'm not holding my breath for CGI.pm divesment. Simplicity to me as an integrator/admin means having set of binaries that can be recompiled, or preferably configed, into diverse implementations with uniform results. To this end the core could be invoked as an unanchored micro-perl (like shell), a mini-perl replacment, perfectly behaved for the thin applications world. In its simplest form it would be fed emitted bytecode evisioned in my RFC. It seems this microperl could also be embedded into other languages via whatever their version of XSUB is. Note the absence of PMs at this level. (no, not prime ministers or ny perl mongers ;) Traditional clients are the next step having all the above features, including location floatability and object receivablility, installing anywhere, loading pms through relative paths via env attrs or cli args. I'm thinking pre-compiled win32, trust me when I say ActiveState is bloating. Finally comes the full implementation, a mirror or subset of the CPANTS server, itself built from every single piece of perl ever presented for review. Well defined, it operates entirely in perl, happily harvesting pieces of itself for the multitude of workstation clients and embedded receivers. Here, a cgi-suite gives every browser in the world access to editors compilers and version control and pod-tools well beyond whatever CVS providesÂ… your take-home copy emits directly into your perl, if you are lucky enough to own one, otherwise you can live in CPANTS. It seems like a good idea to try and coordinate efforts with [ others ] like blackdown.org. As un-sexy as this sounds, I think there should be a subgroup of all ~free~ s/w developers who would specialize in low level modules and integration kits allowing all projects to benefit from each others' pain and frustration ( gotta love it ) I have been predicting for a year now that perl6 will spawn another language which will be a marriage of perl/python/scheme/sh, hopefully enabling a billion or so humans in defiance of AOL and Microsoft. (last rant, I swear ;) I'll get the list out soon, and we can get things going darned soon. Hey ho, lets go !! PS, below are all the design criteria, though my list is short. Did I say "testing" ?? parser optimizer bytecode runtime dispatcher (w/knowledge of dynaloading) data-types regex memory identify the units/modules map relationships between modules design the API for the modules code test cases for the API (circular process with the previous step?) code the API code the wrappers for the libraries (perl.c, etc) Robustness Portability Maintainability Testability Reusability Speed Simplicity Size Avoid copying. Avoid premature optimization. Be extensible. Be orthogonal. Orthogonal be. Be portable. Be scalable
Re: TIL redux (was Re: What will the Perl6 code name be?)
On 28 Oct 2000 08:06:57 +0200, Ariel Scolnicov [EMAIL PROTECTED] wrote : threaded code is so much slower; this can also be seen as an indictment of threaded code). Now I am really confused. This directly contradicts the Threaded Perl RFC. My instincts still tell me we need two perl core modules. 1) A complicated threaded server core designed for people who derive pleasure from syntatic gymnastics ( or those who need a fat emitter ;) 2) And a tiny engine that runs like like the wind, can be regressively tested for any critical (medical) distribution and shoehorns where only lisp has previously been. I would hope to see this internally controlling the majority of tiny receivers some day. Keep in mind all that the competition all fails in one or more categories. Java is too slow, python lags perl, C# will no doubt wind up in court... So, there is absolutely no reason why perl6 cant be everything to everybody, especially me and my recent obsession with big money.
Re: Threaded Perl bytecode (was: Re: stackless python)
This thread seems to be winding down fttb**, Judging from the below, perl multithreading [ I am guessing ] is simply syntatic sugar much the same as Koch C++ is a wrapper for regular cc compiler. This sounds nice, Threading Perl bytecode would be nice about 98% of the time, and should offer a speed increase. But from the operations industry perspective: idioms like: *main::localtime = \localtime_replacement; ~and~ if anything was overriden anywhere, no module code could be read in as bytecode, are issues esoteric enough to be avoided simply because of the cost of maintenance. Experience has also shown that an overdependance sophistication is a good way to wind up stranded waiting for a bugfix (I'm refering to financial ruin). If this is the case, the code underlying the treading would utilize normal functions to poll the concurrent event streams and programmers could choose between the threads and functions depending on their levels of comfort. This is good for my hypothetical remote sensing devices because the byte code interpreter would be single threaded, presumably smaller, and a lot easier to test. John ** like I'm going to tell you ;)
Re: RFC 334 (v1) I'm really trying to understand this...
If you get the chance, I would really grateful if you could translate the abstract into lay terms, just confused by the concept of "low level perl" Why??, perl is my only (byte) compiled language... ...I'm an admin. TIA ;)
Re: RFC 334 (v1) Ahhhh.. i get it
$thanks - (1000K)
Re: RFC 125 (v2) Components... Should Have... And Testing !!!
I'm an admin, perl saved my life... However, yesterday, some simple IO::Socket scripts failed to work on 5.6. I'm not addressing that here but my resulting thought is now that the distribution should only include such core components as are necessariy to define perl's behavior. Those should be kept short as sweet and there should be real-time testing at every stage of development. Otherwise we will lose our position as the mission critical control language. Oh yeah, there should also be as much ( if not more ) documentation as ( or than ) code as well, Cheers, John
Re: RFC 125 (v2) Components in the Perl Core Should Have Well-Defined APIs and Behavior
a design expressed in UML could be implemented in a non-OO language. Interesting concept... "expressing" perl in UML would certainly add depth to the artistic license ;) I think, though, that the core interface should be procedural. I agree. We should not confuse OOD with OOP. As in GNOME ?? John
Re: RFC 313 (v1) Perl 6 should support I18N and L10N
VMS must die! Hahahahaha !!!
Re: RFC 281 (v1) The Perl 6 Development Log
Not to sound too, a, whatever... but you rock, Get it started, make it available, and I will format it into a pleasant (interactive) web page, I promise !!! (thinking faq-omatic)
Threading Debate-- Where ??
I have personally agonized about the threading issue, basically w/o every writing a usable script in it. I would like to know where the archive is, its not really obvious, before comenting that we may need two cores, on with one w/o. cheers, john
Re: New Perl rewrite - embedded Perl
Tom Christiansen wrote: It [miniperl] isn't substantially smaller, so that does you no good. The socket library seems to be the poster child for what to leave out, but that's a weak argument ... it would make sense to design a miniperl that can dynamically load the "expensive" stuff. The world being what it is today, I dont think you can get away w/o communications. The loadable concept might work with industrial strenght and lite versions of the expensive somewhat exotic stuff, maybe in regexps. I like guile (and Scheme in general), but Perl isn't a minimalist language. Stealing from Scheme is good. Adopting Scheme's Small Is Beautiful philosophy I'm a big Schumacher fan, I'm not too sure how to take this ;) he would have loved our economic model :) I'm really entranced by the prospect of sending frozen structures including anonymous subs to to remote devices like out on Mars or Pittsburgh.
Re: RFC 210 (v1) How do I de-typo it ??
I really screwed this up, who has editable rights for the pages. ( .htaccess ?? )
Re: New Perl rewrite - embedded Perl
On Tue, 12 Sep 2000 20:35:32 -0400, Bennett Todd [EMAIL PROTECTED] wrote : I don't even want to embed the current perl in mutt; I'd love to have a scripting and extension language embedded in there, but not one that's bigger than all the rest of the application. A couple years ago I wrote a poem called: "If only emacs were written wholly in perl" since lost in the purple haze. The exact same design targets --- really really fast, teensy memory footprint --- that define the microcontroller embedded market, also define the entry to these roles on the biggest servers. I'm not sure what that means but I think I like it.
RFC 210 (v1) Data/Code Dumping and Freezing
=head1 TITLE Data/Binary Dumping and Freezing =head1 VERSION Maintainer: John van Vlaanderen Date: 12 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 210 Version: 1 Status: Developing =head1 ABSTRACT Allow Perl to create serialize both data and code from the core. =head1 DESCRIPTION The modules Storable and Data::Dumper should be combined to dump data as well as code in text, binary and network order binary form. =head1 IMPLEMENTATION The immediate need for this is to support unmanned remote devices and lightweight clients where listeners evoke frozen classes upon receiving them. Other implementation would allow kiosk browsers, for instance, to run any perl from a minimal plugin. =head1 REFERENCES A sample implementation in Java: http://websprocket.com/vmfoundry.html
