-
^Total sidetrack, but NorthGuy, can you explain this one?
Using 16F1xxx enhanced midrange. I happen to have an older code which has a long subroutine which wraps across page boundary. It's absolute code and there are so many local sub subroutines in it, I can't easily extract it. In this particular code, I have to put "pagesel $" as the first line of the ISR, or I get a bad jump. I assume it is due to presence of this weird subroutine, but I can't understand why. Is it possible that the hardware is saving and restoring the address of the initial call and does not update itself when the subroutine crosses page boundary? But then I don't get how putting pagesel $ at the beginning of the ISR would fix anything.... yet it does. I treat the subroutine in question as a long call (I can actually call it locally from the first page, but pagesel $ after the call), and it works fine, except I have to put that pagesel in the ISR.
(I know this doesn't make any sense; the only way it can run that instruction is if it goes to the right page to begin with).
+1 Re: Mechatrommer. I accept that depending on context/POV, some things are not practical. But in theoretical argument it is maybe confusing to state as fact things which are dependent on theory of practical problems and further confusing when refuting something that is at least perhaps theoretically, if not empirically, correct as false, based on theoretical issue of what is practical.
-
Using 16F1xxx enhanced midrange. I happen to have an older code which has a long subroutine which wraps across page boundary. It's absolute code and there are so many local sub subroutines in it, I can't easily extract it. In this particular code, I have to put "pagesel $" as the first line of the ISR, or I get a bad jump. I assume it is due to presence of this weird subroutine, but I can't understand why. Is it possible that the hardware is saving and restoring the address of the initial call and does not update itself when the subroutine crosses page boundary? But then I don't get how putting pagesel $ at the beginning of the ISR would fix anything.... yet it does. I treat the subroutine in question as a long call (I can actually call it locally from the first page, but pagesel $ after the call), and it works fine, except I have to put that pagesel in the ISR.
The "call" and "goto" instructions require PCLATH set to the page which you're calling. A standard way of doing this:Code: [Select]pagesel Something
call Something
When you enter the ISR, it saves the old PCLATH (and will restore it when you return), but it doesn't load any new value. So, when you enter the ISR, PCLATH could be anything (whatever it was at the moment when the interrupt has happened). All the "goto" and "call" instructions which you do inside the ISR will use this random PCLATH. Therefore, if you have any "goto" or "call" inside your ISR, you need to make sure, the PCLATH is pointing to the destination of the "goto" and "call". I guess that's why you need "pagesel $" at the beginning of the ISR. Alternatively, you can use "bra" instead of "goto". It has shorter reach, but it doesn't require "pagesel".
-
^Ahh, ok. Good to know I'm maybe not crazy for putting pagesel $ in my ISR.
I thought it was due to this subroutine, but in hindsight perhaps just a factor of the first time I crossed over to page 1 in my life. And yeah, I put that pagesel there, everafter.
So ISR vector is special and pointer gets there without any paging address? I wonder if RESET vector the same? (I am putting "pagesel START, goto START" even when START is on page 0 but I'm not sure that's really necessary.)
These addresses are 0x0000 and 0x0004... and same addresses exist on page 1 (0x0800 and 0x0804) and every other page... I take it they reach reset and isr vector by pure hardware?
-
^Ahh, ok. Good to know I'm maybe not crazy for putting pagesel $ in my ISR.
I thought it was due to this subroutine, but in hindsight perhaps just a factor of the first time I crossed over to page 1 in my life. And yeah, I put that pagesel there, everafter.
So ISR vector is special and pointer gets there without any paging address? I wonder if RESET vector the same? (I am putting "pagesel START, goto START" even when START is on page 0 but I'm not sure that's really necessary.)
These addresses are 0x0000 and 0x0004... and same addresses exist on page 1 (0x0800 and 0x0804) and every other page... I take it they reach reset and isr vector by pure hardware?
The jump doesn't go to the page where the execution is at the moment. For example, if your code flows through the page boundary, it doesn't change anything. The program counter (PC) consists of two parts - high byte (PCH) and low byte (PCL). Say, when you execute at 0x0804, PCH is 0x08 and PCL is 0x04.
When you execute goto, such asCode: [Select]goto 0x0220
PCL is loaded from the instruction code (becomes 0x20 in this case).
The low 3 bits of the PCH are also loaded from the instruction code (0x02 in this case).
But the instruction is only 14 bits and doesn't have any room for more bits. So, the rest of the destination address goes from the special PCLATH register:Code: [Select]PCH = (3 bits from the instruction code) | (PCLATH & 0xf8);
PCLATH doesn't change by itself. Nor when you jump, nor when the code crosses page boundary. It only changes when you do "pagesel" (which is in fact movlp instruction which sets PCLATH) or explicitly write to PCLATH.
So, if you have any "goto" or "call" inside your ISR then you do need "pagesel" which will make sure that the PCLATH is set correctly for these jumps. Otherwise, they'll jump astray.
-
@northguy: i finally have a couple of 26k42 with the latest components order. What i'm interested at is to test
-IF the IVT can help me reduce the jitter in generating square waves with the timer countdown method... not that there is need to, i have microseconds jitter on a constantly changing 1-10 kHz signals (airflow sensor), though i have to adjust corretions factor to have a linear response over the entire range. It's more to amuse myself AND be ready for when i will actually need it
-IF with the DMA and ADC-Squared i can siplify the analog input routine and further slow down the processor
last one is more related to the topic: what if the inputs are changed by DMA in the middle of the routine
? Simple answer: i make a temp variable (hoping that a hardware (DMA)/compiler (Compiled stack) bug doesn't make the chip modify it)
dspic: was the latency that high? I know there's a higher latency from interrupt to code, but another 11 cycles for context switching? I remember that EP/EV has single cycle push+pop instructions, but they only save W0 to W3.
I shall take out the programmer's manual...
By the way I never use shadow registers/context saving as i always have more problems with them that the benefits i gain -
I went my round with TGZZZZ several months ago. It's matter of perspective, which I accept as assembly programmer of simple device, I have complete control over actual hardware limitations. So I see North Guy's perspective as valid. But if you are using RTOS, you are using more complex toolchain which you can't completely rewrite or circumvent with inline assembly unless you are in a very specialized business. Most people are paid to get a job done, efficiently. Not to fine tune tools to make tools specific to a given end product.
I agree with that.
In particular I agree with the concept that for very simple applications you can use many techniques. However, such techniques aren't necessarily scalable to larger and/or more complex applications. I believe it is important that people understand that.
The mechanical engineers get frustrated when people implicitly or explicitly expect that their application can be made with a few bits of string and sheet metal. This is an analogue of that!
I also agree that people are paid to get a job done and not to fine tune tools. That should be extended to finding bugs and subtle problems in tools, and inventing workarounds. -
PICs don't use extra cycles to store registers. They're stored automatically and restored back automatically. This is all done in hardware at the very moment the interrupt is taken. No single cycle is added.
PIC16F1* stores 8 different registers, which saves 16 instructions at the beginning of the ISR, which gives you 2 cycle latency (250 ns, or 166 ns on PIC16F14* which can use 48MHz clock). If you would do savings manually, it would give you 18 cycle latency - 4.5 us (plus 16 cycles when you leave the interrupt). 4.5 us is way bigger latency than 250 ns, so the auto-save is very important - it lets you achieve much higher performance.
How many times can they do that without restoring? Once like on a Z80 with its duplicate register set?
Being able to save and restore the entire register set is nice but what I usually do is rely on the ISR to save *only* the registers that it is going to use to save time which is neatly undone with a RTOS that lacks knowledge of which registers those are. Maybe if that matters, one should be using a faster processor.
The original ARM was designed with this in mind. Its pipeline and instruction timing was closely linked to fast page mode (or nibble mode?) DRAM allowing the multiple save and restore register instructions executed as quickly as possible.
-
@northguy: i finally have a couple of 26k42 with the latest components order. What i'm interested at is to test
-IF the IVT can help me reduce the jitter in generating square waves with the timer countdown method... not that there is need to, i have microseconds jitter on a constantly changing 1-10 kHz signals (airflow sensor), though i have to adjust corretions factor to have a linear response over the entire range. It's more to amuse myself AND be ready for when i will actually need it
If you want the best possible latency you need to eliminate everything which can negatively affect the latency. You cannot disable interrupts (because the time when they're disabled is added to your latency) and you need to make sure that there's no other interrupts on the same or higher level (because while these interrupts are being served yours is pending). Then, if you eliminate all other interrupts, IVT doesn't benefit you any more, but it does add 1 cycle to the interrupt latency (PIC uses the extra cycle to fetch the vector).
If you don't need very short latencies (which is usually the case) and you have many interrupts then IVT is very beneficial. It completely eliminates the code necessary to figure out which interrupt has happened. Thus it reduces latencies and jitter.
For the 1-10kHz signal you can use PWM. If PWM is impossible for some reason, then you can try to use CLC triggered by timer, although using CLCs usually takes some design effort.-IF with the DMA and ADC-Squared i can siplify the analog input routine and further slow down the processor
last one is more related to the topic: what if the inputs are changed by DMA in the middle of the routine? Simple answer: i make a temp variable (hoping that a hardware (DMA)/compiler (Compiled stack) bug doesn't make the chip modify it)
Usually, you can use some sort of ping-pong buffer. DMA writes to one half while you read the other half, then it switches.dspic: was the latency that high?
They run at 140 MHz (70 MIPS) but flash is the same speed, so it takes 4 or 5 cycles to fetch something from the flash. It needs to fetch the vector and then fetch the first instruction. Hence the latency.
-
let them try to define or impose on our reality with their own reality, its quite amusing watching from here. for us, their theories seems or sounds plausible yet confusing in multitude grade of levels, but above all, unproven or in another simpler word... nonsense... from a simple switch non blocking single cored code to multicores, parallelism, resources sharing, priority inversion, real time, ecosystem and whatever sheets thats going to be arised next... afaik most of those terms are very well defined and known since before our birth or probably since the invention of Babbage machine, then here they are come up with probably their own delusional meaning in this ever growing thread, just like the fate of the other threads.. the first rule of thumb is, when the slightest correlation between a noob thread and programming, you'll see long winded people with long winded theory try promoting this and that and how unholy C/C++ is... dont you ever try to correct the path to the laymen ship otherwise you'll be dragged away with all these confusing theories and will be doomed to look just like a fool... well... weekend is over... the fuck with the theories, we only care about practical and workable codes. we harness machines to do our jobs, not the other way around...
I have only read the first line and thought that it seems a baby who cries if someone points him on a different way to kick the ball. Do as you want, man. Never imposed anything. I have simply contributed with the hope that hearing our (avionics) experience was useful.
Wasn't? Have a basket of power-cords alone. -
Personally I'm more interested in, for lack of a better term, the philosophy rather than a specific implementation of the philosophy.
Hence my being "satisfied" by xCORE+xC.
Yup. Thought it can be useful for those want to see the fpga-implementation, and the only way is reading HDL source
-
How many times can they do that without restoring?
PIC16 has only one interrupt level, hence one shadow set. PIC18 K42 has two interrupt levels, so it has two shadow sets.Being able to save and restore the entire register set is nice but what I usually do is rely on the ISR to save *only* the registers that it is going to use to save time which is neatly undone with a RTOS that lacks knowledge of which registers those are.
If it stores them all automatically without taking any extra time, you don't need to work on deciding what to save and what not.Maybe if that matters, you should be using a faster processor.
What faster processor would you suggest which would give you 125 ns interrupt latency?
-
In particular I agree with the concept that for very simple applications you can use many techniques. However, such techniques aren't necessarily scalable to larger and/or more complex applications. I believe it is important that people understand that.
Any project has some level of complexity. You cannot make your project less complex than it is. You can, however, make it as simple as possible (but not simpler than that Einstein says). The simplest possible solution has more chances of being developed faster and cheaper and also has better chance of being scalable and maintainable.
-
Maybe if that matters, you should be using a faster processor.
What faster processor would you suggest which would give you 125 ns interrupt latency?
Well, one of these 4000MIPS (£25 unit price) processors will deal with up to 32 "interrupts" simultaneously within <100ns
If you want more, then you can add extra processor ICs at the cost of a little latency.
-
In particular I agree with the concept that for very simple applications you can use many techniques. However, such techniques aren't necessarily scalable to larger and/or more complex applications. I believe it is important that people understand that.
Any project has some level of complexity. You cannot make your project less complex than it is. You can, however, make it as simple as possible (but not simpler than that Einstein says). The simplest possible solution has more chances of being developed faster and cheaper and also has better chance of being scalable and maintainable.
I'm happy for people to suggest simple techniques and to note that they are limited to simple small applications. That's reasonable and valid.
I'm not happy for people to suggest such techniques and omit to mention that they aren't scaleable to interesting applications (interesting = non-trivial or complex or large). Any such omissions suggest a lack of experience/knowledge, and will probably mislead the inexperienced. -
I'm happy for people to suggest simple techniques and to note that they are limited to simple small applications. That's reasonable and valid.
I'm not happy for people to suggest such techniques and omit to mention that they aren't scaleable to interesting applications (interesting = non-trivial or complex or large). Any such omissions suggest a lack of experience/knowledge, and will probably mislead the inexperienced.
You really need to clarify what techniques you're talking about and what interesting applications your have in mind. Otherwise, it just doesn't make any sense.
So far we've seen 15MHz frequency counter on $30 MCU which you have built in just two days. This doesn't sound very interesting. Anyone can build 50MHz frequency counter with 60-cent PIC12F1501, and I cannot see how this can possibly take more than two hours.
-
his counter is scalable allright... a professor trying to teach 5 yrs old kids quantum mechanics, the kid may not come across this subject in his entire life ever, he just like to play music, and the proffesor keep giving hints that music is not good. not that quantum mechanic is not good, its just its not in the right place... btw, latency sometime is not applicable to some applications. no pun and no offense intended, i just find it amusing how some people took some subjects too seriously... i assume the OP has already found solution to his problem, so... there is no stopping rule from ever expanding this basic thread anyway...
-
Maybe if that matters, you should be using a faster processor.
What faster processor would you suggest which would give you 125 ns interrupt latency?
Solder and discrete logic. Or some programmable logic if you must.
PICs and similar microcontrollers are so inexpensive that there is some advantage to using them for single tasks instead of aggregating everything into one larger processor or FPGA allowing optimum interrupt latency. A small package can be deployed close to the interface not to lower latency but to ease layout considerations.
-
I'm happy for people to suggest simple techniques and to note that they are limited to simple small applications. That's reasonable and valid.
I'm not happy for people to suggest such techniques and omit to mention that they aren't scaleable to interesting applications (interesting = non-trivial or complex or large). Any such omissions suggest a lack of experience/knowledge, and will probably mislead the inexperienced.
You really need to clarify what techniques you're talking about and what interesting applications your have in mind. Otherwise, it just doesn't make any sense.
So far we've seen 15MHz frequency counter on $30 MCU which you have built in just two days. This doesn't sound very interesting. Anyone can build 50MHz frequency counter with 60-cent PIC16F1501, and I cannot see how this can possibly take more than two hours.
Advancing strawman arguments doesn't make you look good. The frequency counter was a trivial kick-the-tyres exercise to see if the tools lived up to their claims (they did).
I've mentioned various techniques in other posts; I suggest you re-read them. I'm not going to waste my life repeating them to people with a short attention span. -
I'm not happy for people to suggest such techniques and omit to mention that they aren't scaleable to interesting applications (interesting = non-trivial or complex or large). Any such omissions suggest a lack of experience/knowledge, and will probably mislead the inexperienced.
You really need to clarify what techniques you're talking about and what interesting applications your have in mind. Otherwise, it just doesn't make any sense.
I've mentioned various techniques in other posts; I suggest you re-read them. I'm not going to waste my life repeating them to people with a short attention span.
I don't really understand whether all of the techniques you mentioned in your 5226 posts are not scalable, or only some of them are not scalable? And if some of the techniques mentioned in your posts are not scalable and you omitted to disclose this, does it "suggest a lack of experience/knowledge, and will probably mislead the inexperienced"? -
But -correct me if I'm wrong- it makes having nested interrupts much harder because you'll need to save the context of the previous interrupt. The ARM7TDMI cpu core also has shadow registers but doing nested interrupts takes a lot of extra assembly. The ARM Cortex-M OTOH does need extra cycles at the beginning of the interrupt but it can deal with several interrupts at once without restoring the context in between and it can do nested interrupts as well. All in all that makes it a whole lot more flexible then having a set of shadow registers. Sure the latency is longer but who cares if you have peripherals with FIFOs and/or DMA capability (which in the end have better realtime performance than you can even achieve using software especially with multiple high priority tasks).^ This what I was thinking. Who cares if it automatically saves registers? Newer 8 bit PIC have automatic context saving. Older ones don't. Only difference to me is 6 lines of assembly, 3 in the beginning of ISR and 3 at the end. This is pretty much saying "new model has 6 extra words of instructions and 3 extra bytes of memory compared to older model." You can also conisder those resources are automaticallly reserved for isr, which deprives the user in case he didnt need them for ISR. This is nice to the programmer but not an actual improvement in specs.
If it did this in parallel to core processor which reduces latency, then that's different.
PICs don't use extra cycles to store registers. They're stored automatically and restored back automatically. This is all done in hardware at the very moment the interrupt is taken. No single cycle is added.
PIC16F1* stores 8 different registers, which saves 16 instructions at the beginning of the ISR, which gives you 2 cycle latency (250 ns, or 166 ns on PIC16F14* which can use 48MHz clock). If you would do savings manually, it would give you 18 cycle latency - 4.5 us (plus 16 cycles when you leave the interrupt). 4.5 us is way bigger latency than 250 ns, so the auto-save is very important - it lets you achieve much higher performance. -
I'm happy for people to suggest simple techniques and to note that they are limited to simple small applications. That's reasonable and valid.
I'm not happy for people to suggest such techniques and omit to mention that they aren't scaleable to interesting applications (interesting = non-trivial or complex or large). Any such omissions suggest a lack of experience/knowledge, and will probably mislead the inexperienced.
You really need to clarify what techniques you're talking about and what interesting applications your have in mind. Otherwise, it just doesn't make any sense.
So far we've seen 15MHz frequency counter on $30 MCU which you have built in just two days. This doesn't sound very interesting. Anyone can build 50MHz frequency counter with 60-cent PIC16F1501, and I cannot see how this can possibly take more than two hours.
Advancing strawman arguments doesn't make you look good. The frequency counter was a trivial kick-the-tyres exercise to see if the tools lived up to their claims (they did).
I've mentioned various techniques in other posts; I suggest you re-read them. I'm not going to waste my life repeating them to people with a short attention span.
I omitted to mention "interesting" applications, because I was wondering how to get the concepts over to someone that, presumably, has yet to encounter them.
"Interesting" applications are legion; there's no way to begin listing them. Instead consider some characteristics (from systems/applications I've developed) which frequently hint an application is non-trivial:- a need for formal validation and verification processes
- a bug costs a year's salary, and/or the re-spin latency is measured in agricultural seasons
- someone gets hurt if it fails; worse, someone dies when it works as designed
- remote operation in unattended buildings that you don't have key access to
- high availability, where parts of the system will fail in normal operation, and the system must continue to function 24/7
- development teams split across continents
- development teams split across companies
- customers that throw chairs at FSEs when the product doesn't work as they were expecting
- there is a probability that during commissioning different companies will attempt to shift blame onto other companies, and their lawyers are ready and waiting
- enhancements will be made over many years, and the development team has departed for pastures new
-
I'm not happy for people to suggest such techniques and omit to mention that they aren't scaleable to interesting applications (interesting = non-trivial or complex or large). Any such omissions suggest a lack of experience/knowledge, and will probably mislead the inexperienced.
You really need to clarify what techniques you're talking about and what interesting applications your have in mind. Otherwise, it just doesn't make any sense.
I've mentioned various techniques in other posts; I suggest you re-read them. I'm not going to waste my life repeating them to people with a short attention span.
I don't really understand whether all of the techniques you mentioned in your 5226 posts are not scalable, or only some of them are not scalable? And if some of the techniques mentioned in your posts are not scalable and you omitted to disclose this, does it "suggest a lack of experience/knowledge, and will probably mislead the inexperienced"?
All you have to do is look at my earlier postings in this thread. That's not too difficult is it? -
But -correct me if I'm wrong- it makes having nested interrupts much harder because you'll need to save the context of the previous interrupt. The ARM7TDMI cpu core also has context switching but doing nested interrupts takes a lot of extra assembly. The ARM Cortex-M OTOH does need extra cycles at the beginning of the interrupt but it can deal with several interrupts at once without restoring the context in between and it can do nested interrupts as well. All in all that makes it a whole lot more flexible then having a set of shadow registers. Sure the latency is longer but who cares if you have peripherals with FIFOs and/or DMA capability (which in the end have better realtime performance than you can even achieve using software especially with multiple high priority tasks).
PIC16 doesn't have nested interrupts. Theoretically, you can do it in software, but it is so inefficient that it certainly isn't worth it.
PIC18 has two levels of interrupt, high priority and low priority. Correspondingly, K42 has two sets of shadow registers. If a low priority interrupt happens, it saves the context into the shadow register set designated for low priority interrupt. If a high priority interrupt happens, it saves the context into its own set of shadow registers. The nesting is completely seamless. High priority interrupts don't feel any delays from low priority interrupts being executed.
PIC24/dsPIC33 have 7 levels of interrupts, but don't have so many register sets. You have to select which interrupt levels get shadow registers and which don't. But the nesting is still seamless - higher priority interrupts can pre-empt lower priority interrupts at any time - no extra assembler is necessary to ensure this.
Older PIC32s (MIPS) required some quite extensive code at the beginning of the interrupt before it could enable the interrupts back, which would hurt latency dramatically. In PIC32MZ and PIC32MK, they switched to microAptiv MIPS. It appears that it has processor ASE extensions which are supposed to fix this and make nested interrupts quicker, but the C compiler doesn't seem to support this yet. When such support is added, they promise 50ns latency, but I haven't looked into this in details. The microAptiv core has several sets of shadow registers too.
Of course, this all is mostly to decrease the latency. If the latency doesn't matter for the application then the shadow registers are not as important - everything can be saved/restored by software just as well (C will generate the code).
-
I omitted to mention "interesting" applications, because I was wondering how to get the concepts over to someone that, presumably, has yet to encounter them.
"Interesting" applications are legion; there's no way to begin listing them. Instead consider some characteristics (from systems/applications I've developed) which frequently hint an application is non-trivial:- a need for formal validation and verification processes
- a bug costs a year's salary, and/or the re-spin latency is measured in agricultural seasons
- someone gets hurt if it fails; worse, someone dies when it works as designed
- remote operation in unattended buildings that you don't have key access to
- high availability, where parts of the system will fail in normal operation, and the system must continue to function 24/7
- development teams split across continents
- development teams split across companies
- customers that throw chairs at FSEs when the product doesn't work as they were expecting
- there is a probability that during commissioning different companies will attempt to shift blame onto other companies, and their lawyers are ready and waiting
- enhancements will be made over many years, and the development team has departed for pastures new
Like this: https://gizmodo.com/the-f-35-amazingly-has-even-more-problems-than-we-thoug-1791285476
Such applications could be interesting technically, but there's a pale cast of government bureaucracy, high politics, special interests etc. But of course, the same laws of physics apply to these too. It's all top secret, so it's hard to tell what methods they're using, but whatever they're doing doesn't seem to be working very well. -
Quote
PIC16 doesn't have nested interrupts. Theoretically, you can do it in software, but it is so inefficient that it certainly isn't worth it.
If some of your ISR are very long, you can put periodic checks in them at convenient locations to check flag and have them CALL other ISRs. This doesn't result in an instant response, so adds some variable delay. And it only works if you are careful to identify and sort out any memory conflicts. The memory conflicts are not necessarily overwhelming. It depends on what the ISR's are doing. They might be completely unrelated and/or use not much memory. This would be unusual situation perhaps, and you won't get nanosecond latency, of course. Unless you were doing this check/poll at super high speed in a "dead delay" such as waiting for ADC pin to stabilize(Leave it to imagination why you would be doing this in an ISR, but I've done ADC read in ISR, yeah).
I normally write my ISR as series of subroutines called by the main ISR in series, anyway. If one were to be called by other ISR, it is self-contained. If/when it gets called again in the main ISR, it will be serviced, already, and the ISR will move on to the next in line, down the checklist.
Unless you have a single interrupt in any given priority level, first thing ISR has to do is check if it is enabled and triggered, anyhow. Theoretical minimum latency based on hardware is only going to be achievable in this scenario. Using PIC with single interrupt priority level this is a rare luxury.
Back to topic, though: I think EE's and hobbyists have more varied interest than just ballistic missile guidance systems. I agree to some extent that as you work with more complex device and tools, it rarely makes sense to go back to more basic strategy/tools. If you can do the job with 100x more memory and transistors and multiple layers of software, why "relearn" how to do it more directly? You have worked so hard to learn the "best" way to do things with the complex tools and devices. But when you mention bugs which take years to sort, maybe it's partly because you are relying on all these layers for too many things... We landed people on the moon without 32 bit microprocessors and fancy compilers.