Thread: Gumberoo - Making a new learning language intepreter using FPC

Since I'm planning on it being openGL aware, 32 bit floating point is likely the best minimum once rotations, gravity, momentum and drag are in the equation, much less the notion of resolution independent rendering. I considered single precision since that's what glFloat is guaranteed to be
OK I understand that when you are dealing with graphics and physics having 32 bit or 64 bit numbers could come in handy. But what about other cases. For instance if you are making some shooter game you wil define you units health with integer I presume. So what will be max health for your units? Several milions hitpoint? I don't think so. You wil probably define you units max heath in the range of few hundred hitpoints. So why do you need 64 bit integer for this again?
I know that having several different iteger types can be quite confusiong for beginers. Infact the concept of the integer itself could be confusing.
What I had in mind was support for 8 bit, 16 bit, 32 bit, etc numbers but the programing language itself is taking care about wich of theese is being used (self optimization)

If the 'slowdown' of 64 bit numbers when you have a math coprocessor DESIGNED to handle numbers that size is an issue, you're probably doing something wrong.
I was refering of using 64 bit integers on 32 bit procesors (many platforms today still use 32 bit processing). Ofcourse you can stil do 64 bit math procesing on 32 bit procesors but for that you need to do two math calculation for one (first you calculate fir 32 bits, then you calculate nex 32 bits, and finaly you join result from these two functions into final 64 bit result). So making 64 bit calculations on 32 bit procesor takes atleast tvice as long.

I'm arguing with myself over that because to be honest, I hate complex character sets; they are a needlessly complex mess that until recently (relatively speaking) weren't even involved on computers. I often feel that if we just restricted ourselves to 7 bit ASCII we wouldn't have a lot of the headaches that crop up on websites... and since my bread and butter the past decade has been websites; it's only further made me HATE languages or even normal text that requires anything more complex than that.
I do understand you point of wiew. More complex charsets do cause much more complexity. But how would you feel if you had a developing tool or programing language wich doesnt alow you to show some specific characters used in your language?

I'd be far, far more worried about the overhead of string processing UTF-8 into a raster based font system like my GLKernedFont method; which will be what it's going to run since being cross platform I can't rely on any specific engine being present, and freetype looks like ass and kerns text like a sweetly retarded crack addict.
I don't seem how it would be difficult rendering true type fonts. I will learns shortly becouse I intend to make functions wich will alow me to do that in Aspyre graphic engine. If it will work well I do intend on sharing it source code.

Well, that and I have some really weird ideas on how an interpreter should work - and want to test said ideas without getting led off-track.
Testing weird ideas isn't bad at all. Infact every invention was at firsth thought as a weird idea.

2. Originally Posted by SilverWarior
OK I understand that when you are dealing with graphics and physics having 32 bit or 64 bit numbers could come in handy. But what about other cases. For instance if you are making some shooter game you wil define you units health with integer I presume. So what will be max health for your units? Several milions hitpoint? I don't think so. You wil probably define you units max heath in the range of few hundred hitpoints. So why do you need 64 bit integer for this again?
Remember this is an interpreter, not a compiler, handling data types could add as much if not more overhead as well... php comes to mind with it's total lack of strict typecasting but at the same time internally having types; all those data conversions on every access/assignment can end up just as long as calling the FPU... being it ARM's VPF, legacy x87, or SSE.

Spending time on an interpreter, even after tokenizing on automatically selecting the optimal type for a value or range of values can end up just as big and slow as just operating on a single fixed type. All those branches, calls and conditionals add up quick... certainly faster than the 2 to 8 clock difference between a 32 bit integer operation on the cpu and 64 bit one on the FPU. (at least on x86... still learning ARM)

Originally Posted by SilverWarior
I was refering of using 64 bit integers on 32 bit procesors (many platforms today still use 32 bit processing). Ofcourse you can stil do 64 bit math procesing on 32 bit procesors but for that you need to do two math calculation for one (first you calculate fir 32 bits, then you calculate nex 32 bits, and finaly you join result from these two functions into final 64 bit result). So making 64 bit calculations on 32 bit procesor takes atleast tvice as long.
I get that, and in a way it's part of why I'm not bothering even having integer types.

By going straight to the math-co, on x87 that's simply a FLD, the operation (FMUL,FADD,FSUB,FDIV), then FSTP -- not really any more or less code than mov eax,mem; mov ebx,mem; mul ebx; mov mem,eax

At most a FPU double multiply (for example) on anything x87 pentium/newer is 12 bus clocks memory, 12 bus clocks code fetch and 6 cpu clocks execution (including setting up the FPU memory pointer)... A 32 bit integer multiply on same might be only 6 bus clocks memory, but it's 20 bus clocks code fetch and 4 cpu clocks.... so they may look like they take the same amount of time, but remember the bus isn't as fast as the cpu; as such on modern computers it is often FASTER to do a 64 bit floating point multiplication than it is a 32 bit integer one... just because 386 instructions are that extra byte in length meaning a longer wait for it to fetch.

