jpegqs

3x memory access then, because read+read+write. And extra 0 to 3 reads in this work.

3 If the low bit on any operand is set, remove it, and replace that operand with m[operand] i.e., a dereference of that address

This dereference option makes a second instruction, this is not OISC.

Open the link: https://www.ioccc.org/2024/kurdyukov3/ogvm.html

Replace the text to the right of the Start button with: doomp.bin

Click the Start button.

Doom will launch in your browser.

I think not. There is not only Tetris, but also Snake, and two types of "shooters" - one removes blocks, the other creates. And many variations of these four basic games.

Sadly, the Brick Game model from which the ROM dump was taken doesn't contain a racing game, which was in the Brick Game that I had as a child.

Does it count as a screenshot?

Game select screen:

       HI-SCORE              0
         
 /--------------------\
 |                    |
 |                    | NEXT
 |                    |
 |      [][][]        |
 |    []      []      |
 |    []      []      |
 |    []      []      |
 |    []      []      | SPEED  0
 |    []      []      |
 |      [][][]        | LEVEL 12
 |                    |
 |    [][][][][]      |
 |    []              |
 |    [][][][]        |  ROTATE
 |            []      |
 |            []      |    -->
 |    []      []      |
 |      [][][]        |
 |                    |
 |                    |
 \--------------------/

          SCORE            1000
 
 /--------------------\
 |                    |
 |                    | NEXT
 |                    |
 |                    | []      
 |            [][]    | [][]    
 |            [][]    |   []    
 |                    |
 |                    | SPEED  0
 |                    |
 |                    | LEVEL  0
 |                    |
 |[][]                |
 |[][]  []            |
 |[][][][]            |  ROTATE
 |[][][][]  []  [][][]|
 |[][][][][][]  [][]  |    -->
 |[][][][][]    [][][]|
 |[][][][][][]  [][][]|  PAUSE
 |[][][][][][][]  [][]|
 |[][][][][][]  [][][]|         
 \--------------------/

I wanted to run Doom on one of them. So far I have LCD control for SC6531E (with 9306 LCD panel), USB control for SC6531E/SC6531DA and USB control for MT6260/MT6261 (using API from bootloader).

I load the code not while the OS is running, but through boot via USB.

SC6531DA is similar to SC6531E, but some constants have been changed, so additional research into its firmware is required.

I have enough knowledge to run some game on the SC6531E, but a lot of work still needs to be done.

Anyone want to cooperate with me?

From the ones I got, I found MAUI in the name of the firmware, and on Wikipedia I found these notes:

MAUI, a feature-phone operating system used with MediaTek-based shanzhai devices, also used on Motorola phones and some Samsung feature phones.

MediaTek developed an embedded operating system named MAUI Runtime Environment which is based on Nucleus RTOS.

So it's not raw Nucleus.

I don't know if the Mediatek chips have overridable pins, but the Spreadtrum does. There are also different LCD panels that have slightly different interfaces for which you will need to write a driver (and find it from the original firmware). The button mapping also may vary.

So writing firmware that will work on most phones on a particular chipset will not be so easy.

I recently ordered and researched the cheapest feature phones (and some smartwatches), looks like half of that market is occupied by Unisoc with the SC6531(E/DA) chipset (from the Spreadtrum company they bought). It uses Mocor OS. The second half of this market is occupied by Mediatek MT6260/MT6261 chipsets. I wrote tools to run my code on these chipsets.

There are also phones on Mocor5 OS, a little more expensive, it's actually Android 4.4 on the Spreadtrum SC7715 chipset.

I didn't find any Java here, but these CPUs have a Jazelle ARM extension to run Java bytecode.

P.S.: There's an old project based on reverse engineered MT6260 firmware: https://github.com/xobs/fernly

Explanation:

1. There are no data members inside X, in this case the size of the structure is 1 byte.

2. main() does nothing.

3. *x = new X[100]() - this requests a new array of 100 elements of type X, at a stage before main() is called.

4. The new[] operator is overloaded in the class, this operator must return the address for the requested array. It returns the address of the empty string object plus 1.

5. For each of the 100 elements, the X() constructor is called, the "this" address for those elements will be the value returned by new[] plus an index from 0 to 99. The X() constructor converts this to a number from 1 to 100 by subtracting the address of the empty string. This is the only UB here, but it works in all major modern compilers since they combine the same strings into one instance.

I have suggested them to look at my version, but I think UPX not much hardcore for that. Because I'm guessing decompression speed is more important to UPX than the extra 2kb.

I looked at the latest version of UPX, they began to use LZMA, if this is considered an LZMA decoder:

https://github.com/upx/upx/blob/devel/src/stub/src/arch/amd6...

