Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #118780

Re: Almost Ready to Repeat the Cycle

Show all headers | View raw

On 10/22/2026 11:47 AM, Anton Ertl wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>> BGB <cr88192@gmail.com> posted:
>>> At some level of feature cost, it may become preferable to emulate a
>>> feature, or maybe the whole ISA, rather than invest the cost in native
>>> hardware support.
>>
>> Worked great for Transmeta ...
> 
> That may have to do with the target that they translated to.  Intel
> and HP could not get this architecture style to perform well on
> general-purpose programs even when targeting it directly, so why
> should it perform well with a dynamic binary translator?
> 

I am not sure, I think Transmeta was using a fixed wide-issue VLIW as 
their underlying ISA. Hard to make this work well even in the best of 
times...


> OTOH, it seems to work ok for Apple with Rosetta.
> 

Yes.

ARM64 works well here.


There also seems to be some interest in the RISC-V space for dynamic 
translation of x86 to RISC-V; though emulating x86 on RISC-V is likely 
to lead to a not exactly small number of things that are difficult to 
emulate efficiently (EFLAGS being almost kinda evil in some ways; and 
then on an ISA that is in some ways rather poorly equipped to try to 
fake it).

For x86 emulation attempts in the past, the best option I had found was 
basically to have the emulator look forwards in the instruction stream 
and infer cases where any EFLAGS updates would be rendered irrelevant by 
subsequent instructions and then prune them away.


Though, any efforts to write an x86 emulation layer on top of my ISA 
have fizzled, mostly as the target is already not very fast, so an x86 
emulation layer would effectively be too slow to do anything useful with 
it even if the translation is itself reasonably good.

Well, and there is relatively little I would want to run that:
   I don't already have source code for;
   That I could redistribute without legal risk.

Like, for example, I probably could write an effective NES emulator on 
top of TestKern and similar, but then "The Big N" is very protective of 
their IP and prone to basically go after anyone who shares any ROMs and 
sometimes tries to go after the emulators themselves.

In theory, wouldn't be as bad in the Genesis/MegaDrive space, but the 
same underlying legal issues remain.

...


The other intermediate (and in some ways harder) option being to blend 
natively running code with emulating parts of the ISA which don't exist 
or are not directly usable.

Say, for example, running code in userland and then trying to make it 
look like it is bare HW while trying to limit emulation overhead.

Or, trying to fake RV-V on top of a simpler SIMD implementation.

This can create new issues that don't exist in full emulation.




Otherwise, in other news:
Now finished playing through Riven, in around 5 hours of total gameplay 
time. Still feels as if I had probably played it before. The only time 
something really felt particularly new/unexpected was at the final end 
of the game realizing I was being railroaded into needing to go straight 
to the end (to ram a telescope through the window which plays the ending 
cutscene / ends the game).

Took around 2 hours for this final stretch, but this is where the game 
makes a sort of phase transition from "go around and click various 
things" to "stop and watch a big chunk of cutscenes".

Or, seeming progression (sessions):
   1 hr: Wander around, open up 2 of the domes;
   2 hr: Do most of the puzzles and areas, open the various domes, ...
     Stopped here: Realized that all that was left was ending stuff.
   2 hr:
     Do animal puzzle, get trap-book back;
     Do colored marble puzzle;
     Visit and trap villain;
     Go and free the trapped lady;
     Finish the game, noting the game had taken away all other options.
       Went looking for ways back off the temple island,
         all seemingly blocked.

Ran into some minor issues, mostly random minor things.
   Animal puzzle:
     Initially conflated the fish and 'whark' in my mind;
       The latter being... also a big fish...
     Selected the wrong frog symbol at first;
       Well, it is frog from side-view, not frog from top view.
       But, when freed from the trap, is seen from top view, so...
         And the order spheres are based on sound.
     ...
   Marble puzzle:
     Failed to realize the white thing under the switch was a button;
       Visually had interpreted it as a white indicator light.
   ...




Also came up with a new entropy coding scheme (that I am calling AdSkew 
for now) that slightly beats out AdRice in some of the use-cases I had 
previously used AdRice for (both better compression and also slightly 
faster to decode).

Doesn't "replace" Huffman though, as AdSkew and Huffman exist in 
different use-cases (and STF+AdSkew was intended fairly specifically to 
address some weak points of STF+AdRice; both typically applied to small 
buffer use-case cases).

Whereas, Huffman is a better fit for medium-to-large buffers (well, say, 
one needing at least a few kB mostly to offset the constant-sized cost 
of the tables and the setup cost of the table initialization).


