Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!nerds-end From: Uli Kusterer Newsgroups: comp.compilers Subject: Re: generating bytecode, was Good practical language and OS agnostic text? Date: Sun, 22 Apr 2012 13:12:25 +0200 Organization: Compilers Central Lines: 37 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-04-065@comp.compilers> References: <12-04-019@comp.compilers> <12-04-056@comp.compilers> <12-04-060@comp.compilers> <4D79ECD8-A457-4995-9D38-66A3C14C51FB@googlemail.com> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1335104929 16764 64.57.183.58 (22 Apr 2012 14:28:49 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 22 Apr 2012 14:28:49 +0000 (UTC) Keywords: code, design Posted-Date: 22 Apr 2012 10:28:49 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:608 On 22.04.2012, at 12:53, Uli Kusterer wrote: > Fully agreed. Hence the suggestion to generate bytecode first. But of course, if you plan to make an actual native code compiler, pointers in that direction don't necessarily hurt. Huh. Just realized I never actually *wrote* that suggestion, it seems. So I guess I should re-qualify that as: Yes, I agree, it is actually a good idea to start with a simple bytecode interpreter first and to compile against that, before you try to generate your own assembler. It may look like more work, but it lets you get one module working before you have to figure out the other one. Thanks for pointing that out, BGB. While we're on things I wrote that are missing something I wanted to say: > I build a bytecode, with an index into an instruction array and two param fields. I thought about generating CALL instructions instead, but it's easier to debug this way, and subroutines in my language all have a variable number of parameters, so I thought the advantage of avoiding one function pointer dereference probably won't gain me much. And I'm still in the "get this dang thing working" phase, after all. Another reason I'm doing the bytecode is that I'm hoping I can eventually just save that to disk. I would love to get this thing running on iOS eventually, and having files contain compiled x86 code in them wouldn't go over too well on that ARM CPU :-) Also, if I save byte code (right now I save source code) would be a slight added level of obfuscation for people who want to ship their programs commercially (compared to aforementioned source code), and the ability to make sure only instructions I consider "safe" can actually be used. Cheers, -- Uli Kusterer http://stacksmith.org