I was inquiring about the 64bit version Of iwbasic. I have been a member for years and I was wondering if it is available yet.
I may need to update my email address.
philiphughes@treecare.tv . I will look under members to see.
Philip Hughes
aka Texas Pete
Still working on it.
Had to do a complete compiler re-write in order to use Clang/bytecode version
to make it multi platform.
At this time I am working on the windowing part of the compiler.
It will create windows but having problems (minor) with some of the finer
points of IWB.
I am a bit slow working on stuff - two granddaughters and 3 great grandkids
living with us now and they take up lots of my time.
Anyway - still chipping away.
Anyone want to help?
Larry
Translating the old lib functions to bytecode.
Quote from: Rock Ridge Farm (Larry) on May 01, 2019, 03:56:33 PMTranslating the old lib functions to bytecode.
You mean llvm byte code?
Are you translating everything by hand?
Modifying the main compiler to emit llvm problem is that some of the lib functions do not produce the proper call function so I need to figure out what it should be and adjust the compiler. Has not been an easy task as I can find only limited documentation on generating llvm bytecode. It seems that I am the only person who does not know this by default.
Indeed, there are not many tutorials for handwritten bytecode out there. Someone showed a method of writing what he wanted to translate in C and then analysed thr resulting IR code.
That is how i would do it.
Your way of emiting IR code directly is definitely the fastest regarding compilation time.
I don't have much experience in that part.
Writing C code and figuring out what bytecode is generated is how I have been doing it so far - just hoped there was a better way. Since I am trying to keep as much of the existing lexer/parser it gets a bit difficult meshing the bytecode in place of the asm code that was generated.
Hi Folks,
I'm an unbeliever in 64 bit :o
I suspect you guys are giving yourselves headaches for no useful purpose.
Some folk think 64 bit is bound to result in faster programs - not so. If you check the Web - something to do with extra memory usage and padding can result in slower programs.
Maybe we should aim for 256 Bit machines and go really fast .. ;D
Some think you can access huge memory storage with 64 bit data lines and registers. Unfortunately, there aren't any machines that could fit that much memory. And why would you need it, unless you're working on Google-type World spying systems or calculating astronomical journeys.
Try searching for existing 64 bit compilers - there's not much to see.
PureBasic trumpets it's already got such facilities. But check out their Forum.
No sign of lengthy discussions - or people saying 'Wow! However did we manage without 64 bit'.
Not surprisingly, there are comments about driver problems in the 64 bit World.
Overall, I don't see myself as needing 64 bit in my lifetime ..
Best wishes, :)
Graham
Having the compiler produce byte code - it can support 8 - 128 bit machines.
You set the machine type and output of the final stage of the compiler produces an executable for that machine.
Have not gotten that far yet but I am still plugging along.
Larry
An example of what I am dealing with:
%2 = call i32 @OPENWINDOW(%struct._GtkWidget* %win,i32 100,i32 100,i32 400,i32 400,i32 13041664,i32 0,i8* getelementptr inbounds ([12 x i8], [12 x i8]* @.str.2, i32 0, i32 0),i8* %s)
This is the byte code representation of the ebasic:
OPENWINDOW win,100,100,400,400,@SIZE|@MINBOX|@MAXBOX|@CAPTION,0,"IW Test Win",&mainwindow
close but enough variance to need lots of research to get it right.
There is no definitive byte code manual so most of my work is trial and error.
I end up writing a prototype in C then reverse engineering. This has to be done for every function. Simple instructions are not as bad.
At my age this comes with much effort - need younger blood on this project.
Larry
are you saying that in order to write a program using the 64bit compiler the User will have to learn
this:
%2 = call i32 @OPENWINDOW(%struct._GtkWidget* %win,i32 100,i32 100,i32 400,i32 400,i32 13041664,i32 0,i8* getelementptr inbounds ([12 x i8], [12 x i8]* @.str.2, i32 0, i32 0),i8* %s)
for the OPENWINDOW command or will they still be able to use:
OPENWINDOW win,100,100,400,400,@SIZE|@MINBOX|@MAXBOX|@CAPTION,0,"IW Test Win",mainwindow ?
No - you will not need to learn byte code. It is the stage at which point the compiler will produce code for other platforms. It will be a compile time flag
that will indicate if the code is for Win, Linux, Mac, .......
Unless you use a flag to see the bytecode you will never know it is there.
It is just the big change internally that I am making.
Larry
good - it scared me for a sec.