Of course, if you can optimize the assembly to put everything into proper registers you can shift that back around, but that's more the type of thing for a compiler to do, not an interpreter.

... and while that's for the wintel world of doing things, you also have to remember that ARM lacks a integer divide; while the various VFP/VFE/SIMD/NEON whatever they want to optionally include this week do tend to provide it. Of course, there is the issue of not being able to rely on which FPU extensions are even available (if any) on ARM, and if FPC even bothers trying to include code for them -- that is a concern I'm going to have to play with in QEMU. I know the Cortex A8 provides NEON, which uses 64 bit registers despite being hooked to a 32 bit CPU.

After all, that's why SIMD and it's kine exist, and why the x87 was a big deal back in the day... since a 8087 was basically having a memory oriented 80 bit FPU sitting next to a 16 bit processor.

It is a good point though that I should 'check it'... I'll probably toss together a synthetic bench tomorrow to gauge the speed differences, if any... though constant looping will likely trigger the various caches, so I'll probably have to make a version that puts a few hundred k of NOP's in place to cache-flush between operations.

I'm also used to thinking x86 where the 'integer optimization' for coding hasn't really been true since pentium dropped... I've really got a lot of studying of ARM to do -- and the code FPC makes for ARM. I mean, does it even try to use SIMD/FPV if available?

Originally Posted by SilverWarior
I don't seem how it would be difficult rendering true type fonts. I will learns shortly becouse I intend to make functions wich will alow me to do that in Aspyre graphic engine. If it will work well I do intend on sharing it source code.
Wait until you try using the train wreck known as freetype -- it's rubbish, pure and simple... There's a reason so many SDL and OpenGL programs don't even bother and use raster fonts instead... The rendering is ugly, inconsistent, painfully slow and the code interfaces are the worst type of tripe this side of trying to write a device driver for linux.

I was thinking I could use monospace and/or monokerned fonts instead of true kerning; that would make it simpler/faster and since it's going to have an editor, it will have a monospaced fonts anyways. Vector fonts are a high resolution luxury that I don't think translate well to composite-scale resolutions in the first place; see the old vector fonts from the BGI at CGA resolutions.

I may also keep the editor strictly SDL, leaving openGL for when a program is running in the interpreter. Still need to play with the idea. Nowhere near working on that part of it yet as my first order of business is getting the tokenizer and bytecode interpreter complete to where it can at least make a console program. THEN I'll worry about the IDE, graphics, fonts, etc...

Remember this is an interpreter, not a compiler
Pardon me. It seems I misunderstood your intention. I got a feling that you intend to make completly new programing language from scratch.

BTW how come you have decided to not include support for pointers? I do understand that for beginner they might seem verry complicated, but when you learn working with them then you realize that they can be verry powerful if used corectly.

4. Originally Posted by SilverWarior
Pardon me. It seems I misunderstood your intention. I got a feling that you intend to make completly new programing language from scratch.
It is... but it's an interpreted one like PHP, Python, Perl, ROM Basic, Javascript, (and if you don't buy into this virtual machine BS, Java), etc -- instead of a compiled one. At this point being 'truly original' is a joke (given 90% of programming languages are just C rehashed -- see Java and PHP) but there are some ways to make things simpler.

A lot of the choices come from Python and Ruby without the parts to me are either needlessly complex, pointless, or annoying. (annoying? Elif much?!?).

Originally Posted by SilverWarior
BTW how come you have decided to not include support for pointers? I do understand that for beginner they might seem verry complicated, but when you learn working with them then you realize that they can be verry powerful if used corectly.
First, as you said it is a complicated concept; one I really wasn't able to grasp until Junior high and I was pretty up on the take for this sort of stuff. (given I'd written my first business app in diBol at 13)

