2026-07-18 00:00:08 <tabemann    > yes
2026-07-18 00:00:18 <xentrac     > I guess mental retardation imaging would not be very plausible
2026-07-18 00:00:30 <xentrac     > the others are likely
2026-07-18 00:00:44 <xentrac     > the others are likely possible, I mean
2026-07-18 00:00:45 <tabemann    > "MR" in biomedical computing normally means "magnetic resonance"
2026-07-18 00:00:48 <xentrac     > right
2026-07-18 00:00:56 <xentrac     > I've just never worked in biomedical computing
2026-07-18 00:01:03 <xentrac     > so I have to ask stupid questions
2026-07-18 00:03:00 <tabemann    > "NMR" is chemical engineering computing terminology, and while they use fundamentally the same physical principles as we do, the object of what they do is very different (e.g. detecting the configuration of labeled isotopes in chemical structures)
2026-07-18 00:03:26 <tabemann    > we used to call it "NMR" too but the marketing people thought that idiots in the public were too scared of the word "nuclear"
2026-07-18 00:04:00 <xentrac     > yes, exactly ;)
2026-07-18 00:04:31 <tabemann    > as if being stuck in a magnet and bombarded with radio waves would make you radioactive or something
2026-07-18 00:05:10 <xentrac     > Berkeley, California, has signs up declaring it a "nuclear-free zone"
2026-07-18 00:06:34 <tabemann    > I'm a big skeptic of the "anti-nuclear" crowd -- practically all nuclear/radioisotope accidents have resulted from deep human stupidity and not any kind of fundamental lack of safety of nuclear technologies
2026-07-18 00:10:26 <xentrac     > signs saying "nuclear-free zone" seem like a clear sign of deep human stupidity
2026-07-18 00:12:26 <tabemann    > (ranging from things like the Windscale fire -- as if exposing nuclear chain reactions in flammable graphite to the open air was ever a good idea -- to the Kyshtym accident -- as if mixing radioactive waste with potentially explosive chemical mixtures and storing it carelessly was ever a good idea (combined with, on the side, dumping radioactive waste directly into rivers and ponds) -- to SL-1 --
2026-07-18 00:12:28 <tabemann    > which was most likely suicide because there was no way that reactor should have gone critical without deliberate human intervention -- to Third Mile Island -- which incidentally was almost a non-accident as it showed that even in severe accidents with proper protection they can be contained (the estimated number of deaths from cancer resulting are < 1) -- to Chernobyl -- which involved doing very
2026-07-18 00:12:30 <tabemann    > risky things deliberately with a grossly misdesigned reactor -- to Fukushima -- which involved poor design of cooling systems for cooling radioactive waste in a reactor inappropriately placed directly in a area already known to be strongly at risk of tsunamis)
2026-07-18 00:13:09 <tabemann    > oh and that's the accidental ones, excluding deliberate nuclear testing and warfare, which contaminated the environment with radioisotopes entirely on purpose
2026-07-18 00:13:34 <tabemann    > but in none of these cases was this not involving either human stupidity or human malfeasance
2026-07-18 00:20:32 <tabemann    > and then there's non-nuclear radiation accidents, such as lost source accidents like Goiâna (again, stupidity) or radiotherapy accidents such as the whole Therac-25 matter (which was don't just trust reused code to be correct and figure "oh the code's got to be correct, let's just remove the physical lockouts just because")
2026-07-18 00:24:55 <xentrac     > clearly if human stupidity ceases to be a factor then dealing with radioisotopes would be perfectly safe
2026-07-18 00:25:14 <xentrac     > do you expect that to happen soon?
2026-07-18 00:25:22 <tabemann    > thing is, plenty of other things are dangerous because of human stupidity, such as driving cars
2026-07-18 00:25:51 <tabemann    > yet we don't see people proposing "car-free zones" except on tourist-trap islands
2026-07-18 00:26:19 <tabemann    > one is far more likely to be killed by a car accident than a nuclear or radiation accident
2026-07-18 00:28:26 <tabemann    > (the difference may be less than what one would expect, though, *if* you factor in increased cancer deaths from radioisotopes released into the environment by nuclear testing, though)
2026-07-18 00:31:25 <xentrac     > it would probably help if everyone had geiger counters
2026-07-18 00:31:41 <xentrac     > 50 years ago that wasn't a reasonable proposal
2026-07-18 00:32:42 <tabemann    > between 1899 and 2023 there were 17,224,789 traffic deaths in the US according to the Wiki
2026-07-18 00:34:29 <tabemann    > according to the following there were roughly 11,000 deaths from nuclear testing between 1951 and 2000: https://www.newscientist.com/article/1913988-nuclear-test-fall-out-killed-thousands-in-us/
2026-07-18 00:34:39 <xentrac     > that sounds a bit high, though possible if most of those were in the early years, before, for example, seatbelts
2026-07-18 00:35:10 <xentrac     > I think it's reasonable for people to be more concerned about things like deaths from nuclear testing
2026-07-18 00:35:16 <xentrac     > per death
2026-07-18 00:36:04 <tabemann    > traffic deaths peaked in the 1970's, when seatbelts were still rather new to the public
2026-07-18 00:36:30 <xentrac     > because autonomy is intrinsically valuable to people, and being killed by a risk you can't see, don't understand, and can't do anything to protect yourself against, like government nuclear testing, is a significant loss of autonomy
2026-07-18 00:37:10 <tabemann    > I should clarify, that was 11,000 deaths *in the US*
2026-07-18 00:37:12 <tabemann    > not globally
2026-07-18 00:37:20 <xentrac     > yes, thanks
2026-07-18 00:37:26 <xentrac     > that seems like the right number to compare
2026-07-18 00:37:43 <xentrac     > also the fact that it was a secret military program that you weren't *allowed* to understand was a real problem
2026-07-18 00:38:12 <tabemann    > apparently cancer rates are extremely high to this day in the marshall islands
2026-07-18 00:38:16 <xentrac     > more generally there was no risk that automotive deaths might balloon from 100,000 one year to 10,000,000 the next due to some kind of unforeseen interaction
2026-07-18 00:38:45 <xentrac     > traffic deaths are sort of the least scary kind of death
2026-07-18 00:39:06 <tabemann    > they are a type of death, while very common, is easy for one to feel like one can do something to avoid
2026-07-18 00:39:09 <xentrac     > yes
2026-07-18 00:39:14 <xentrac     > and it's immediate
2026-07-18 00:40:00 <xentrac     > you aren't going to discover that you and everyone in your town has been irreparably damaged and will die within five years, which didn't in fact happen with the nuclear weapons program
2026-07-18 00:40:27 <xentrac     > but was a reasonable kind of thing to worry about, given what was known publicly at the time and the systematic public deception campaigns around it
2026-07-18 00:41:41 <tabemann    > and you had things like The Conqueror, where a suspiciously large portion of the cast ended up with cancer, but whether that was actually that statistically off in reality is a good question
2026-07-18 00:42:05 <xentrac     > cars did cause a worldwide wave of mental disability and resulting street crime, including murder, though
2026-07-18 00:42:09 <xentrac     > via leaded gas
2026-07-18 00:42:13 <tabemann    > yes
2026-07-18 00:43:11 <tabemann    > when people say "there's so much crime today" they are ignorant of the fact that violent crime in the US peaked roughly 21 years after the point where leaded gas started being phased out
2026-07-18 00:43:22 <tabemann    > i.e. the start of the 1990's
2026-07-18 00:44:05 <tabemann    > except for a temporary increase during COVID it's been down from there
2026-07-18 00:54:03 <xentrac     > well, street crime
2026-07-18 00:54:15 <tabemann    > yeah
2026-07-18 00:54:35 <xentrac     > it's hard to tell whether Ponzi schemes, wage theft, and government bribes are up or down
2026-07-18 00:54:39 <tabemann    > some kinds of crime have definitely gone up over time, such as financial crime
2026-07-18 00:54:48 <xentrac     > I'm not sure that's definite
2026-07-18 00:54:57 <xentrac     > nobody this century is the equal of John Law
2026-07-18 00:55:20 <xentrac     > but maybe he was an outlier
2026-07-18 00:55:23 <tabemann    > when I was a kid I didn't get nearly as many scam calls or emails as I do today
2026-07-18 00:55:48 <tabemann    > I didn't have to worry about phishing
2026-07-18 00:56:42 <tabemann    > the latest thing for me has been phone calls leaving messages about suspicious-sounding loan offers
2026-07-18 00:58:59 <tabemann    > for a good while there I was getting lots of texts trying to trick me into clicking very fishy-looking links
2026-07-18 00:59:53 <tabemann    > and then there was the time that someone called me claiming to be from the sheriff's department saying that if I did not pay them $2000 USD in cash they'd have me arrested for missing a (nonexistent) jury duty appearance
2026-07-18 01:01:15 <xentrac     > those probably don't appear in the FBI's Uniform Crime Statistics
2026-07-18 01:03:16 <tabemann    > in the "sheriff" case I reported it to the local sheriff's department, which confirmed that it was a very common scam at that time
2026-07-18 01:03:46 <xentrac     > globalization also affects this.  40 years ago gangs in Laos were limited to robbing other Laotians.  now they can call you and ask you to buy them a gift card
2026-07-18 01:04:33 <xentrac     > from the US that might look like financial crime going up over time, but it might just be financial crime becoming more evenly distributed
2026-07-18 01:05:32 <tabemann    > it depends -- these loan offers definitely have the voices of people who're clearly either Americans or Canadians on the messages (but they only need one American or Canadian to record the messages, which they then spam millions of people with)
2026-07-18 01:09:07 <xentrac     > or use deepfakes, or practice with an accent coach
2026-07-18 01:10:26 <xentrac     > but sure, for voicemails they can just play a prerecorded message
2026-07-18 01:13:53 <tabemann    > the thing is accent coaches cost money, and the average scammer based out of, say, India can't afford one
2026-07-18 01:14:41 <xentrac     > scam centers in Cambodia can: https://en.wikipedia.org/wiki/Scam_center
2026-07-18 01:14:48 <tabemann    > when calling companies' phone numbers and jumping through the hoops to get an actual person I usually get someone I can tell is from India, even if they are trained to have an American accent
2026-07-18 01:14:52 <xentrac     > the average scammer isn't based in India
2026-07-18 01:15:25 <xentrac     > the person you get that way isn't a scammer; they're a legitimate employee of the company
2026-07-18 01:15:51 <xentrac     > (or possibly of their customer service subcontractor)
2026-07-18 01:16:16 <tabemann    > yeah
2026-07-18 01:17:00 <tabemann    > about the scam centers, so they're forcing actual North Americans to do their scams for them to pull in more people to do the same?
2026-07-18 01:17:59 <xentrac     > I think that is unusual
2026-07-18 01:18:45 <xentrac     > Kenyans, Ugandans, Chinese, Indians, Indonesians, etc.
2026-07-18 01:18:59 <xentrac     > see https://en.wikipedia.org/wiki/Scam_center#Human_trafficking_victims
2026-07-18 01:19:08 <tabemann    > yeah, just read that
2026-07-18 01:19:56 <xentrac     > but they're based in Cambodia, Laos, and Myanmar
2026-07-18 01:22:05 <tabemann    > and of course, they've been aided by the internal conflict in Myanmar that prevents just about any gov't, even if they wanted to, from intervening to stop these there
2026-07-18 01:30:13 <watch_dem_carbz> some of those southeast asian scam centers actually enslave american or british begpackers, "expats", "travel influencers" etc. under the guise of lucrative job offers
2026-07-18 01:30:55 <xentrac     > I haven't heard of that happening, but I think the total number of travel influencers is not large enough to satisfy much of their labor demand
2026-07-18 01:33:22 <watch_dem_carbz> maybe that's just some wishful thinking on my part
2026-07-18 01:33:22 <tabemann    > the wiki seems to say that they primarily target their "job offers" at asians or africans
2026-07-18 05:47:30 <crc         > pyzozord: The largest one I have has about 23k words
2026-07-18 05:47:56 <crc         > Not all of those are visible in the final dictionary; the top level vocabulary is around 4.5k visible words.
2026-07-18 09:40:52 <pyzozord    > 02oh interesting thanks for sharing
2026-07-18 14:37:01 <lofty       > really not enjoying trying to write an x86-64 assembler in forth; I must be missing something >.>
2026-07-18 16:08:53 <MrMobius    > whats your strategy?
2026-07-18 16:10:02 <lofty       > Break down the general forms of instructions into the specific forms I need. It's not very extensible and it's quite clumsy to work with
2026-07-18 16:30:50 <crc         > I've never enjoyed writing assemblers for x86
2026-07-18 16:31:44 <lofty       > a devil on my shoulder tells me to just hardcode the instructions I need without trying to do anything intelligent or factor things out
2026-07-18 16:36:07 <crc         > I can't help much with x86-64, but I have an assembler for a subset of 32-bit x86 in RetroForth that covers enough to implement the underlying nga vm
2026-07-18 16:37:33 <crc         > I've thought about porting it to konilo for use in the native system, but have too many other projects in progress to start another
2026-07-18 16:56:08 <lofty       > this is what I have at the moment; it's awful: https://gist.github.com/Ravenslofty/9bbd943ba4b110f11f1f8bb0842b018a
2026-07-18 17:22:02 <crc         > https://codeberg.org/jmf/impexus/src/branch/main/rasc/rasc-x86.retro is the x86 one in RetroForth
2026-07-18 17:29:09 <crc         > I don't think yours is a bad starting point
2026-07-18 17:34:09 <tabemann    > does x86 assembly not have any real underlying order to it?
2026-07-18 17:34:54 <tabemann    > I've written an ARMv6-M assembler and a partial RV32I assembler, and both of these took a great deal of advantage of the basic order of these instruction sets
2026-07-18 17:35:22 <lofty       > it had something approaching order when it was the 8086
2026-07-18 17:36:31 <tabemann    > my assemblers took advantage of the fact that there were significantly fewer instruction patterns than actual instructions
2026-07-18 17:37:03 <tabemann    > e.g. most OP Rx, Ry instructions encode similarly but with different opcode bits
2026-07-18 17:37:26 <tabemann    > a perfect use case for DOES>
2026-07-18 17:38:25 <lofty       > 1-4 bytes of legacy prefixes (optional); 1-4 bytes of opcode with prefixes (required); 1 modr/m byte (if required); 1 sib byte (if required); 1, 2, 4, or 8 bytes of displacement (if required); 1, 2, 4, or 8 bytes of immediate (if required)
2026-07-18 17:38:36 <lofty       > that's the underlying structure of an x86-64 instruction
2026-07-18 17:40:10 <tabemann    > a clusterf*ck compared to ARMv6-M or RV32I
2026-07-18 17:40:47 <lofty       > yes, it is quite fun to deal with a 64-bit immediate in the...one instruction that permits it
2026-07-18 17:43:19 <lofty       > and all of this is made even more fun with the upcoming Intel APX
2026-07-18 17:44:02 <tabemann    > wtf is that?
2026-07-18 17:44:54 <tabemann    > oh it's Intel's own latest, greatest extension of x86
2026-07-18 17:45:14 <lofty       > x86 is traditionally 2-operand instructions; x86-16/x86-32 had 8 GPRs, which x86-64 extended to 16 GPRs, but you need a REX prefix to access the upper 8 GPRs. APX extends this to 3-operand instructions with 32 GPRs, which needs a REX2 prefix
2026-07-18 17:45:28 <crc         > tabemann: not sure on x86-64, but the instruction encodings through the 32-bit variations make more sense if you look at them in octal instead of hexadecimal IIRC
2026-07-18 17:45:47 <iv4nshm4k0v > Well, 8086 was called "CISC" for a reason.  Then again, I've read the AVR instruction set manual, and while there's a number of patterns... it's not all regular through and through.
2026-07-18 17:46:56 <tabemann    > crc: I personally don't think of instruction encodings in terms of nibbles -- and after all, ARMv6-M (the instruction set I'm most familiar with) uses three bits per register
2026-07-18 17:47:03 <tabemann    > in many cases
2026-07-18 17:47:15 <lofty       > uh, are you thinking of Thumb?
2026-07-18 17:47:30 <crc         > https://gist.github.com/seanjensengrey/f971c20d05d4d0efc0781f2f3c0353da
2026-07-18 17:47:50 <tabemann    > (yeah ARMv6-M does have 16 registers, but the lower 8 registers are privileged, and SP, LR, and PC are common accessed using special ops)
2026-07-18 17:49:11 <tabemann    > lofty: Thumb-1
2026-07-18 17:49:47 <lofty       > yeah, you caught me off guard a bit because I was thinking of A32 rather than T32
2026-07-18 17:50:37 <tabemann    > I didn't write an assembler for ARMv7-M or ARMv8-M as those are considerably more complex than ARMv6-M, and the use of assembly for those breaks compatibility with ARM Cortex-M0+ (e.g. the RP2040) -- I do compile ARMv7-M/ARMv8-M *instructions* in my kernel, but my kernel is architecture-specific anyways
2026-07-18 17:51:41 <tabemann    > ARMv7-M and ARMv8-M are a mess IMO
2026-07-18 17:52:21 <tabemann    > RISC-V is much nicer than those on paper... but the RISC-V people made some key design decisions I, well, have issues with
2026-07-18 17:53:03 <tabemann    > (like assuming that the SP is four-word aligned... ugh... and let's not get into their interrupt-handling architecture)
2026-07-18 17:53:21 <tabemann    > (oh, and putting multiply and divide in the same extension too...)
2026-07-18 17:53:47 <lofty       > (Zmmul)
2026-07-18 17:54:21 <tabemann    > yeah, they learned from that *later*, but that only contributed to RISC-V's perennial extension-arrhea
2026-07-18 17:55:48 <tabemann    > RISC-V can't decide whether they're for really big application processors or really tiny microcontrollers, and made a lot of design decisions that, contradictorily, make sense on one or the other and not for anything else
2026-07-18 17:57:11 <lofty       > don't take me as an RV defender, despite having written an RV core :p
2026-07-18 17:57:28 <tabemann    > they do things to save a few gates in < $1 USD microcontrollers while simultaneously not providing things out of the box that save a lot of code memory like ARM Cortex-M-style PUSH and POP instructions (yeah, they're in an extension, I know, but they aren't nearly as flexible as their ARM counterparts...)
2026-07-18 17:59:12 <tabemann    > oh, and their interrupts... when I implemented the original ARM Cortex-M zeptoforth it kind of assumed a table of interrupt vectors that would be conveniently called and returned from like normal subroutines
2026-07-18 18:00:58 <tabemann    > when I tried to port zeptoforth to RV32I... I realized that not only did they not have vectors like ARM Cortex-M (yeah, they have a vectored mode, but that uses *instructions* and not *addresses* and hence are inherently limited by branch distances), and furthermore, they lumped everything other than 'soft' interrupts (e.g. like ARM SVC) and 'timer' interrupts (e.g. like SysTick) into one big
2026-07-18 18:01:00 <tabemann    > 'external' interrupt that would have to be handled entirely manually
2026-07-18 18:01:23 <tabemann    > and furthermore almost every RISC-V implementation tries to fix this deficiency... entirely independent of one another
2026-07-18 18:02:05 <tabemann    > this is why we don't have zeptoforth-V yet, because I can't bring myself to deal with this nonsense
2026-07-18 20:45:26 <veltas      > To be honest ARM is unique in having a lot of push/pop flexibility
2026-07-18 20:45:31 <veltas      > I don't know other arch's like this
2026-07-18 21:32:59 <tabemann    > apparently the big criticism of ARM PUSH/POP is that it makes implementing interrupts harder
2026-07-18 21:33:33 <tabemann    > but at the same time, isn't that just a limited cost in gates for the sake of significantly reducing the size of certain kinds of code?
2026-07-18 21:33:53 <lofty       > I wouldn't quite say it's "limited"
2026-07-18 21:34:36 <tabemann    > when I was working on zeptoforth-V, where I couldn't use the RISC-V PUSH/POP extension because it requires the SP to be four-word aligned (which is an anathema to me), my push and pop functionality was consistently far bigger and more complex than on ARM Cortex-M
2026-07-18 21:34:59 <lofty       > if you make those uninterruptible you increase interrupt latency; otherwise you need to be able to save state inside the instruction
2026-07-18 21:35:15 <lofty       > tabemann: what's your reference chip?
2026-07-18 21:35:40 <lofty       > RP2350, or something else?
2026-07-18 21:35:42 <tabemann    > ARM Cortex-M3/M4/M7/M33 have interruptable multiword stores and fetches, BTW
2026-07-18 21:36:15 <tabemann    > for zeptoforth-V I was using RP2350 as my reference, but I was stymied by the fact that I didn't want to rely on anything RP2350-specific in the very core of the kernel
2026-07-18 21:36:47 <tabemann    > in the original zeptoforth, while the kernel has platform-specific code, it's rather separated out
2026-07-18 21:37:11 <tabemann    > but for zeptoforth-V it seems I will have to code specifically for the RP2350 at a deeper level, an idea I don't like
2026-07-18 21:37:37 <tabemann    > because of the interrupt controller in particular
2026-07-18 21:38:43 <tabemann    > I wanted to maintain compatibility with the ARM Cortex-M as far as possible, but the problem is that RISC-V does not follow the "vector of call addresses for interrupts" model of ARM Cortex-M, seeingly to save a few transistors
2026-07-18 21:39:11 <tabemann    > and of course Wren thought that was stupid so implemented his own interrupt controller specifically for the RP2350
2026-07-18 21:39:23 <tabemann    > but that would mean marrying my code specifically to the RP2350
2026-07-18 21:41:03 <tabemann    > the big problem is that zeptoforth is designed around each peripheral driver registering its own interrupt handler for the IRQ's it is interested in
2026-07-18 21:41:42 <tabemann    > but in the stock RISC-V interrupt controller I have to filter *all* of that through just the 'external' interrupt... or I have to use Wren's extra special Hazard3 interrupt controller
2026-07-18 21:43:27 <lofty       > tabemann: did you look at Zilsd/Zclsd if you didn't like Zcmp?
2026-07-18 21:43:55 <tabemann    > these sorts of things are why I say RISC-V simultaneously seems to target very small systems and very big systems while inadequately accommodating everything in between
2026-07-18 21:45:38 <tabemann    > lofty: I've been implementing zeptoforth-V to be easily portable to RV64I consciously, whereas the original zeptoforth has 32-bit-ness baked in, and relying on those would break that
2026-07-18 21:48:10 <tabemann    > for instance, I removed most references in the code to 4 bytes except where I could guarantee that 4 bytes would remain 4 bytes on RV64I, I made macros for accessing 4 bytes on RV32I and 8 bytes on RV64I, I made separate W@ W! W, etc. words for specifically accessing 4 byte quantities when I need it (so @ ! , etc. could be 8 byte on RV64I), and like
2026-07-18 21:55:03 <lofty       > So your envisioned target RV64 platform does not have D?
2026-07-18 21:55:43 <lofty       > Or can disable D through misa
2026-07-18 21:58:16 <tabemann    > just a question -- what do you mean by D offhand?
2026-07-18 21:58:28 <tabemann    > you certainly don't mean the D programming language
2026-07-18 21:58:46 <lofty       > Double-precision floating point - the RISC-V D extension
2026-07-18 21:58:59 <tabemann    > oh gotcha
2026-07-18 22:00:23 <tabemann    > I'll cross that bridge when I get to it, but I'll probably handle it the way I handle single-precision floats in ARM Cortex-M4F, -M7F, and -M33F
2026-07-18 22:01:07 <lofty       > because C + D implies Zcd, which is mutually exclusive with Zcmp.
2026-07-18 22:01:41 <tabemann    > which is to not use a separate stack for floats but rather to store floats on the same stacks as everything else
2026-07-18 22:02:54 <tabemann    > that's more reason to not use Zcmp
2026-07-18 22:03:06 <tabemann    > I'm currently not using Zcmp because of its alignment requirements
2026-07-18 22:03:30 <tabemann    > because with how I use the return stack, requiring four-word alignment of SP would be *terribly* wasteful
2026-07-18 22:04:17 <tabemann    > each uninlined/unfolded word call would end up using *at least* 16 bytes of return stack
2026-07-18 22:04:56 <tabemann    > which to me is unacceptable
2026-07-18 22:05:12 <tabemann    > this is a good example of a braindead decision made by the RISC-V people
2026-07-18 22:08:53 <lofty       > to be honest: I don't think RV32 and RV64 were ever meant to be used simultaneously. as a new ISA it's not like RV64 has to support legacy RV32 software.
2026-07-18 22:09:32 <tabemann    > I'm taking the idea from Mecrisp-Quintus, which can run on both RV32 and RV64
2026-07-18 22:09:47 <tabemann    > of course it takes a recompile
2026-07-18 22:10:00 <tabemann    > as it relies heavily on macros to work on both
2026-07-18 22:10:08 <lofty       > but that's the thing, isn't it?
2026-07-18 22:10:40 <lofty       > I feel like you should treat them as two separate platforms, not as one combined platform
2026-07-18 22:12:47 <tabemann    > part of it is that I don't want to repeat some of the mistakes I made when implementing the original zeptoforth, where I implemented for ARM Cortex-M4 originally and then had to do a big porting job to get it to work on ARM Cortex-M0+
2026-07-18 22:13:11 <tabemann    > so I'm this time around intentionally future-proofing it for the eventuality that I do want to run it on RV64
2026-07-18 22:14:16 <tabemann    > so I have to use as little conditional compilation or duplicated code as possible
2026-07-18 23:22:20 <veltas      > Yeah I would treat like a different arch