Could do a longer description, but the core idea (of AdSkew) is probably 
obvious enough from an encoding table:

Skew=0: (All symbols 8-bit)
      xxxxxxx0  00..7F (8, FrSkew++)
      xxxxxxx1  80..FF (8, FrSkew--)
Skew=1:
       xxxxxx0  00..3F (7, FrSkew++)
      xxxxxx01  40..7F (8, FrSkew--)
     xxxxxxx11  80..FF (9, FrSkew--)
Skew=2:
        xxxxx0  00..1F ( 6, FrSkew++)
       xxxxx01  20..3F ( 7, FrSkew--)
     xxxxxx011  40..7F ( 9, FrSkew--)
    xxxxxxx111  80..FF (10, FrSkew--)
Skew=3:
         xxxx0  00..0F ( 5, FrSkew++)
        xxxx01  10..1F ( 6, FrSkew--)
      xxxxx011  20..3F ( 8, FrSkew--)
    xxxxxx0111  40..7F (10, FrSkew--)
   xxxxxxx1111  80..FF (11, FrSkew--)
Skew=4:
          xxx0  00..07 ( 4, FrSkew++)
         xxx01  08..0F ( 5, FrSkew--)
       xxxx011  10..1F ( 7, FrSkew--)
     xxxxx0111  20..3F ( 9, FrSkew--)
   xxxxxx01111  40..7F (11, FrSkew--)
  xxxxxxx11111  80..FF (12, FrSkew--)

As noted, used in combination with an STF (Swap Towards Front) symbol 
reordering transform (with the STF table starting with all of the 
symbols in their normal ordering).

The Skew parameter is mostly an adaptive value for how steep the table 
is based on previously encoded symbol indices.

Experimentally, ended up with a 1/8 fractional step, as this seemed to 
give the best results in this case.


Partly, with both this and the STF, it is a thing of basically balancing 
adaptation rate with stability:
Adaptation rate too slow, fails to give usable compression within a 
reasonable number of symbols;
Adaptation rate too fast, results are noisy and the noise reduces 
effectiveness.


For now I was using it in my RP2 STF post-compressor as an alternative 
to AdRice, but could also be applicable to my UPIC image format (which 
uses a very similar entropy coding stage).

...

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-18 18:39 +0000
  Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-18 18:47 +0000
    Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-18 22:00 +0000
      Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-20 17:12 +0000
  Re: Almost Ready to Repeat the Cycle jgd@cix.co.uk (John Dallman) - 2026-10-20 20:21 +0100
    Re: Almost Ready to Repeat the Cycle BGB <cr88192@gmail.com> - 2026-10-21 15:28 -0500
      Re: Almost Ready to Repeat the Cycle John Levine <johnl@taugh.com> - 2026-10-22 04:52 +0000
        Re: Almost Ready to Repeat the Cycle Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-22 23:42 +0100
      Re: Almost Ready to Repeat the Cycle MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-22 16:10 +0000
        Re: Almost Ready to Repeat the Cycle anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-22 16:47 +0000
          Re: Almost Ready to Repeat the Cycle BGB <cr88192@gmail.com> - 2026-10-22 20:23 -0500
            Binary translation (was: Almost Ready to Repeat the Cycle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 07:55 +0000
              Re: Binary translation BGB <cr88192@gmail.com> - 2026-10-23 03:50 -0500
                Re: Binary translation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 16:21 +0000
                Re: Binary translation jgd@cix.co.uk (John Dallman) - 2026-10-23 23:51 +0100
              Re: Binary translation antispam@fricas.org (Waldek Hebisch) - 2026-10-25 00:10 +0000
                Re: Binary translation aph@littlepinkcloud.invalid - 2026-10-25 19:49 +0000
          Re: Almost Ready to Repeat the Cycle Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-22 15:45 -0400
            Binary translation (was: Almost Ready to Repeat the Cycle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 08:13 +0000
              Re: Binary translation (was: Almost Ready to Repeat the Cycle) Michael S <already5chosen@yahoo.com> - 2026-10-23 12:24 +0300
                Re: Binary translation (was: Almost Ready to Repeat the Cycle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 16:41 +0000
              Re: Binary translation (was: Almost Ready to Repeat the Cycle) jgd@cix.co.uk (John Dallman) - 2026-10-23 23:51 +0100
            Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-23 14:53 +0000
              Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-23 15:08 +0000
          Re: Almost Ready to Repeat the Cycle jgd@cix.co.uk (John Dallman) - 2026-10-23 17:22 +0100
            Re: Almost Ready to Repeat the Cycle anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 21:20 +0000

csiph-web