Reputation: 1
I am developing a programming language.In that,I am obliged to make a design decision.The decision, whether to implement methods as a functionality(which would render the language as Object Oriented.
My objective is to compile this language to a format compatible with handhelds,the likes of arduboy nano and fx.
Thus,I am wondering, whether using method calls will have any significant effect on the performance
I haven't tried anything as of now.I am uncertain for the methods to be considered for testing the performance,since I do not own an arduboy or a handheld with similar specs. I have tried looking for opinion on the internet,but found none.
The official GitHub repo seems to be written in C.Thus,it isn't object oriented,owing to which it lacks the use of methods.However,this do not conclude that methods have any significant performance impact(i.e. drop in framerate)
Upvotes: -1
Views: 56
Reputation: 213266
I am developing a programming language.
As a prerequisite to doing so, it would perhaps be advisable to study existing programming languages like C and C++ and how they translate source code to machine code.
whether to implement methods as a functionality(which would render the language as Object Oriented.
There is no such thing as "object oriented languages", there are just languages with more or less support for OO features. Object orientation is a way to design programs. Your program does not automatically turn object-oriented because you use a certain language.
The pillars of fundamental OO are private encapsulation, autonomous objects and inheritance/polymorphism. None of these require member functions as such, although they are obviously very handy to have. As as RAII with constructors/destructors, but that's still no requirement for OO design.
whether using method calls will have any significant effect on the performance
That depends on the context. A plain static
C++ object does not come (should not) with additional overhead for calling a member function, compared to an ordinary function. The only extra overhead that you might get from such objects is the default constructor getting called by the CRT.
In a design using inheritance/polymorphism, you'll need vtables in between no matter language, and these come with a slight memory and function call overhead. They might also block function inlining in some situations. I wouldn't call it a "significant" effect on performance, but it is extra overhead.
Generally one stayed clear of such things in tiny legacy microcontrollers like ATMega 8-bitters, mainly because RAM was very tight. Writing C code for such MCUs was a novel thing even - in the 1990s the majority of these programs were written in assembler and the general switch to C happened in the early 2000s, around the time when Arduino was released. Some 5 to 10 years later, 8-bitters had mostly gotten phased out from new designs.
The official GitHub repo seems to be written in C.Thus,it isn't object oriented
This isn't necessarily true. It is perfectly possible to write OO programs in C, just like it is common to not write OO programs in C++ - the keyword class
doesn't magically turn the program design OO.
However, 8 bit microcontroller programming is/was usually done with a minimum of abstraction layers, because these MCUs were so dreadfully slow. "Framerate" is probably not a thing on anything running from an 8-bitter; these do not typically have DMA even.
Upvotes: 0