> The problem I had that the larger your project gets, the more mistakes Claude makes
I think the reason for this is because these systems get all their coding and design expertise from training, and while there is lots of training data available for small scale software (individual functions, small projects), there is much less for large projects (mostly commercial and private, aside from a few large open source projects).
Designing large software systems, both to meet initial requirements, and to be maintainable and extensible over time, is a different skill than writing small software projects, which is why design of these systems is done by senior developers and systems architects. It's perhaps a bit like the difference between designing a city and designing a single building - there are different considerations and decisions being made. A city is not just a big building, or a collection of buildings, and large software system is not just a large function or collection of functions.
It's interesting that Amazon don't appear interested in acquiring Anthropic, which would have seemed like somewhat of a natural fit given that they are already partnered, Anthropic have apparently optimized (or at least adapted) for Trainium, and Amazon don't have their own frontier model.
It seems that Amazon are playing this much like Microsoft - seeing themselves are more of a cloud provider, happy to serve anyone's models, and perhaps only putting a moderate effort into building their own models (which they'll be happy to serve to those who want that capability/price point).
I don't see the pure "AI" plays like OpenAI and Anthropic able to survive as independent companies when they are competing against the likes of Google, and with Microsoft and Amazon happy to serve whatever future model comes along.
LOL of course they don't want to own Anthropic, else they themselves would be responsible for coming up with the $10s of billions in Monopoly money that Anthropic has committed to pay AMZN for compute in the next few years. Better to take an impressive looking stake and leave some other idiot holding the buck.
Now I’m no big city spreadsheet man but I bet you “company that owes us billions went belly up” looks better on the books than “company we bought that owes us billions went belly up.”
It’s pretty crazy that Amazon’s $8B investment didn’t even get them a board seat. It’s basically a lot of cloud credits though. I bet both Google and Amazon invested in Anthropic at least partially to stress test and harden their own AI / GPU offerings. They now have a good showcase.
Yeah. I bet there’s a win-win in the details where it gets to sound like a lot of investment for both parties to look good but really wasn’t actually much real risk.
Like if I offered you $8 billion in soft serve ice cream so long as you keep bringing birthday parties to my bowling alley. The moment the music stops and the parents want their children back, it’s not like I’m out $8 billion.
Why does everybody keep insisting on this “Enron accounting” stuff. LLM companies need shitloads of compute for specialized use case. Cloud vendor wants to become a big player in selling compute for that specialized use case, and has compute available.
Cloud provider gives credit to LLM provider in exchange for a part of the company.
Amazon gave away datacenter time share in exchange for stock in a startup. That has nothing to do with electricity futures and private credit revolvers.
This is my thought too. They de-risked any other AI startup from choosing AWS as their platform. If the hype continues AWS will get their 30% margin on something growing like rocket emoji, if they don't at least they didn't miss the boat.
Amazon also uses Claude under the hood for their "Rufus" shopping search assistant which is all over amazon.com.
It's kind of funny, you can ask Rufus for stuff like "write a hello world in python for me" and then it will do it and also recommend some python books.
> It's kind of funny, you can ask Rufus for stuff like "write a hello world in python for me" and then it will do it and also recommend some python books.
Interesting, I tried it with the chatbot widget on my city government's page, and it worked as well.
I wonder if someone has already made an openrouter-esque service that can connect claude code to this network of chat widgets. There are enough of them to spread your messages out over to cover an entire claude pro subscription easily.
A childhood internet friend of mine did something similar to that but for sending SMSes for free using the telco websites' built in SMS forms. He even had a website with how much he saved his users, at least until the telcos shut him down.
Well Phreaking in 2003-05 (no clue when anymore), so at the same time you could still get free phone calls on pay phones in the library or hotel lobby.
Not sure for Claude Code specifically, but in the general case, yes - GPT4Free and friends.
I think if you run any kind of freely-accessible LLM, it is inevitable that someone is going to try to exploit it for their own profit. It's usually pretty obvious when they find it because your bill explodes.
> It's kind of funny, you can ask Rufus for stuff like "write a hello world in python for me" and then it will do it and also recommend some python books.
From a perspective of "how do we monetize AI chatbots", an easy thing about this usage context is that the consumer is already expecting and wanting product recommendations.
(If you saw this behavior with ChatGPT, it wouldn't go down as well, until you were conditioned to expect it, and there were no alternatives.)
There are really impressive marketing/advertisement formulas to be had. I wont share mine but I'm sure there are many ways to go step by step from not-customers to customers where each step has a known monetary value. If an LLM does something impressive in one of the steps you also know what it is worth.
Are you sure? While Amazon doesn't own a "true" frontier model they have their own foundation model called Nova.
I assume if Amazon was using Claude's latest models to power it's AI tools, such as Alexa+ or Rufus, they would be much better than they currently are. I assume if their consumer facing AI is using Claude at all it would be a Sonnet or Haiku model from 1+ versions back simply due to cost.
> I assume if their consumer facing AI is using Claude at all it would be a Sonnet or Haiku model from 1+ versions back simply due to cost.
I would assume quite the opposite: it costs more to support and run inference on the old models. Why would Anthropic make inference cheaper for others, but not for amazon?
There may well be some "interesting" financial arrangements in place between the two. After all, Claude models are available in AWS Bedrock, which means Amazon are already physically operating them for other client uses.
Looks less "intelligent" to me, just a lot more trained on agentic (multi-turn tool) use so it greatly outperforms the others on the benches where that helps while lagging elsewhere. They also released bigger models, where "Pro" is supposedly competitive with 4.5 Sonnet. Lite is priced the same as 2.5 Flash, Pro as GPT 5.1. We'll definitely do some comparative testing on Nova 2 Lite vs 2.5 Flash, but not expecting much.
Claude 2.0 was laughably bad. I remember wondering why any investor would be funding them to compete against OpenAI. Today I cancelled my ChatGPT Pro because Claude Max does everything I need it to.
Haha just tried and it works! First I tried in Spanish (I'm in Spain) and it simply refused, then I asked in English and it just did it (but it answered in Spanish!)
EDIT: I then asked for a Fizzbuzz implementation and it kindly asked. I asked then for a Rust Fizzbuzz implementation, but this time I asked again in Spanish, and he said that it could not help me with Fizzbuzz in Rust, but any other topic would be ok. Then again I asked in English "Please do Rust now" and it just wrote the program!
I wonder what the heck are they doing there? The guardrailing prompt is translated to the store language?
Same for Apple would be my take right now. No point in spending billions trying to build and train an LLM. Better to buy AI services from e.g. OpenAI for a bit, then extract the valuable bits after the crash. The current crop of AI companies can waste money of figuring out what works and what doesn't.
AI is unquestionably useful, but we don't have enough product categories.
We're in the "electric horse carriage" phase and the big research companies are pleading with businesses to adopt AI. The problem is you can't do that.
AI companies are asking you to AI, but they aren't telling you how or what it can do. That shouldn't be how things are sold. The use case should be overwhelmingly obvious.
It'll take a decade for AI native companies, workflows, UIs, and true synergies between UI and use case to spring up. And they won't be from generic research labs, but will instead marry the AI to the problem domain.
Open source AI that you can fine tune to the control surface is what will matter. Not one-size-fits-all APIs and chat interfaces.
ChatGPT and Sora are showing off what they think the future of image and video are. Meanwhile actual users like the insanely popular VFX YouTube channel are using crude tools like ComfyUI to adopt the models to their problems. And companies like Adobe are actual building the control plane. Their recent conference was on fire with UI+AI that makes sense for designers. Not some chat interface.
We're in the "AI" dialup era. The broadband/smartphone era is still ahead of us.
These companies and VCs thought they were going to mint new Googles and Amazons, but it's more than likely they were the WebVans whose carcasses pave the way.
After watching The Thinking Game documentary, maybe Amazon has little appetite for "research" companies that don't actually solve real world problems, like Deepseek did.
The movie seems like a fluff piece when you find out what has transpired at DeepMind subsequently with slowing down publishing material to “selling out to product” which the founder was hell bent against in the documentary.
> It seems that Amazon are playing this much like Microsoft - seeing themselves are more of a cloud provider, happy to serve anyone's models, and perhaps only putting a moderate effort into building their own models (which they'll be happy to serve to those who want that capability/price point).
Or, as a slight variation of that, they think the underlying technology will always be quickly commoditized and that no one will ever be able to maintain much of a moat.
I think anyone sane will have had the same conclusion a long time ago.
It's a black box with input/output in text, thats not a very good moat.
especially given that Deepseek type events can happen because you can just train off of your competitors outputs
I've tried out Gemini 2.5/3 and it generally seems to suck for some reason, problems with lying/hallucinating and following instructions, but ever since Bard came out at first, I thought Google would have the best chances of winning since they have their own TPUs, YouTube (insane video/visual/audio data), Search (indexed pages), and their Cloud/DCs and they can stick it into Android/Search/Workspace.
meanwhile OpenAI has no existing business, they only have API/Subs as revenue, and they're utilizing Nvidia/AMD
I really wonder how things will look once this gold rush stabilizes
Bezos is playing it smart: sell shovels to all of the gold diggers. If he partners with one of the gold diggers he won't be able to sell shovels to the remainder.
That's a risk-return issue. Bezos plays it safe within Amazon, and quite unsafe outside of that. By the time he acquires something from Amazon it is because it has proven long-term revenue generation and the shake-out period is done and consolidation is about to start. With AI the shake-out is still to come. So he can afford to wait to eventually acquire the winner or to copy it if he can't buy it. Having very deep pockets enables different business strategies.
They're likely just waiting out the eventual crash and waiting to buy at the resulting fire sale. Microsoft has done a very good job of investing in the space enough to see a potentially lucrative pay out while managing the risk enough to not be sunk if it doesn't pan out.
It's safe to assume that a company like Anthropic has been getting (and rejecting) a steady stream of acquisition offers, including from the likes of Amazon, from the moment they got proninent in the AI space.
I think Claude Code is the moat (though I definitely recognize it's a pretty shallow moat). I don't want to switch to Codex or whatever the Gemini CLI is, I like Claude Code and I've gotten used to how it works.
Again, I know that's a shallow moat - agents just aren't that complex from a pure code perspective, and there are already tools that you can use to proxy Claude Code's requests out to different models. But at least in my own experience there is a definite stickiness to Claude that I probably won't bother to overcome if your model is 1.1x better. I pay for Google Business or whatever it's called primarily to maintain my vanity email and I get some level of Gemini usage for free, and I barely touch it, even though I'm hearing good things about it.
(If anything I'm convincing myself to give Gemini a closer look, but I don't think that undermines my overarching (though slightly soft) point).
1. using Claude Code exclusively (back when it really was on another level from the competition) to
2. switching back and forth with CC using the Z.ai GLM 4.6 backend (very close to a drop-in replacement these days) due to CC massively cutting down the quota on the Claude Pro plan to
3. now primarily using OpenCode with the Claude Code backend, or Sonnet 4.5 Github Copilot backend, or Z.ai GLM 4.6 backend (in that order of priority)
OpenCode is so much faster than CC even when using Claude Sonnet as the model (at least on the cheap Claude Pro plan, can't speak for Max). But it can't be entirely due to the Claude plan rate limiting because it's way faster than CC even when using Claude Code itself as the backend in OC.
I became so ridiculously sick of waiting around for CC just to like move a text field or something, it was like watching paint dry. OpenCode isn't perfect but very close these days and as previously stated, crazy fast in comparison to CC.
Now that I'm no longer afraid of losing the unique value proposition of CC my brand loyalty to Anthropic is incredibly tenuous, if they cut rate limits again or hurt my experience in the slightest way again it will be an insta-cancel.
So the market situation is much different than the early days of CC as a cutting edge novel tool, and relying on that first mover status forever is increasingly untenable in my opinion. The competition has had a long time to catch up and both the proprietary options like Codex and open source model-agnostic FOSS tools are in a very strong position now (except Gemini CLI is still frustrating to use as much as I wish it wasn't, hopefully Google will fix the weird looping and other bugs ... eventually, because I really do like Gemini 3 and pay for it already via AI Pro plan).
Google Code assist is pretty good. I had it create a pretty comprehensive inventory tracking app within the quota that you get with the $25 google plan.
Google had PageRank, which gave them much better quality results (and they got users to stick with them by offering lots of free services (like gmail) that were better quality than existing paid services). The difference was night and day compared to the best other search engines at the time (WebCrawler was my goto, then sometimes AltaVista). The quality difference between "foundation" models is nil. Even the huge models they run in datacenters are hardly better than local models you can run on a machine 64gb+ ram (though faster of course). As Google grew it got better and better at giving you good results and fighting spam, while other search engines drowned in spam and were completely ruined by SEO.
PageRank wasn't that much better. It was better and the word spread. Google also had a very clean UI at a time where websites like Excite and Yahoo had super bloated pages.
That was the differentiation. What makes you think AI companies can't find moats similar to Google's? The right UX, the right model and a winner can race past everyone.
PageRank, everything before PageRank was more like yellow pages than a search engine as we know it today. Google also had a patent on it, so it's not like other people could simply copy it.
Google was also way more minimal (and therefore faster on slow connections) and it raised enough money to operate without ads for years (while its competitors were filled with them).
Not really comparable to today, when you have 3-4 products which are pretty much identical, all operating under a huge loss.
Is Claude Code even running at a marginal profit? (who knows)
Is the marginal profit large enough to pay for continued R&D to stay competitive (no)
Does Claude Code have a sustainable advantage over what Amazon, Microsoft and Google can do in this space using their incumbency advantage and actual profits and using their own infrastructure?
Assuming by "they" you mean current shareholders (who include Google and Amazon and VCs) if they are selling at least in part, why would at least some of them not be willing to sell their entire stakes?
> They could make more money keeping control of the company and have control.
I get the feeling Amazon wants to be the shovel seller for the AI rush than be a frontier model lab.
There is no moat in being a frontier model developer. A week, month, or a year later there will be a open source alternative which is about 95% as good for most tasks people care about.
I don't know how much they are spending to be fair.
I am basing my observation on the noises they are making.
They did put out a model called Nova but they are not drumming it up at all.
The model page makes no claims of benchmarks or performance.
There are no signs of them poaching talent.
Their CEO has not been in the press singing praises about AI unlike every big tech CEO.
Maybe they have a skunk-works team on it but something tells me they are waiting for the paint to dry.
Well, i have had chats with a few engineers working in Amazon retail and there is talk about adding agents for Ops and similar internal tasks. So there is a bunch of AI related things happening, and like others have said, they rent shovels for the rush, so they will bank all the money without having to compete with the money bonfires that others are burning.
Sort of. You can do what Zuck did; give your shares more votes, so you stay in control. (He owns 13% of the shares, but more than 50% of the voting power.) That's less doable with an acquisition.
In one case your ownership is diluted by maybe 10%, and you keep full decision making power and everything else. In the other it is diluted by 100% and you are now an employee. They are very different outcomes.
why would you take on that burn rate when you can invest, get the investment back over time in cloud spend, and maybe make off like bandits when they ipo
why exit now and become a stuffed AI driven animal when you can keep running this ship yourself, doing your dream job and getting all the woos and panties?
> It's interesting that Amazon don't appear interested in acquiring Anthropic
1. Why buy the cow when you can get the milk for free?
2. Amazon doesn't appear interested in acquiring Anthropic _at its current valuation_. I would be surprised if it's not available for acquisition at 1/10th its current price in the next 3-5 years
AI isn't going anywhere, but "prop model + inference" is far from a proven business model.
It is spending a lot of money to do the same thing (selling the shovels), and gaining maybe a bit bigger cut if the bubble doesn't burst too violently.
Anthropic is a $1T company in the making (by 2030), already raised their last round at ~$200B valuation. Do you really think Amazon can acquire them? They already invested a lot of money in them and probably own at least 20% of Anthropic, which was the smartest thing Jassy did in a while. Not to mention, if Adobe wasn't allowed to buy Figma, do you think Amazon will be allowed to buy Anthropic? No way it's going to be approved.
> I don't see the pure "AI" plays like OpenAI and Anthropic able to survive as independent companies when they are competing against the likes of Google, and with Microsoft and Amazon happy to serve whatever future model comes along.
One thing you're right about - Anthropic isn't surviving - it's thriving. Probably the fastest growing revenue in history.
They've developed a sparse attention mechanism (which they document and release source code for) to increase model efficiency with long context, as needed for fast & cost-effective extensive RL training for reasoning and agentic use
They've built a "stable & scalable" RL protocol - more capable RL training infrastructure
They've built a pipeline/process to generate synthetic data for reasoning and agentic training
These all combine to build an efficient model with extensive RL post-training for reasoning and agentic use, although they note work is still needed on both the base model (more knowledge) and post-training to match frontier performance.
LEA and MOV are doing different things. LEA is just calculating the effective address, but MOV calculates the address then retrieves the value stored at that address.
e.g. If base + (index * scale) + offset = 42, and the value at address 42 is 3, then:
LEA rax, [base + index * scale + offset] will set rax = 42
MOV rax, [base + index * scale + offset] will set rax = 3
LEA stands for Load Effective Address, so the syntax is as-if you're doing a memory access, but you are just getting the calculated address, not reading or writing to that address.
LEA would normally be used for things like calculating address of an array element, or doing pointer math.
I was ok with that as "fledgling AI" at the start of the movie/documentary, but thought that going back to it and having the chatbot suggest a chess book opening to Hassabis at the end was cheesy and misleading.
They should have ended the movie on the success of AlphaFold.
It seems that to solve the protein folding problem in a fundamental way would require solving chemistry, yet the big lie (or false hope) of reductionism is that discovering the fundamental laws of the universe such as quantum theory doesn't in fact help that much with figuring out the laws/dynamics at higher levels of abstraction such as chemistry.
So, in the meantime (or perhaps for ever), we look for patterns rather than laws, with neural nets being one of the best tools we have available to do this.
Of course ANNs need massive amounts of data to "generalize" well, while protein folding only had a small amount available due to the months of effort needed to experimentally discover how any protein is folded, so DeepMind threw the kitchen sink at the problem, apparently using a diffusion like process in AlphaFold 3 to first determine large scale structure then refine it, and using co-evolution of proteins as another source of data to address the paucity.
So, OK, they found a way around our lack of knowledge of chemistry and managed to get an extremely useful result all the same. The movie, propaganda or not, never suggested anything different, and "at least 90% correct" was always the level at which it was understood the result would be useful, even if 100% based on having solved chemistry / molecular geometry would be better.
We have seen some suggestion that the classical molecular dynamics force fields are sufficient to predict protein folding (in the case of stable, soluble, globular proteins), in the sense that we don't need to solve chemistry but only need to know a coarse approximation of it.
I think the ideal compiler for 6502, and maybe any of the memory-poor 8-bit systems would be one that supported both native code generation where speed is needed as well as virtual machine code for compactness. Ideally would also support inline assembler.
The LLVM-MOS approach of reserving some of zero page as registers is a good start, but given how valuable zero page is, it would also be useful to be able to designate static/global variables as zero page or not.
I've implemented Atari 2600 library support for both LLVM-MOS and CC65, but there are too many compromises to make it suitable for writing a game.
The lack of RAM is a major factor; stack usage must be kept to a minimum and you can forget any kind of heap. RAM can be extended with a special mapper, but due to the lack of a R/W pin on the cartridge, reads and writes use different address ranges, and C does not handle this without a hacky macro solution.
Not to mention the timing constraints with 2600 display kernels and page-crossing limitations, bank switching, inefficient pointer chasing, etc. etc. My intuition is you'd need a SMT solver to write a language that compiles for this system without needing inline assembly.
AIUI, Oscar64 does not aim to implement a standard C/C++ compiler as LLVM does, so the LLVM-MOS approach is still very much worthwhile. You can help by figuring out which relevant optimizations LLVM-MOS seems to be missing compared to SOTA (compiled or human-written) 6502 code, and filing issues.
We already know what the main remaining issue is - LLVM-MOS's register allocator is far from optimal for the 6502 architecture. mysterymath is slowly working on what may become a more sutiable allocator.
There is a video below of mysterymath presenting LLVM-MOS where he talks about reserving 32 bytes of zero page to present to LLVM as 16 16-bit registers, to be able to utilize it's register allocator, which does seem a sane approach.
I wouldn't say intractable, but it's not clear whether LLVM's optimization framework is flexible enough for it.
From mysterymath's (LLVM-MOS) description, presenting some of zero page as 16 bit registers (to make up for lack thereof, and perhaps due to LLVM not having any other support for preferred/faster memory regions), while beneficial, still had limitations since LLVM just assumes that there will be FAST register-register transfer operations available, and that is not even true for the 6502's real registers (no TXY), let alone these ZP "registers" which would require using the accumulator to copy.
A code generation/optimization approach that would seem more guaranteed to do well on the 6502 might be to treat it more as tree search (with pruning) - generate multiple branching alternatives and then select the best based on whatever is being optimized for (clock cycles or code size).
Coding for the 6502 by hand was always a bit like that ... you had some ideas of alternate ways things could be coded, but there was also an iterative phase of optimization (cf search) to tweak it and save a byte here, a couple of cycles there ...
I've mentioned elsewhere I used to work for Acorn back in the day, developing for the BBC micro, with me and a buddy developing the ISO-Pascal system which was delivered in 2 16KB ROMs. Putting code in ROM gives you an absolute hard size budget, and putting a full Pascal compiler, interpreter, runtime library and programmers editor into a total 32KB was no joke! I remember at the end of the project we were still a few hundred bytes over what would fit in the ROMs, and had to fight for every byte to make it fit!
It is my conjecture that due to the 8 bit index registers, contrast that to 6800, 6809 and others, the 6502 becomes fundamentally a structure of arrays (SOA) system versus C which is coupled in it's libraries and existing code base with array of structures (A0S).
Optimizing code will never solve good data oriented design. This is just one of the reasons that Asm programmers routinely beat C code on the 6502. Another one is math. In the C language specification, if fixed point had been given equal footing with float that would also help.
These are such a blind spos that you rarely even see custom 6502 high level languages accommodate these fundamental truths.
BTW, growing up on the 6502, I had no problems moving into the very C friendly 68000 but later going backwards to the 6809, on the surface it looked so much like a 6502 that I was initially trying to force SOA in my data design before realizing it was better suited to AOS.
If we're comparing performance of code generated by a C compiler vs hand optimized assembler, then for it to be an apples-to-apples comparison the same data structures (e.g. SOA or AOS) need to be used in both cases.
Yep. C was always meant to be a "close to the metal" language providing a feature set that could be mapped pretty directly to the processors it was running on. It's a "low level, high level language" where the expectation is more what you see is what you get (WYSIWYG), even though a modern optimizer might be expected to remove invariant code out of loops, etc - localized efficiency gains, but not large scale transformation.
So, optimal C targetting the 6502 is not going to look much like C targetting a modern processor. The developer still needs to be very aware of the limitations of the processor they are targetting.
One somewhat radical thing that LLVM-MOS does is to analyze the program's call graph, and for functions that are not used recursively it will assign parameters and local variables to zero page instead, both for speed of access and to avoid need for a stack frame. Even though this violates the WYSIWYG mental model, this is a nice abstraction of what the assembly language programmer would have done themself.
>One somewhat radical thing that LLVM-MOS does is to analyze the program's call graph, and for functions that are not used recursively it will assign parameters and local variables to zero page instead, both for speed of access and to avoid need for a stack frame. Even though this violates the WYSIWYG mental model, this is a nice abstraction of what the assembly language programmer would have done themself.
very nice, it sounds similar to the 'compiled stack' concept. I've seen that here in the co2 language for the 6502
"Variables declared as subroutine parameters or by using let are statically allocated using a "compiled stack", calculated by analyzing the program's entire call graph. This means scopes will not use memory locations used by any inner scopes, but are free to use them from sibling scopes. This ensures efficient variables lookups, while also not wasting RAM. However, it does mean that recursion is not supported."
There is a C standard extension for embedded/low-level programming which specifies fixed point arithmetic. (And other goodies such as hardware register access and multiple address spaces.)
With regard to code size in this comparison someone associated with llvm-mos remarked that some factors are: their libc is written in C and tries to be multi-platform friendly, stdio takes up space, the division functions are large, and their float support is not asm optimized.
I wasn't really thinking of the binary sizes presented in the benchmarks, but more in general. 6502 assembler is compact enough if you are manipulating bytes, but not if you are manipulating 16 bit pointers or doing things like array indexing, which is where a 16-bit virtual machine (with zero page registers?) would help. Obviously there is a trade-off between speed and memory size, but on a 6502 target both are an issue and it'd be useful to be able to choose - perhaps VM by default and native code for "fast" procedures or code sections.
A lot of the C library outside of math isn't going to be speed critical - things like IO and heap for example, and there could also be dual versions to choose from if needed. Especially for retrocomputing, IO devices themselves were so slow that software overhead is less important.
More often than not the slow IO devices were coupled with optimized speed critical code due to cost savings or hardware simplification. Heap is an approach that rarely works well on a 6502 machine - there are no 16 bit stack pointers and it's just slower than doing without - However I tend to agree that a middle ground 16 bit virtual machine is a great idea. The first one I ever saw was Sweet16 by Woz.
I agree about heap - too much overhead to be a great approach on such a constrained target, but of course the standard library for C has to include it all the same.
Memory is better allocated in more of a customized application specific way, such as an arena allocator, or just avoid dynamic allocation altogether if possible.
I was co-author of Acorn's ISO-Pascal system for the 6502-based BBC micro (16KB or 32KB RAM) back in the day, and one part I was proud of was a pretty full featured (for the time) code editor that was included, written in 4KB of heavily optimized assembler. The memory allocation I used was just to take ownership of all free RAM, and maintain the edit buffer before the cursor at one end of memory, and the buffer content after the cursor at the other end. This meant that as you typed and entered new text, it was just appended to the "before cursor" block, with no text movement or memory allocation needed.
> I think the ideal compiler for 6502, and maybe any of the memory-poor 8-bit systems would be one that supported both native code generation where speed is needed as well as virtual machine code for compactness.
Threaded code might be a worthwhile middle-of-the-way approach that spans freely across the "native" and "pure VM interpreter" extremes.
I think the reason for this is because these systems get all their coding and design expertise from training, and while there is lots of training data available for small scale software (individual functions, small projects), there is much less for large projects (mostly commercial and private, aside from a few large open source projects).
Designing large software systems, both to meet initial requirements, and to be maintainable and extensible over time, is a different skill than writing small software projects, which is why design of these systems is done by senior developers and systems architects. It's perhaps a bit like the difference between designing a city and designing a single building - there are different considerations and decisions being made. A city is not just a big building, or a collection of buildings, and large software system is not just a large function or collection of functions.
reply