The wonderful world of compilers



  • So in your normal desktop space you have GCC or LLVM in widespread usage and it's unheard of to ever use anything else.

    Now in the embedded space, things are a different story.

    You see...we have these...."compilers". We do have the choice of gcc for most micros but when it comes to companies they want enterprise! So there is proprietary trash that you have to license. And generally most of the time they are ok. Except for one....whose terror none of you know.

    Microchip's XC8.
    It is the compiler for PIC16 and PIC18 microcontrollers. In fact, there is a deeper fundamental issue with these micros. Their internal architecture is so broken, NOBODY can easily make a compiler nor really wants to bother. Because you would have to write a custom assembler for every single fucking micro of the family because of how bad things are.

    But to describe XC8 is like to describe a person in a mental institution.50% of the time, code compiles fine. 25% of the time it can't compile code correctly but it obviously doesn't work, the other 25% of the time...the code works but the assembly is wrong in some subtle way which is terrifying.

    So this goes down the path of realizing that XC8 is not a deterministic compiler at all. In fact I am absolutely terrified about any of my company's products built using it failing in some weird edge case where a bug got compiled in by the compiler itself.

    List of fun bugs:
    It flipped the padding word endianness in the output hex file. Their tech support at first acknowledged the word value was wrong and then proceeded to argue with me on the compiler was doing it right. Their fix ETA was 1 year from the conversation in the next release.

    The list of bugs they fix is more terrifying than the bugs I counter, here are some:

    Incorrectly initialized structures (XC8-1057) For PIC18 devices, when initializing structures
    that contained a char array with a string less than the size of the array, the initialization
    may have caused structure members following the array to be corrupted.

    Yes, somebody actually broke their compiler to the point it wasn't using the struct declaration as the structure declaration

    Bad short long addition result (XC8-1052, XC8-1064) For PIC18 devices, the result of short
    long additions when the operands were in different banks may have been incorrect.

    Yes, in this compiler 1+1 does equal 3

    Wrong bank selected with complement (XC8-1035) In some cases for PIC18 targets the copiler was selecting the wrong bank when performing a bitwise complement of a word-sizedobject in banked memory

    Yes it couldn't complement correctly.

    Program resets (XC8-970) Under some circumstances inlining nested functions calls might
    have resulted in a call to reset and program failure

    Yes, doing an inline fucking function somehow caused the compiler to insert RESET op codes. How does this happen? Fucking wonderland.

    Incorrectly merged code (XC8-924) When a statement in the true part of an if statement and a
    statement in the false (else) part was the same except for a conversion (cast) of a symbol,
    the compiler might incorrectly consider these statements identical and merge the generated
    code.

    So that's why my code was break pointing oddly(I'm serious)

    Bad right shift (XC8-938) For all devices, some expressions involving a right shift of an unsigned object that was cast to be a signed object, might have produced an incorrect result.

    Yes, it couldn't keep up with typecasts and failed to do shifts properly.

    Another one that also made me rage extremely hard and loudly. If I inserted two levels inside a function explicitly labeled as inline, the inner most if statement never got compiled into the assembly. I visibly saw it was missing from the assembly list. If I removed the inline attribute, it got compiled in.

    I could go on for fucking PAGES about this trash.

    The wonderful part is this is supposed to be a production quality tool. I can't believe we continue to use this trash brand of micros and their tools.



  • I feel for you. For those who have never used this poor apology for a "tool", @delfinom is merely scratching the surface of the horrors it hides.

    We moved away from PIC16 for exactly this reason.



  • If only I could move away so easily.
    My company has 1 ex-microchip employee who is a Bible nut not just for Jesus but for microchip. Then we have one engineer who thinks reusing designs with a shit micro makes the job of the embedded engineers easier (to the contrary). And then we have the guy in management who has this whole "pride" and "honor" bullshit about sticking to certain vendors.


  • šŸš½ Regular

    We've moved entirely to ST now for jobs that don't require much processing power and/or are cost-sensitive. This means we won't use Microchip at all now as other manufacturers fill our need for the higher end.

    The ST parts are nice to use and the pricing we are getting on their 8-bit value life is literally about half what we get from Microchip on their value lines (with close feature parity). We were a decent sized customer as well.

    TBH the errata for the silicon bothered me more on Microchip than the compilers, some of the PIC24 errata was a bloody joke. I can't remember the specifics for the best/worst one but it was along the lines of 'the part may execute a totally random instruction under a common use case that will likely occur in your program'... :headdesk:



  • My ninja group has moved to Atmel. I love their shit and their support and FAE cater to my every demand. I hate ST for their complete lack of documentation when you need, doxygen only goes so far. ST's approach, here's an USB stack, here's a datasheet on the registers.What's that? You want a diagram for the USB state handling for our peripheral? Haha, good luck bro. What's that, you want to use code compatible with GCC instead of wasting money on IAR? What's this "GCC" you speak of?


  • šŸš½ Regular

    It was a bit of a shock moving from Microchip's datasheets and Family Guides to ST's documentation that's for sure. I hadn't appreciated until then that, on the whole, Microchip's documentation was pretty good.

    Thankfully there's not very much in the STM8 parts to need reference on.

    Is your group using the new M0+ parts? I went on an Atmel training day and was very impressed but haven't had a chance to use them in anger yet.



  • @delfinom said:

    What's that, you want to use code compatible with GCC instead of wasting money on IAR? What's this "GCC" you speak of?

    You don't have to put up with the ST vendor libs... here, try something that actually will work with GCC instead

    @delfinom said:

    My ninja group has moved to Atmel. I love their shit and their support and FAE cater to my every demand.

    But on the other hand...the AVRs are quite fine parts as well (if a bit costly), and Atmel is also one of the long time players in the ARM space with the ATSAM lines (which date back all the way to the ARM7 days!). Also, the full Atmel datasheet on a part has basically everything you ever wanted to know about it (less scrambling around for docs, hooray!). Only downside is that their current IDE is VS-based, so that leaves Linux and Mac IDE-less, not that that's a huge deal (both AVR and ARM Cortex-M are well supported in upstream GCC, which is another thing Microchip fubars completely).



  • @delfinom said:

    In fact, there is a deeper fundamental issue with these micros. Their internal architecture is so broken, NOBODY can easily make a compiler nor really wants to bother.

    As an embedded systems programmer there are some architectures you can look at and just know that compilers were simply not on the chip designers' radar.

    6502 is one of them. 8048 is another. But PIC? PIC is so not for high level language programmers. PIC is for people who fancy themselves as modern-day Mels.



  • @Cursorkeys said:

    It was a bit of a shock moving from Microchip's datasheets and Family Guides to ST's documentation that's for sure. I hadn't appreciated until then that, on the whole, Microchip's documentation was pretty good.

    Thankfully there's not very much in the STM8 parts to need reference on.

    Is your group using the new M0+ parts? I went on an Atmel training day and was very impressed but haven't had a chance to use them in anger yet.

    Actually yes, I have had the chance to use the D20s for the last year from it was in sampling. I am switching to a D21 on a design in the next week when a new board rev arrives. They are wonderful and awesome. It works cleanly. Documentation is great. They have been doing a great job knocking off errata items and updating their code libraries as issues arise. (Did I mention their code libraries for all their chips are git revision controlled by them instead of arbitrary zip file downloads off a website like ST?)

    I love being able to do "real" C with the capabilities/performance of a 32-bit processor but at the price level of a higher end 8-bit micro.

    There are more M0+ parts coming this year that I am privy to and they are only getting better. :)


  • BINNED

    Bah, kids and their Cs and GCCs and fancy ifs and loops.

    In college I programmed ARM in assembly. On paper. In the cold. In a third floor classroom without a lift in the building!


    Filed under: True story (ok, the heating did work), Also, used assembly a "special" CPU that doesn't exist outside of a simulator, I swear they only invented that one so we can't use MUL



  • I haven't done actual assembly in years. Bits of Z80, bits of 68000 for Spectrums and Amigas, but nothing useful or modern.


  • BINNED



  • @tarunik said:

    You don't have to put up with the ST vendor libs... here, try something that actually will work with GCC instead

    oooo, I may try it. I have an accidental one off design that used an STM32f1 that was never finished. Needless to say that's when I discovered how awful they were at documenting a USB stack.

    @tarunik said:

    @delfinom said:
    My ninja group has moved to Atmel. I love their shit and their support and FAE cater to my every demand.

    Only downside is that their current IDE is VS-based, so that leaves Linux and Mac IDE-less, not that that's a huge deal (both AVR and ARM Cortex-M are well supported in upstream GCC, which is another thing Microchip fubars completely).

    Honestly, I love the VS based IDE. I absolutely fucking hate the Eclipse based garbage companies put out. I can't pull global company libs because Eclipse has this hardon for including all files automatically into the project compilation. Smart companies eliminate that nonsense and others dont. Of course I could disable that option in standard eclipse but then I have to start making Makefiles manually and that defeats the point of an IDE. At that point I rather use command line.

    I will say on the topic of IDEs, Microchip did make a great choice in using Netbeans for their MPLABX. But that's the only good choice they made.



  • @Onyx said:

    Bah, kids and their Cs and GCCs and fancy ifs and loops.

    In college I programmed ARM in assembly. On paper. In the cold. In a third floor classroom without a lift in the building!

    Like a ninja in the night, Hanz M., AKA Hanzo, stalks across Hesse Universityā€™s Dresden campus. The go-to man in the IT department, he fixes the messes that others leave behind. These are his stories.

    It was a cold winter's night in Hesse, and the Computer Science department (which included the IT department's offices) was mostly dark. Only one light illuminated one room in the building, and that room was empty, except...

    Hanzo was used to getting callouts for problems, but nothing like this one. In the middle of the night he was awakened from his ninja slumber (Hanzo sleeps upside down above a bed of nails to keep his ninja senses strong) by a frantic call about all of the Computer Science building's power being out, it seemed that some low born student (all ninjas are members of wealthy families from high society) was trying to complete his Assembly course project, the night before the deadline (again) without having attended lectures (again). Every year there was at least one, and every year it ended up causing Hanzo problems.

    He acknowledged the call-out, dressed, and quickly grabbed his tools, screwdrivers, wire-clips, ninja-stars (Hanzo knew their true name, but wouldn't share it with the uninitiated), and his mighty katana. Some problems require the finesse of a screwdriver, and some require a silent slash of the throat from a blade unseen.

    On arrival at the building, he could see from the outside that the power was definitely out, not a single light was on, the building was in pure darkness, the perfect environment for a ninja to do their work. treading silently but swiftly, Hanzo padded into the building, within seconds his lithe frame was investigating the circuit breakers, as he had expected (not feared, for ninjas have no concept of fear), one of the fuses had blown, and would need replacing. Thankfully, Hanzo was always prepared. Spare fuses were kept on the third floor of the building near the classrooms. He contemplated the route for a fraction of a second and then - like a passing shadow - silently sped to the third floor.

    The department had no lift, they had been sent to one of the older buildings of the campus, but this did not trouble Hanzo, not only would the lift not function without power, but Hanzo always travelled on foot, trusting his guile to keep him unseen and unheard, far more than the machinations of others. on reaching the staircase, he bound from handrail to handrail like a silent invisible acrobat, and scaled to the third floor faster than anyone would have thought possible, for that was his way of the ninja.

    On reaching the third floor, he headed silently for the storage room, when he heard screaming and thumping coming from one of the classrooms. A moment of realization struck him, and he knew he would have to wait with the fuse for now. A more important task awaited him. He silently drew his katana and prepared for what was to come.

    He silently crept along the corridor, katana ready but kept in the shadows, a true ninja knows to keep his blade ready, but avoid any light that could glint off the blade and alert their target, the screaming and banging and sound of smashed furniture got louder as he proceeded, and he knew the last room was where his target awaited. He didn't know how long the student had left, but he couldn't risk being detected to soon.

    He approached the door and immediately realized that it was blocked by smashed furniture, several desks flung indescriminately had piled infront of the door, there was no way to make a silent entrance through there, thankfully, the ceiling panels could be silently lifted aside, the perfect entry point for a ninja. For Hanzo was a ninja, an IT ninja.

    He slowly crawled through the ceiling until he was above the classroom, and silently lifted aside a ceiling panel, and confirmed his suspicions. An errant server Daemon had been released when the servers went down in the power outage, and, having sensed human flesh nearby, had attempted to devour the still warm soul within and permanently free itself from servitude. This was not the first time Hanzo had dealt with such a beast, and it would not be the last.

    Preparing his katana, he silently waited for the perfect opportunity to strike. The beast was slow and clumsy, having spent so long managing system processes, but in the limited room the student only had so many places he could run. Eventually the beast was passing directly below Hanzo, and he struck. In less than a second he dropped from the ceiling, katana raised, and instantly separated the beast's head from it's shoulders. It fell to the floor dead.

    The student stared at Hanzo in wonder, he looked back silently, before stepping backwards into a shadow, and disappearing the way he had come. He silently fetched a fuse, descended the stairs to the ground floor, fitted it and restored power to the building. The fluorescent lamps burned away the corpse of the daemon as they turned on, leaving no trace. Another would take it's place during system start-up, and no one would believe the student if he mentioned it, he might not even believe himself. Hanzo returned to his home, and slept the rest of the night.

    Meanwhile, the student, terrified of what had befallen him, pulled paper from a tray nearby and fled for a room as far from computers as possible. Having failed to grab a pencil, he cut his finger, and finished his thesis in his own blood. The room was cold and unheated, but at least it was not trying to kill him. He finished his thesis and submitted it on time, but was marked down as his submission was a biohazard.

    To this day, he still tells the story, at least, the parts he thinks people will believe.


  • BINNED

    +1, would read again, only one complaint:

    Couldn't you do it while I was still sporting the Hanzo name in my "long name" field?

    Bastard.



  • Ninjas are not supposed to advertise their presence.



  • @delfinom said:

    I absolutely fucking hate the Eclipse based garbage companies put out.

    Amen to that, brother.

    It's all more usage for the barbed-wire wrapped umbrella, though.



  • @Onyx said:

    In college I programmed ARM in assembly. On paper. In the cold. In a third floor classroom without a lift in the building!

    Filed under: True story (ok, the heating did work), Also, used assembly a "special" CPU that doesn't exist outside of a simulator, I swear they only invented that one so we can't use MUL

    Manually disassembling ARM instructions as they flow through the (simulation of the) processor's fetch-execution pipeline, trying to figure out what's causing the simulation to crash-and-burn.



  • @algorythmics said:

    Hanzo

    I feel like I should post my next one as a "reply as new topic". I don't feel like it gets sufficient attention in this format.

    Or badges.

    I will write a new one next week people! keep posting things and maybe YOU will be the lucky one to get GERNified (as @keith puts it)

    this thread is no longer about compilers.



  • @algorythmics said:

    this thread is no longer about compilers.

    Unless you write a compiler to translate regular text into a GERNifiedTM Ā© Ā® representation. This would save you time in the long run.



  • it would, but that would require a level of intelligence that direct gernification does not, and I do not have it.

    Maybe someday someone will write such a compiler, and put me out of an unpaid job, but until then, I will manually make these mundane masterpieces of melodrama.

    Many a humorous chuckle will I draw from my avid readers, many an "Oh Hanzo, you knave!" will they cry in their mirth as they read. Many a president's daughter will they learn nothing about, and many a WTF will not quite make it into the final text due to detracting from the story.


  • Fake News

    @algorythmics said:

    many a WTF will not quite make it into the final text due to detracting from the story.

    Since when has Erik Gern left out a WTF from a story to keep it readable? You must be doing it wrong.



  • @JBert said:

    Since when has Erik Gern left out a WTF from a story to keep it readable?

    Granted, he doesn't do anything to keep them readable. And while he doesn't usually leave the WTF entirely out of the story, the story itself becomes the WTF, with the original WTF getting lost in the noise.



  • @tarunik said:

    Only downside is that their current IDE is VS-based

    Downside? I need to try it out, maybe I'll finally see a decent IDE for uCs. So far, I've been struggling with TI's Code Composer Studio, with... varying results.

    And yep, we use MSP430 boards in college, which we had to order by ourselves (they're cheap, sure, but still...). We wanted to do Arduino, but nope.

    And it was all fun as far as blinking LEDs was concerned, until the time came to do a fairly serious project using uCs, and suddenly having the whole of 14 usable I/O pins turned out to be quite... limiting.

    @Onyx said:

    In college I programmed ARM in assembly.

    In college, I programmed 8080 with buttons.


  • BINNED

    @Maciejasjmj said:

    In college, I programmed 8080 with buttons.

    Ok, you win this one,



  • @Maciejasjmj said:

    In college, I programmed 8080 with buttons.

    I do that these days. Although I call them keys.



  • @Maciejasjmj said:

    Downside? I need to try it out, maybe I'll finally see a decent IDE for uCs. So far, I've been struggling with TI's Code Composer Studio, with... varying results.

    And yep, we use MSP430 boards in college, which we had to order by ourselves (they're cheap, sure, but still...). We wanted to do Arduino, but nope.

    And it was all fun as far as blinking LEDs was concerned, until the time came to do a fairly serious project using uCs, and suddenly having the whole of 14 usable I/O pins turned out to be quite... limiting.

    @Onyx said:

    In college I programmed ARM in assembly.

    In college, I programmed 8080 with buttons.

    FYI
    I suggest this guy to play with it:
    http://store.atmel.com/PartDetail.aspx?q=p:10500372#tc:description
    (Has an embedded debugger/swd)
    And Atmel Studio is 100% free unlike CC Studio ;) It's GCC based anyway.

    There's some minor bugs with their implementation of the VS Shell but overall it's just like the normal VS experience :)

    You have no idea how beautiful it has been this week for me when I took a board, populated some extra resistors I had placed in the layout. Then it took only about 5 minutes to select their USB stack in the IDE, edit the config and BAM. I now have USB from effectively no USB at all with zero headaches. Their code framework is great, the USB stack has the same API as their 8-bit micros meaning I can effectively upgrade between micros with minimal porting effort. Same applies for all other APIs as well. I can transition between AVRs, M0s,M3s,M4s with relative ease. (Not always 100% the same).


  • BINNED

    Looks like more fun than raspberry pi!



  • Well these are lower level and much simpler than Raspberry Pi so not quite the same to compare depending on application.



  • I did about a year of firmware before leaving to work from home.

    We used Rowley CrossWorks, which was actually quite a good experience. It used GCC underneath, and built a nice GUI on top of it. You could also extend the debugger with JavaScript, though it was slow going through a JTAG port.

    I am so glad that when I started firmware we used Atmel. Their documentation is absolutely superior. We changed to an STM chip - which has (almost) sufficient documentation though it's spread through many documents instead of just one like Atmel does quite nicely. STM also was very slow in publishing known errata, while Atmel kept theirs up-to-date.

    Sadly, I know a guy who's working on the LLVM compiler. Seems like such a waste; the only reason they're working on it instead of improving GCC is because of GPLv3.



  • @StephenCleary said:

    We used Rowley CrossWorks, which was actually quite a good experience. It used GCC underneath, and built a nice GUI on top of it. You could also extend the debugger with JavaScript, though it was slow going through a JTAG port.

    You could also extend the debugger with JavaScript
    extend the debugger with JavaScript
    JavaScript

    wut
    the
    fuck



  • I know. It sounds crazy. But it worked. :)


  • BINNED

    Yah, very true but I like futzing w/ stuff like that. My first "computer" was built from a mail order kit ages ago. Amtel's stuff looks very DIY in the most fun way.



  • Aye, I am going to sound like a shill at this point but that's their mindset per say (their fae/sales guy keeps saying so at least hehe). They have a huge backing from the Ardiunos and absolutely know they have to stay true to what people love to grow business and keep it. But generally it is why I love their stuff, an embedded project isn't some monstrous forty document of reading system design exercise, it's just one manual.

    Did I also mention since its relevent to the original topic of Microchip being inept, that Atmel actually reuses peripherals between all their families? Fuck, Microchip couldn't manage to reuse the same peripheral in the same fucking chip but different package in some cases(1 example: DIP/SSOP packages which are bigger are missing I2C peripherals but the smaller die QFNs didn't WTF)


  • BINNED

    @delfinom said:

    I am going to sound like a shill at this point

    No worries :) I've now got their website open, and I'm making a list and checking it twice... Now to shake loose some cash from my "allowance"... ( budget, budget, budget...)



  • @delfinom said:

    I absolutely fucking hate the Eclipse based garbage companies put out.
    ā€¦
    At that point I rather use command line.

    And then you find you can't. At work I have multi-mobile-platform project that uses CMake, from which the build server can cut releases on all platforms easily. Except for this Bada. They provide this crappy Eclipse-based IDE and the compiler is (somewhat misconfigured) gcc. So let's just tell CMake we want that compiler and build manually, right?

    Well, no; it compiles, but it refuses to package. The packaging tool does have a command-line, but it looks in the Eclipse workspace for some weird files the IDE somehow creates by inspecting the sources. So no way of building it without the IDE.

    So we generate a library containing everything except one tiny source from the CMake-generated makefile and have a project including that one file and the library. It spews a lot of warnings that we don't need this and that permission (because they are used in the library and the tool does not see there), but it successfully packages. Never managed to get this working on the build server (where we build all other releases). Oh, yeah, we did try asking support. No, they were not helpful, thanks for asking.

    Thank $DEITY that platform is dead now, so we will be able to drop the support for that POS soon.



  • @delfinom said:

    You could also extend the debugger with JavaScript

    extend the debugger with JavaScript

    JavaScript

    wut
    the
    fuck

    Considering that stock GDB supports Python(!) scripting these days, is this really a WTF? Or are you saying that being able to script your debugger in the first place is the WTF?



  • Web scripting language intended for user interfaces/interaction, in a bloody C language debugger.



  • @delfinom said:

    Web scripting language intended for user interfaces/interaction, in a bloody C language debugger.

    Well, you're conflating the DOM (the HTML/Web part of JS) with JS-the-language, as so many are wont to do...I think JS with an apropos set of APIs for the job is not unreasonable for scripting a debugger. Besides, debugger scripting is rather event-driven, no? So a language that got a lot of support for event-driven-programming from the UI world makes some sense...


  • BINNED

    Works nice mixed with QML at least. Now, granted, QML is kinda DOM-ish (but with less WTF), but I think it shows that JS can be used in general sense pretty well.

    I don't know how well it works there, but Unity uses JS as well, doesn't it? Or a modified version at least.



  • @delfinom said:

    Web scripting language intended for user interfaces/interaction, in a bloody C language debugger.

    JavaScript is a scripting language. It was never designed specifically for the web, and many apps use it as originally intended. The biggest one being Microsoft Windows (in the form of JScript), but there's also Flash (ActionScript is JavaScript), and I know the Fiddler web debugger uses it for scripting as well.



  • @flabdablet said:

    PIC is for people who fancy themselves as modern-day <a href="http://www.pbm.com/~lindahl/mel.html">Mels.</a>

    I love it. I came here to say I do all my PIC programming in assembler and it seems I chose a product line that's suited for doing just that. I've never considered writing my PIC code in C because I just assumed I would never get it to fit in 2K of code space.

    Disclaimer: I only do really trivial stuff on embedded platforms like read an A/D port and store the data to EEPROM or activate one of a series of relays based on some logic applied to the state of the inputs.



  • @Jaime said:

    I love it. I came here to say I do all my PIC programming in assembler and it seems I chose a product line that's suited for doing just that. I've never considered writing my PIC code in C because I just assumed I would never get it to fit in 2K of code space.

    Disclaimer: I only do really trivial stuff on embedded platforms like read an A/D port and store the data to EEPROM or activate one of a series of relays based on some logic applied to the state of the inputs.

    You are insane.

    Why would you write assembler with an architecture that still uses banked memory in the year 2014?
    There are real RISC architecture chips, <=2kb flash and cheap as hell for the last decade.


  • I survived the hour long Uno hand

    The node.js ecosystem is also helping to boost the popularity of non-web JS



  • Yah but it's a johnny-come-lately. JScript and ActionScript have been around for decades, what's pathetic is how few software developers know JavaScript can be used outside the web.



  • @blakeyrat said:

    Yah but it's a johnny-come-lately. JScript and ActionScript have been around for decades, what's pathetic is how few software developers know JavaScript can be used outside the web.

    I have multiple interfaces written in JS that are basically applications with nothing to do with the internet or networks. It's just debuggers are meh, different.



  • @delfinom said:

    You are insane.

    Why would you write assembler with an architecture that still uses banked memory in the year 2014?
    There are real RISC architecture chips, <=2kb flash and cheap as hell for the last decade.


    Thank you for noticing. PIC is my platform of choice for practicing my insanity. If I switched to a saner platform or a higher level language, then I would have to find another outlet for this particular from of insanity. I really do look for reasons to read datasheets.

    For example... I'm currently building a custom car using a wrecked car a source of parts. I could have easily kept the box that runs the interior lights and buzzers (the Body Integrated Controller), but I chose to build my own so that I could get exactly the dimming behavior I wanted. Well, that's what I tell everyone is the reason, really I'm just doing it because I think it's fun.

    The on-topic part of this is that I chose this platform because I'm sadistic and I have a decent stock of PICs that I bought like a thousand years ago. I think that is a perfect validation of your opinion that this platform isn't suitable for professional use.



  • The scary part is "thousand years ago". As recent as 8 years ago their chips still required old school style emulators to debug....


  • Discourse touched me in a no-no place

    @blakeyrat said:

    what's pathetic is how few software developers know JavaScript can be used outside the web.

    Which is kinda funny given how long Microsoft's provided a standalone JS engine. (Yes, yes, I know it's JScript, not JavaScript, unless they dealt with that at some point.)



  • @FrostCat said:

    Which is kinda funny given how long Microsoft's provided a standalone JS engine. (Yes, yes, I know it's JScript, not JavaScript, unless they dealt with that at some point.)

    JScript is based on the ECMA standard for JavaScript, it's like 98.99% compatible.

    There are some constructs you can do in JScript that you can't in JavaScript. For example, in JScript this works:

    var gebi = document.getElementById;
    gebi("test"); // works
    

    That doesn't work in JS proper.


Log in to reply