fbc -gen html5

For other topics related to the FreeBASIC project or its community.
Landeel
Posts: 695
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

fbc -gen html5

Postby Landeel » Aug 24, 2011 15:06

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
Posts: 2770
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: fbc -gen html5

Postby marcov » Aug 24, 2011 16:40

Landeel wrote: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
Posts: 1515
Joined: Jun 21, 2005 19:04

Postby angros47 » Aug 24, 2011 18:41

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
Posts: 695
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » Aug 24, 2011 20:37

I'm not planning anything for now, I was just curious.
It's better to just stick with Javascript then.
Thanks.
TeeEmCee
Posts: 261
Joined: Jul 22, 2006 0:54
Location: Auckland

Postby TeeEmCee » Aug 25, 2011 21:16

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:

Alchemy FAQ wrote: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
Posts: 695
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » Aug 25, 2011 23:09

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
Posts: 2770
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Aug 26, 2011 7:01

TeeEmCee wrote: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
Posts: 261
Joined: Jul 22, 2006 0:54
Location: Auckland

Postby TeeEmCee » Aug 26, 2011 8:09

marcov wrote: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.
Last edited by TeeEmCee on Aug 26, 2011 8:13, edited 1 time in total.
HD_
Posts: 215
Joined: Jun 10, 2006 12:15
Contact:

Postby HD_ » Aug 26, 2011 8:12

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
Posts: 2770
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Aug 26, 2011 11:00

TeeEmCee wrote:
marcov wrote: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.
Pritchard
Posts: 5492
Joined: Sep 12, 2005 20:06
Location: Ohio, USA

Postby Pritchard » Aug 28, 2011 2:16

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
Posts: 261
Joined: Jul 22, 2006 0:54
Location: Auckland

Postby TeeEmCee » Aug 28, 2011 6:34

marcov wrote: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_FlashCCompiler.pdf if interested.
marcov
Posts: 2770
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Aug 28, 2011 12:15

Pritchard wrote: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 :-)

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 22 guests