mras0

There already exist cross-compilers (e.g. http://sun.hasenbraten.de/vbcc/ and various amiga-gcc versions). vAmos is more for the case where you want to use an Amiga-native compiler (say SAS/C http://pjhutchison.org/tutorial/sas_c.html) but work on Linux/Windows.

Amiga Forever is a distribution of software (Amiga ROMs and OS disks) and a full system emulator: CPU, custom chips (graphics/sound/..) etc. It allows you to emulate various Amiga systems completely.

vAmos is just CPU and an embedded ROM/OS replacement that does just enough to run (some) AmigaOS command line programs. The primary use case is for cross-development (running Amiga compilers/tools, testing simple stuff, etc.) without having to boot a full system emulator for each command and better integration with e.g. host-side Makefiles.

With the vAmos=WINE analogy, Amiga Forever=VirtualBox/VMWare.

Size optimizing assembly code finds use in a variety of places. Demoscene for size constrained things is one of them, but also "hacking"/exploits and of course "whitehat" stuff (patches / compiler optimization etc).

I understand what you're getting at, but in this case even I (who know what most things on that page means) struggle to understand why it was submitted. Are we looking for the 0E opcode? New optimization opportunities?

Genuinely asking, for this post did you click on the link and say "yeah, I got the point" or did you involve an LLM? If you did, what did you ask it? I'm asking because I want to get better at LLM use (Another example post (and prompt) where you've used this, that's also fine)!

The link is to an opcode map with strange abbreviations with no apparent explanation. Asking "What am I looking at?" without doing any research (with a LLM or otherwise) is entirely reasonable.

Not sure why you're being downvoted. You need a to know quite a bit of esoteric knowledge to parse this beyond knowing x86 opcodes (even x86 assembly).

It's more or less the same information you get from the intel manuals (specifically appendix 2A of https://www.intel.com/content/www/us/en/developer/articles/t...). There you can also see what e.g. "Jb" means (a byte sized immediate following the instruction that specifies a sign-extended relative offset to the instruction).

One-byte opcodes here differs from 2 byte opcodes (386+ IIRC) prefixed by a 0F byte and even more convoluted stuff added later.

No, it's due to the construction of bcrypt - it ends up using the password more or less directly as the key for blowfish (the underlying cipher) which is why the limit is there. Check wikipedia for details.

bcrypt is based on the blowfish cipher which "only" support keys up to 576 bits (72 bytes) in length (actually only 448 bits as spec'ed). Wikipedia has all the details.

> moduli generated by OpenSSL will always have the high bit set

Correct for 1024, but...

    openssl genrsa 1023 | openssl rsa -text -noout

:)

Also just noticed that openssl rsa actually has a -modulus switch so you can make do with "cut -b9-"

The standard format for RSA private keys is ASN.1 (https://www.rfc-editor.org/rfc/rfc8017#appendix-C) with the components encoded as INTEGERs. An INTEGER is always signed in ASN.1, so you need the leading 0 byte if the MSB of your positive number is set.

OpenSSL is just dumping the raw bytes comprising the value. Tools that don't show a leading zero in this case are doing a bit more interpretation (or just treating it as an unsigned value) to show you the number you expect.

Not really the ethos of C(++), though of course this particular bug would be easily caught by running a debug build (even 20 years ago). However, this being a game "true" debug builds were probably too slow to be usable. That was at least my experience doing gamedev in that timeframe. Then again code holding up for 20 years in that line of biz is more than sufficient anyway :)

Good luck! As the sibling comment mentions, Asm-Pro is IMO a good choice these though it requires KSv2+ (so you can't use it on an stock A500). I mostly use vasm for "larger" stuff though (http://sun.hasenbraten.de/vasm/) and cross-compile (though it can run on Amiga as well) / test in an emulator.

For a quick test/code loop nothing beats the Asm-* family - remember to save often and make backups though :)

Update: a1=-1 is a bad choice of test value (0 is much better), as it won't show the issue if present! However, it doesn't change the outcome of the test on 060, but I would have noticed that 020 is affected as well (as also mentioned in the comments to the article).

Rev5 "full" 060 (not EC/LC). Quick capture of crappy methodology: https://imgur.com/a/XwQ1Tnp (PCR with revision number is in d0)

Have an Amiga w/ 060, and that instruction doesn't seem to modify any A registers. (Only did a very quick test of those exact instruction words)

Thanks, understand what you mean. I probably botched the 1/4 probability thing, was thinking 4^-60 gives 2^-120 bit assurance (roughly, security margin in my mind), and an extra round would quadruple it, but doesn't work that way I realize.

Thanks for the reply (and it definitely answers my original question). For both short-lived keys, and where production time matters it makes perfect sense. I was mostly thinking about the scenario where you're generating a key for e.g. a long-lived certificate (maybe even a CA) or high-stakes PGP stuff. Just seems like you'd want spend a few more seconds in that case.

I don't pretend to understand all the involved math, but what I'm trying to say is that as far as I understand T rounds gives 4^-T probability that we've chosen a "bad" prime (really composite) per normal Miller-Rabin in the worst case. Doing ~5 rounds has been shown to be enough to choose a good prime candidate, under most (very probable!) conditions when we get it a random, and thus the argument is that that ~5 rounds is fine. We agree so far?

I'm just asking, why not run the conservative 60 round test, rather than ~5 when you're doing a very rare, one time, key generation? I understand that it's very unlikely to reject any numbers, but at least BSI thinks it's worth it for important keys.

If I understand the recommendation right, you wouldn't do 60 for a 2048 bit key and then 120 for 4096, rather 61 rounds would be enough for 4096 if 120 is alright for 2048.

The BSI recommendation I linked says 60 times here (considering the worst case and the security level they're targeting). Just wondering why we'd want to do less for a (presumably rare) one-time operation.

I happened to look at this recently, and while I understand the argument (but not the math) of having to do fewer Miller-Rabain rounds, why would you do so in PRACTICAL settings? Unlike ECC you're likely only generating long term keys, so shorter key generation time seems like a bad tradeoff. Composite candidates are going to be rejected early, so you're (with high probability) not doing expensive calculations for most candidates. My reading of [BSI B.5.2](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...) confirms this.

Of course random bit flips could interfere, but other measures should thwart this in high-stakes environments (at least to some degree).

Great article and analysis as always, thanks! Somewhat crazy to remember that a (as you argue) minor CPU erretum made world wide headlines. So many worse ones out there (like you mention from Intel) but others as well, that are completely forgotten.

For the Pentium, I'm curious about the FPU value stack (or whatever the correct term is) rework they did. It's been a long time, but didn't they do some kind of early "register renaming" thing that had you had to manually manage doing careful fxchg's?

Thing is that isn't a single unified Amiga community with a clear goal. Roughly speaking you have people who (like this project) want to keep the "OS/UI experience" and move that forward to newer architectures and build new stuff for that (PPC was the main target for a long time), and what you call diehard retrocomputing people who are more closely tied to the hardware used back in the day - M68K and custom chipset (or at least the "period correct" HW extensions made possible by original Commodore made machines).

I'm probably mostly in the latter camp, but still appreciate efforts like this. It's not a rational thing, but more about "reliving the past" but with more skills/money/available software. Like classic cars or whatever, where you know you could have a better overall experience with a newer car, but you want to tinker on the old one (where maybe you now got the upgrade model you yearned for back in the day).

Simplified: Traditional SIM card is "smart" card with a chip (exactly like modern credit cards) from your network operator that gives access to mobile network(s). The chip has software + data that allows this.

eSIM: same (or similar) chip is soldered into your phone. Software is different, and allows storing the data part from multiple operators at the same time. You use your phone to switch between operators and add/remove potential operators (add part is over the internet via your phone, either via wifi or current active operator).

By way of analogy you can download new "SIM cards" to your esIM, switch between them, delete them etc. It's a feature of your phone, either it supports eSIM (has such a chip and supporting software on the phone) or it doesn't. You can't add it later.

Once the drive is spinning that doesn't matter though. Floppies are slow by modern standards mostly because you only get a new (decoded) bit around every 2nd (or for DD drives 4th) microsecond, and the drive takes some time stepping to the next cylinder (track).

The addressing modes do exist on 68020+ (https://www.nxp.com/files-static/archives/doc/ref_manual/M68... section 2.2), but I don't think any compiler will generate them (even with -mcpu=68020) as I think they're not actually faster than doing it the normal way (even if that costs a register), maybe slower, but I'd have to check the cycle counts.

EDIT: Yeah, so if I'm not misreading MC68020UM the memory indirect mode is slower

   move.l #3,([6,a0,d0.l*8],4) ; 9 cycles best case

vs.

    move.l 6(a0,d0.l*8),a0 ;4
    move.l #3,4(a0) ; 3

Only supported on 68020+ though, but yeah think it would be something like move.l #3,([6,a0,d0.l*8],4) (scale only goes up to 8 though)

One thing to consider is that the compiler can't simply replace a division by just a right shift for signed variables (it will round towards -inf for negative numbers), so even today there's a tiny bit of benefit of explicitly using shifts if you know that the number can't be negative (and the compiler can't prove it) or you don't care about the rounding (https://godbolt.org/z/vTzYYxqz9).

Of course that tiny bit of extra work is usually negligible, but might explain why the idiom has stuck around longer than you might otherwise expect.

Yeah, and I seem to recall reading an article about some of the good old tricks (think it was about the Aladdin game?), but unfortunately I can't seem to find it now. Doing the dithering (by hand) just right would give a good effect in practice. Things made for real higher resolution monitors looked bad on lowres CRTs though (with very distinct scanline effects) as I recall like the menubar in my screen cap, even at a distance.

14" 1994 vintage Microvitec. Very popular monitor for Amiga systems because it supports 15KHz horizontal refresh rate modes (PAL/NTSC TV standard - for games/demos) up to 31KHz+ (VGA) for nice flicker free 640x480 60Hz display ("productivity") modes for serious stuff.

Guess it depends. I haven't had a CRT TV for many years, but I have an old multisync CRT monitor and I can clearly see the individual raster lines (close up of 320x200 progressive scan: https://i.imgur.com/Osc4ZMm.jpeg). At normal viewing distances it's not noticeable though.