fbc -gen html5

[Landeel]

How hard would it be to make fbc emit html5 instead of binary executables?
Would it be a matter of adding another emiter, like the gcc one?
Do you think it's possible?

[marcov]

How hard would it be to make fbc emit html5 instead of binary executables?

About as hard as generating MS Word.

Would it be a matter of adding another emiter, like the gcc one?

No. You would need to find a general way to transform FBs abstraction level to the higher level of javascript (since HTML5 is not a programming language, I assume you mean javascript)

C is relatively on the same level as FB's Basic dialect. FB's lowlevel parts map 1:1 on C's, and for the higher level constructs some extra C code is generated. In such case the transformation is fairly obvious, but for lower level to higher level translation it is not that easy.

And that is only the language, once you have found a solution for the language, you need a solution for the libraries, which will be very hard and the result only partially usable too.

Do you think it's possible?

It may be possible for a subset, but it would be mostly a pointless excercise, since the result would not be to most FB code, the result very slow, library support very limited (a browser not being able to access the harddisk).

And all that would be a lot of work.

So rather from the question if it is possible, the question should be why on EARTH would you want to do that?

Even if it is just about Basic syntax, basing yourself on a higher level Basic (VBscript, nearly anything interpreted) would make more sense than basing yourself on FB which borrowed heavily, heavily from C[/b]

[angros47]

HTML5 alone is not a programming language: the actual code is made in javascript.

FreeBasic programs have a start and an end. Javascript programs are usually event-driven, and are made of many subroutines, with no main section.

So, a FB program would perform badly if converted to Javascript; you'd need to redesign it... so, you could directly write it in javascript.

Also, a FB program can access almost every API (i.e., it can create and delete files), a web page cannot.

Last, but not least, the graphic: HTML5 supports many featurs (jpg images, sprites, vector graphic....) but it's not very fast. FBGFX is much faster, but doesn't support many of these features, so you have to do them yourself: porting it to HTML5 would mean that you won't be able to use most HTML5 features (since they are not supported in the freebasic code), and you won't have the speed of native freebasic (since you are using HTML): so, you'd have the worst of both world.


Anyway, if you can't live without a basic program in HTML5, you can try this:

http://stevehanov.ca/blog/index.php?id=92

I think it's the best that can be done.

[Landeel]

I'm not planning anything for now, I was just curious.
It's better to just stick with Javascript then.
Thanks.

[TeeEmCee]

Not to go against what the previous posters have said about this being pointless, but this is actually quite possible and maybe even easy, assuming that you write your code so that you can actually compile it with -gen gcc. There's not just one, but at least three backends from LLVM to either javascript or actionscript:
https://github.com/kripken/emscripten
https://github.com/dmlap/llvm-js-backend
http://labs.adobe.com/wiki/index.php/Alchemy

Supposedly Python, Ruby, Lua, Perl all run in Alchemy.

And if that fails, you can run always use Bellard's x86 emulator written in javascript :P

BTW, I found this interesting:

For computation-intensive use cases, such as audio encoding/decoding, data manipulation or cryptographic functions, performance of code ported using the Alchemy tool chain can be ten times faster or more than native ActionScript 3.0 and anywhere from 2-10 times slower than native C/C++ code.

The reason is that the Actionscript compiler is nowhere near as good at optimising as LLVM is.

[Landeel]

Wow, that's great.
It means when the c emitter is stable, it will be possible.
Just imagine creating web page elements, like banners, or little web games with FreeBASIC, that's the point. Would be so cool.

[marcov]

Not to go against what the previous posters have said about this being pointless, but this is actually quite possible and maybe even easy, assuming that you write your code so that you can actually compile it with -gen gcc. There's not just one, but at least three backends from LLVM to either javascript or actionscript:
https://github.com/kripken/emscripten
https://github.com/dmlap/llvm-js-backend
http://labs.adobe.com/wiki/index.php/Alchemy

The question is not if there is a backend for it, but if it supports anything the frontends will generate.

I can barely imagine that those backends convert any hackish pointer tricks in C compiled with Clang to javascript.

IOW there is more to it than modularly connecting existing frontends and backends.

Supposedly Python, Ruby, Lua, Perl all run in Alchemy.

These are all interpreted languages, and that is not any different then my suggestion to aim for a more interpreted Basic instead of trying to do this with C clone FB.