Then it takes ~2500 bytes, mine is ~500 (static version). But the decompression speed for larger code should be higher, as I noticed.

The compression method in UPX is much simpler (therefore smaller and faster), but the last time I saw it was over 10 years ago, something may have changed. But LZMA should provide better compression.

I want to make the decoder small enough to be used in compressed executables. Where decompression performance doesn't matter because LZMA is far from fast decompression, and small code without inlining makes it worse (but bearable).

Still can't improve this stage of encoding, it requires a lot of operations. Maybe there is something trivial, but I don't see it.

Great description, but there is a typo in the second row:

    00000000 abcdefgh ijklmnop qrstuvwx
    -------- -------- -------- --------
    00abcdef 00ijklgh 00qrmnop 00stuvwx
    0000ijkl 0000qr00 0000gh00 00mnop00 <-- missing "qr"
    000000qr 00000000 00000000 00gh0000

I know that. My approach is different: instead of finding the fastest solution to deal with the existing base64 standard, I modify the standard to make it easier to decode. (There are cases when it isn't necessary to follow the standard.)

Is the rest of the table[1] unchanged?

The rest is unchanged, but there is a trick in that the table indexes are shuffled, and shuffled differently depending on the neighboring values in a 24-bit block of source data.

but I have had to decode a ton of 64-bit base64 strings, for example

Should be good for small data. It's a pity that no one (or I haven't seen such benchmarks) measures the performance of decoding a large amount of small data (like 1..64 bytes).

Memory bandwidth is the limit, so you can't make it faster than memcpy(). However, copying memory is still faster than these algorithms, аnd it's complicated to make the conversion speed closer to the speed of copying memory.

but two ternaries become a branch

I need to use inline assembly because of this.

So far I've got these results:

   Allwinner H616 (Cortex-A53) 64-bit mode
   
   linux-5.15.7.tar.xz : 25.12 --> 24.43 (+3%)
   linux-firmware-20211027.tar.xz : 22.80 --> 21.63 (+5%)

Update: It looks like I need to use inline assembly for AArch64 or GCC where it can make two CSEL instructions from the same condition - replaces them with if-else branch.

And I got better results (below) than when tried to avoid this compiler behavior but didn't use inline assembly (results above).

    linux-5.15.7.tar.xz : 25.12 --> 23.85 (+5%)
    linux-firmware-20211027.tar.xz : 22.80 --> 21.10 (+8%)

Cool, but it doesn't generate SBB in real code, but instead gives me something like this:

    xorl %r11d, %r11d
    cmpl %r12d, %eax
    seta %r11b

    tmp = rc.code < rc_bound ? ~0 : 0;
    if (rc.code < rc_bound) rc.range = rc_bound;

Thus, inline assembly is the only option so far to prevent the compiler from doing something dumb.

I tried it and realized that predicated instructions are removed from aarch64, which I was not aware of (because I rarely work with ARM). That sucks. But I'll try to do it without them.

Can be done, ARM has better support for predicated instructions. May be done without using inline assembly.

But I guess ARM CPUs can also have a smaller branch penalty, which means less speedup from such a patch.

You can try it by replacing the inline assembly with the commented code above it (also don't forget to remove i386 and x86_64 from #if). (Although the code could be rewritten a bit to help the compiler make better binary code for ARM.)

It would be great to have builtin for CMOV. But I also want GCC to utilize the hack with the SBB instruction when I write something like:

(unsigned)a < (unsigned)b ? ~0 : 0

Instead of three instructions what it generates.

LZMA compression (used in 7-zip, XZ, LZMA2) is known as one of the best, but it has a noticeable drawback - it's slow. I tried to improve the decompression speed by removing excessive branching at decoding of every bit from the compressed data.

Decompression speedup from this patch largely depends on the compression ratio, more ratio - less speedup. Compressed text, such as source code, gives the least speedup.

That's the result from my Skylake, compiled with GCC. Please help me with testing on different x86 CPUs.

x86 (32-bit) - should work, but haven't tested yet. Compiled with Clang should work as well.

I'm porting Linux packages that compile for GCC/Clang to an EDG frontend based compiler and I need to remove forced -Werror from build scripts because different compilers have different warnings (and even false warnings due to compiler bugs). So what I want to say to people who force -Werror by default is that your software is no longer portable. Do not do this.

I made a windows port on github, you can try exploit that.

".//machine:foo/bar/baz" - will it work if the dot is added at the beginning?

And now it compiles on Windows, at least with Msys2. I'm updating the code on github.

It won't be a problem in this code because "%" is not handled. But could be a vulnerability for more implemented HTTP servers, and a few days ago I got this idea too.