That's not a fair question given Forth doesn't do crap compared to alternatives I'm pushing. More like "Does it use a reasonable number of gates for a commercial processor? For a MCU, do any schemes use a tiny number of gates to provide some protections vs existing MCU's?"
Answer to these are yes. As several people want links, here's a list of approaches ranging from safety to security, full to partial, MPU to MCU.
Two of the best for full safety are Hardbound and Watchdog, both from same group:
https://www.cis.upenn.edu/acg/papers/asplos08_hardbound.pdf
https://www.cs.rutgers.edu/~santosh.nagarakatte/papers/isca1...
One provides full spatial safety with other providing full memory safety with both having C compatibility. There are significant extra chip resources. Not a problem in a microprocessor, though, given the frivilous stuff takes up more space than this. The performance overhead is usually single-digit (under 5%) with it maxing out on 20% on Hardbound and 25% on Watchdog. For Watchdog, that's trading occasional 25% hit or buying a bit of extra CPU to get fully-compatible and safe C software. Great trade. HW experts could probably optimize it even further.
CHERI processor:
https://www.cl.cam.ac.uk/~swm11/research/papers/isca2014.pdf
CHERI processor adds capability-security to mix on MIPS processor. FreeBSD already ported. Uses 32% extra logic elements with 8% clock speed reduction and overhead similar to above designs. Recent papers added more protection, reduced some overheads, and so on. Strange enough, I used this one because the others have too much data to sift through quickly.
Sandia Secure Processor (SSP):
http://faculty.ist.unomaha.edu/winter/ShiftLab/Monarch_web/L...
For microcontrollers, Forth is a bad idea because it's typeless and dynamic. It's best to have strong typing plus static behavior so our current tooling can know exactly how it will behave. That naturally leads to things like Java. The system at jopdesign.com is just over 2,000 slices in FPGA. Idk if it has built-in safety checks or uses compiler's. However, this high-assurance CPU manages first-pass for 40,000 gates with full checks and verification. Plus can leverage Java tooling for automated unit tests, static analysis, dynamic analysis, design by contract... you name it. They even have a tool for converting regular Java to their tool.
Examples of ultra, lightweight schemes for MCU's:
http://www.icri-sc.org/fileadmin/user_upload/Group_TRUST/Pub...
Trustlite does isolation, attestation, and exception handling. It uses about 300 extra registers and 440 extra LUTS on a FPGA plus around 200 each per protected module. Tiny.
https://www.cs.utah.edu/~regehr/papers/plos06a.pdf
Works on 8-bit with TinyOS demonstration. Software method. Something like this could be hardware supported.
http://www.ece.umd.edu/~barua/simpson-CASES-2005.pdf
One for microcontrollers that averages 0.72% speed overhead (approx 10% max) and code size of 3.6%. Could be aided with HW.
http://read.seas.harvard.edu/~kohler/pubs/kumar07system.pdf
Another proven out on an ATmega with single-digit runtime effects and only a few thousands slices in MCU that's over 20,000 at start.
Note: You don't see much on 8-bit or 16-bit HW on my list as they're so constrained that a MPU or stack-overflow check is about all you can do. It's why I recommend against them most of the time. The likes of Infineon and Gemalto are stretching their capabilities far, though, in smartcard IC's with onboard crypto, MPU's, built-in checks, and usually a verified, safe OS or platform like MULTOS or JavaCard. One really just needs to use best tools and care they can on such platforms, though. 32-bit in 20,000-30,000 gate range is the lower bound so far on believable tech for assisted safety or security. I mean, you can use 8- or 16-bit with similar tech but your overall datapath and gates will be similar to 32-bit ones. Just get different tradeoffs in speed, code-size, addressing, and so on.