[TeeEmCee]

The question is not if there is a backend for it, but if it supports anything the frontends will generate.

I can barely imagine that those backends convert any hackish pointer tricks in C compiled with Clang to javascript.

I don't know to what extent they can; however I would assume that any pointer hackery that is portable enough to be compiled to an equivalent LLVM opcode representation can then also be compiled to an equivalent javascript representation by prioritising correct semantics over speed. The x86 emulator proves it's just a matter of giving up speed.

(Also, if you actually tried, it would probably be better to use gcc-llvm instead of clang)

These are all interpreted languages, and that is not any different then my suggestion to aim for a more interpreted Basic instead of trying to do this with C clone FB.

Hmm, OK, I guess those were confusing examples. The point was that all of those interpreters are written in C. I'm not going to argue with your suggestion though.

[HD_]

I have spent some time recently learning javascript/html5/css. Honestly, take a few days to learn them and write directly in them, the are really simple to learn. It's just nasty trying to imagine a lower level language being used to write for a high level language when they are so different in approach :x

Learning resources:
Dive into HTML5 - Good place to start, nice and relaxed document that doesn't spend too long focusing on crud you probably already know.
w3 schools - A lot of information if you know where to look (the references are very useful once you start doing your own thing), otherwise the tutorials are also a good place to start.

[marcov]

The question is not if there is a backend for it, but if it supports anything the frontends will generate.

I can barely imagine that those backends convert any hackish pointer tricks in C compiled with Clang to javascript.

I don't know to what extent they can; however I would assume that any pointer hackery that is portable enough to be compiled to an equivalent LLVM opcode representation can then also be compiled to an equivalent javascript representation by prioritising correct semantics over speed.

Sure. In theory you could have a map somewhere that has an entry for every byte in the memory and use that, and for every problem add another layer.

And of course one can write an emulator in anything that is Turing complete given enough speed and memory.

One could theoretically make a case to emulate whole windows or a *nix with it, and thus run the runtime library unmodified. The practical use of such statements however is limited.

Anyway my point was to be careful, one frontend might compile to a lowlevel subset of the intermediate representation than others, and I'm glad that is understood.

Hmm, OK, I guess those were confusing examples. The point was that all of those interpreters are written in C. I'm not going to argue with your suggestion though.

I don't understand how the interpreter written in C connects to this discussion. Please elaborate.

[anonymous1337]

Wow. You guys convinced me to look up two things:

1) Whether or not any processors use bytecode as their "assembly" language. Yes. There are in fact "Java Processors".

2) Whether or not any emulators have been written in JavaScript. Yes. I've seen several emulators, including NES emulators, in JavaScript.

I'm curious as to how both work.

[TeeEmCee]

I don't understand how the interpreter written in C connects to this discussion. Please elaborate.

Sorry. I meant that a) (significant subsets of) all the language runtimes for all these languages can be compiled to actionscript/javascript (Emscripten also runs CPython and Lua, for example), and b) these are large and complex C programs.

I looked through the paper on Emscripten. The methods used to deal with issues like integer overflows and casting pointers seemed fairly crude, and for me the demos are much slower than the ~x10 slowdown advertised. I'd guess that the Actionscript Virtual Machine supports opcodes which allow more efficient porting. The Flash port of Doom, for example, runs perfectly, which is pretty good, considering that nearly everything else (including cmd.exe!!) on my computer runs at a couple fps due to not having a working DirectX/OpenGL driver.

Since -gen gcc doesn't really work yet, I'm not going to try to port any FB programs to JS/AS, but if it did, I would immediately create a flash port of the OHRRPGCE.

EDIT: Yes, lots of stuff was added to flash to support efficient translation. See http://llvm.org/devmtg/2008-08/Petersen ... mpiler.pdf if interested.

[marcov]

Wow. You guys convinced me to look up two things:

1) Whether or not any processors use bytecode as their "assembly" language. Yes. There are in fact "Java Processors".

Nearly every ARM in mediaplayers, phones or NAS is of the "J" variety.

IOW such things are not even rare.

Java is something totally different from javascript though.

2) Whether or not any emulators have been written in JavaScript. Yes. I've seen several emulators, including NES emulators, in JavaScript.

I'm curious as to how both work.

That is not hard to guess: Slow :-)