But more importantly, given the other stuff I've omitted, what purpose would they serve? There's no direct memory access, no complex data structures like record or userland objects, arrays are (hopefully) going to automatically be dynamic (since I'll be using "array of" with setlength on the back end)... Pointers for the sake of having pointers is... pointless.

Plenty of real world deployment languages get along just fine without them. PHP doesn't have pointers... Java doesn't have them; they have handles which will work much akin to my 'createxxxxx' methods...

They're an advanced concept best left to an intermediate or higher language, not a elementary one.

Though I've been beating myself up over including/not including all sorts of things like pointers the past week and a half since I started this project on a cocktail napkin during a "brainstorming luncheon". I keep having to remind myself "don't make it any more complicated than a 1980's ROM Basic, just let it do more"

Which means no scope, no pointers, no user functions, no typecasting of numerics, no complex data structures.

5. Don't beat yourself up, stick to your guns!

6. I have to be honest though. Pointers are somewhat of a double edged sword, used correctly they can create some absolutely marvelous and innovative code, especiall in an OOP context. However, the down side is that they can also create an absolute hell of debugging as in my case, I often find myself referring to 'runlevels'. In other words, an array of procedures, sometimes 2D, which the program can modify on the fly to change its behaviour when conditions are met. However, due to the generic context of many of these procedure the error with a memory address is not so useful - its not the actual procedure that was at fault as the code there was working just a minute ago - but rather, a pointer has moved to the wrong procedure/variable and fed the wrong array into the wrong procedure or something.

I guess what I'm getting at, is that although GDB can point to your code being faulty, pointers are more of a higher level 'logic' problem. I can definitely see why its a good idea to keep people whom are new to code away from such nasties, however I would recommend something similar to pointers as when they eventually become more adept at programming, they will inevitably want to create more complex programs and experiment with that concept - something all to present in the real world. Perhaps implementing something similar to pointers, but under a more structured context would be a good idea in that case?
Just my 2 cents... Great work anyhow.

7. Originally Posted by code_glitch
I guess what I'm getting at, is that although GDB can point to your code being faulty, pointers are more of a higher level 'logic' problem.
Which is why with my primary target being pre-teens down to third or fourth grade, they have no place.

Originally Posted by code_glitch
I can definitely see why its a good idea to keep people whom are new to code away from such nasties, however I would recommend something similar to pointers as when they eventually become more adept at programming, they will inevitably want to create more complex programs and experiment with that concept - something all to present in the real world. Perhaps implementing something similar to pointers, but under a more structured context would be a good idea in that case?
To me that's time for them to move on to a real programming language -- like pascal or C.

A lot of people seem to like to use the training wheels analogy; but usually you give them a tricycle or big wheels long before you give them a real bike even with training wheels. I don't see a lot of adults or even teenagers riding around on big wheels. You might have alphabet blocks as a toddler, doesn't mean you're still using them in Elementary school.

I'm thinking Duplo, not Lego Technix. I'm thinking Erector Set, not Arc Welder. I'm thinking alphabet blocks, not Merriam-Websters.

Oddly, across the various places I'm discussing this that seems to be the hardest point to drive home and/or that people aren't understanding. (this forum so far has been the most accepting of the concepts)- Hoping that will get better when I have a real website written up with the various points and information broken into pieces and dumbed down -- as opposed to forum rants the illiterates who make up modern society piss and moan about. Oh noes, wall of text -- AAAH!!! God forbid people be expected to read anything anymore.

8. I had a thought. You said that pointers was something that you didn't get until junior high right? Well why bother putting them in for the first version? When I first learned to program I started with only the functions I needed to do some of the interesting things then eventually I learned more to become a better programmer. So why not take that approach?

Start with the basic concepts and lessons, then make a second version OR a "Novice" or "Advanced" edition to teach the second set of concepts that you would learn later on. These editions would compliment each other as people learning the advanced stuff would still be familiar with the language enough that moving onto more complex concepts would be smoother that way.

If this is a project that you wish to put up as a teaching tool of sorts it's best to start with the beginning and then move upward into the next step one at a time. You could even do a 3rd edition that went on to teach the basics of OOP.

9. Thats an interesting way of putting will. My only potential worry about that is code maintenance - you'd have to fix bugs across each version... Unless, you had it fixed so you had a line like:
at the start, kind of like {\$Mode ObjFpc}, the interpreter would know to switch out of 'easy' mode with more functions, pointers and etc...

Having said that, though, deathshadow - whats your take on scratch? Personally I actively persecute it... But thats just me

10. Originally Posted by code_glitch
Having said that, though, deathshadow - whats your take on scratch? Personally I actively persecute it... But thats just me
It's actually something I looked at during my whirlwind tour of "wow these suck". It's too gimmicky, their website seems to be just thrown together any old way to the point I couldn't even figure out where the actual instructions for using it or doing anything in it actually are, and I didn't see any results built in it that were particularly blowing my skirt up.

Though much of that is just the technology it's based on. Flash can be very powerful, but to compile to actionscript, which is basically what it does... well... the net result leaves a lot to be desired... Crappy user input handling, oddball flickers of simple things like sprite movement... and that's before we talk the "IDE".

Which I naturally hate for the goofy illegible color contrasts -- but to be fair, I can't stand illegible acid trip of color syntax highlighting either; it's one of the first things I disable in any editor. (part of why I use Flo's Notepad2 as my primary). I didn't like it when Borland added it to TP4, I've not seen it improve in usefulness since; making giant colored boxes with text that doesn't line up in a clear manner with all sorts of pointless useless extra wording? I'll pass.

In a lot of ways SCRATCH reminds me of Logo -- you can't actually seem to make anything useful with it; and when the results are NOT as good as ROM Basic programs were on a TI-99/4a on a multi-ghz computer using a API that DOES have hardware acceleration... you've got problems.

Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•