Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Newsgroups: comp.compilers Subject: Re: Is This a Dumb Idea? paralellizing byte codes Date: Sat, 29 Oct 2022 09:06:38 GMT Organization: Institut fuer Computersprachen, Technische Universitaet Wien Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-10-063@comp.compilers> References: <22-10-046@comp.compilers> <22-10-060@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="24823"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, architecture Posted-Date: 30 Oct 2022 00:51:06 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:3233 gah4 writes: >Seems to me it is not that parallelizing byte codes that is >a dumb idea, but byte codes themselves are. > >This was known when Alpha replaced VAX. Work on making faster VAX >systems was stuck with the byte oriented instruction stream which was >impossible to pipeline. Pipelined VAX implementation exist, e.g. the VAX 8800 and NVAX. AMD64 is also a byte-granularity instruction set. While byte granularity makes wide decoders more expensive (by roughly a factor of 4 compared to an instruction set with 32-bit granularity for the same number of decoded bytes). RISC-V's compressed (C) instructions have 16-bit granularity, so at least the RISC-V designers think that the benefits of instruction compression outweigh the costs in decoding. Anyway, this has little to do with the question of the original poster. Virtual machines (often called byte codes, even if they use a different instruction granularity) use instruction sets that are quite different from that of VAX or AMD64; in particular, they have no "instruction formats" with "addressing modes", where every base instruction can be combined with a set of addressing modes in an orthogonal way. That's because they are not decoded like hardware instructions. There are, however, costs to byte granularity in VM interpreters: * Byte granularity makes it harder to use direct-threaded code and optimizations that start with that, in particular dynamic superinstructions: You cannot rewrite the VM code into direct-threaded code in-place, but have to translate it to another place, which also means that you cannot reuse the branch targets as-is. * Also, if the VM instruction has an inline argument wider than one byte, the access to that argument can be significantly more expensive on architectures with alignment restrictions (e.g., ironically, SPARC). But alignment restrictions have died out in general-purpose computers, and VM interpreters are not that popular on embedded systems. - anton -- M. Anton Ertl anton@mips.complang.tuwien.ac.at http://www.complang.tuwien.ac.at/anton/