Pure FB Runtime Library (in progress)
-
- Posts: 564
- Joined: Sep 27, 2016 18:20
- Location: Valencia, Spain
Re: Pure FB Runtime Library (in progress)
> I get what it is supposed to do, but why would you choose that over a multi-line comment? Is there some benefit that I don't know about?
Maybe multi-line comments were not yet implemented when that code was written. Anyway, a comment is a comment, isn't it?
Maybe multi-line comments were not yet implemented when that code was written. Anyway, a comment is a comment, isn't it?
Re: Pure FB Runtime Library (in progress)
It is in C code so it was implemented. I just didn't know if there was some benefit to using it that I was unaware of. One I can see is syntax highlighting still happens in the IDE. That could be it. I only ask because I am converting the code and was changing them to multi-line comments at first, but now I am leaving them because of the syntax highlighter.Josep Roca wrote:> I get what it is supposed to do, but why would you choose that over a multi-line comment? Is there some benefit that I don't know about?
Maybe multi-line comments were not yet implemented when that code was written. Anyway, a comment is a comment, isn't it?
Re: Pure FB Runtime Library (in progress)
In C you can't nest multi line comments so if you want to comment out a complete section of code that might contain multi line comments, this ifdef idiom is often used.
Re: Pure FB Runtime Library (in progress)
Ah ha! That makes sense. Thanks for the explanation. I used C in college and not much outside of that, so a lot of this is stuff I have never seen before.caseih wrote:In C you can't nest multi line comments so if you want to comment out a complete section of code that might contain multi line comments, this ifdef idiom is often used.
Re: Pure FB Runtime Library (in progress)
To anyone who wants to try:
I have converted all of the standard FB String methods. I am not sure if they are correct. If someone would like to try and test the code, or tell me how I can test it (it throws errors because of the missing WString functions), I would be all ears for fixes/advice.
I have converted all of the standard FB String methods. I am not sure if they are correct. If someone would like to try and test the code, or tell me how I can test it (it throws errors because of the missing WString functions), I would be all ears for fixes/advice.
-
- Posts: 564
- Joined: Sep 27, 2016 18:20
- Location: Valencia, Spain
Re: Pure FB Runtime Library (in progress)
A function like this
won't work with FB 64-bit, that does not support variadic functions.
It is going to be a 32-bit only runtime?
Code: Select all
function fb_CHR cdecl ( args as long, ... ) as FBSTRING ptr
It is going to be a 32-bit only runtime?
Re: Pure FB Runtime Library (in progress)
That is the way it was written in C, so that is what I have translated. I hope that the bug in the C emitter will be fixed to allow this to work in any bit depth.
Re: Pure FB Runtime Library (in progress)
OK, I got it to compile and run on linux-x86 after fixing some bugs. Should work on win32 too, if you have the prereqs for compiling libfb itself there (I don't, but aside from that, crosscompiling seemed to work). I copied out some parts of FB's makefile and modified it to prefer .bas files over .c files. It proved quite painful; I hate writing makefiles. Made a pull request
A test:
I noticed a problem: TRUE is defined as 1, which is the value used in C, but FB uses -1. However, if you change TRUE to -1, then there will probably be some incompatibilities between modules written in C and those in FB. Also, over the place you've translated !X to not(X), but that works only if X takes only the values 0 and -1.
I think TRUE should almost certainly be changed to -1, never mind compatibility of internal structs. However this does mean you need to be careful anywhere that truth values are used, whether replacing 1 with -1 and ! with not changes the logic (not just where TRUE is used, but also for any logical operators)
A test:
Output:dim as string a = "hello!", b
b = "a23"
? a
? str(32)
? a+b
? string(10, "a")
? chr(65,66,67,68)
? left(a,3), right(a,3)
? ucase(a)
Code: Select all
hello!
32
hello!a23
aaaaaaaaaa
ABCD
hel lo!
fish: Job 2, “./hello” terminated by signal SIGSEGV (Address boundary error)
I think TRUE should almost certainly be changed to -1, never mind compatibility of internal structs. However this does mean you need to be careful anywhere that truth values are used, whether replacing 1 with -1 and ! with not changes the logic (not just where TRUE is used, but also for any logical operators)
Last edited by TeeEmCee on Oct 13, 2017 13:40, edited 1 time in total.
Re: Pure FB Runtime Library (in progress)
Code: Select all
Dim As Boolean b = True
Print Cast(Byte, b)
Print Hex(Cast(Byte, b), 2)
Sleep
-1
FF
Re: Pure FB Runtime Library (in progress)
Thank you so much! I have merged your changes. Anyone else who wants to contribute is welcome to do so. Find bugs I missed! After I finish the array functions, I am going to work on getting all of the OS specific files translated, so I will need non windows people to test that bit for me.TeeEmCee wrote:OK, I got it to compile and run on ... Made a pull request
Also, @TeeEmCee: can I get you to send me a copy of that make file? It would help me out quite a bit.
Re: Pure FB Runtime Library (in progress)
Damnit, I forgot to actually add the makefile to git! Sorry about about; I made another pull req for it.
There's a lot of stuff in FB's makefile that I left out, in particular most OS-specific stuff, including support for building for DOS. It can be added back later. But I guess actually targetting DOS is something that fbrtLib could excel at. Anyway, at 300+ lines, almost nothing in this makefile is actually necessary, but I thought it would be good to stay close to FB's own build system.
There's a lot of stuff in FB's makefile that I left out, in particular most OS-specific stuff, including support for building for DOS. It can be added back later. But I guess actually targetting DOS is something that fbrtLib could excel at. Anyway, at 300+ lines, almost nothing in this makefile is actually necessary, but I thought it would be good to stay close to FB's own build system.
-
- Posts: 215
- Joined: Dec 14, 2013 0:43
Re: Pure FB Runtime Library (in progress)
I have run into a snag using your version of the runtime:
Code: Select all
#include "LibFB/fb.bi"
#include "LibFB/str_chr.bas"
#include "LibFB/str_core.bas"
DECLARE SUB PrintString(src AS Byte Ptr, x AS LONG, y AS LONG)
DECLARE SUB main ()
SUB multiboot ()
Asm
'setting up the Multiboot header - see GRUB docs for details
.set ALIGN, 1<<0
.set MEMINFO, 1<<1
.set FLAGS, ALIGN | MEMINFO
.set MAGIC, 0x1BADB002
.set CHECKSUM, -(MAGIC + FLAGS)
.align 4
.LONG MAGIC
.LONG FLAGS
.LONG CHECKSUM
.set STACKSIZE, 0x4000
.comm stack, STACKSIZE, 32
.global loader
loader:
lea esp, stack + STACKSIZE
push eax
push ebx
CALL MAIN
cli
hlt
END Asm
END SUB
SUB main ()
' ONST s = fb_CHR(97)
PrintString CPtr(Byte Ptr, @Chr(97)), 35, 12
END SUB
SUB PrintString(src AS Byte Ptr, x AS LONG, y AS LONG)
DIM dst AS Byte Ptr
DIM counter AS LONG
dst = CPtr(Byte Ptr, &HB8000 + y * 160 + x * 2)
counter = 0
WHILE src[counter] <> 0
dst[2 * counter] = src[counter]
dst[2 * counter + 1] = 15
counter = counter + 1
WEND
END SUB
[main@Manjaro FBCDOS]$ ld -m elf_i386 -T link.ld -o kernel.bin kernel.o
kernel.o: In function `fb_CHR':
(.text+0x32): undefined reference to `__fb_ctx'
(.text+0x9c): undefined reference to `__fb_ctx'
kernel.o: In function `fb_hStrAllocTmpDesc':
(.text+0x107): undefined reference to `fb_hListInit'
(.text+0x114): undefined reference to `fb_hListAllocElem'
kernel.o: In function `fb_hStrFreeTmpDesc':
(.text+0x170): undefined reference to `fb_hListFreeElem'
kernel.o: In function `fb_hStrAlloc':
(.text+0x222): undefined reference to `malloc'
(.text+0x23e): undefined reference to `malloc'
kernel.o: In function `fb_hStrRealloc':
(.text+0x314): undefined reference to `fb_StrDelete'
(.text+0x323): undefined reference to `malloc'
(.text+0x33f): undefined reference to `malloc'
(.text+0x366): undefined reference to `realloc'
(.text+0x385): undefined reference to `realloc'
kernel.o: In function `fb_hStrDelTemp_NoLock':
(.text+0x4f1): undefined reference to `fb_StrDelete'
kernel.o: In function `FB_MEMCPYX':
(.text+0x667): undefined reference to `memcpy'
Re: Pure FB Runtime Library (in progress)
Sorry, you can't simply include a couple source files from the library and expect it to work. Those files have dependencies on many other files, and on libc, as you noticed.
Quite a lot of the minimum code that needs to be linked is related to initialising the console, actually, so that PRINT can work.
In your case, running without an OS, I guess the DOS console backend code might work, if it accessed video memory or BIOS directly instead of using DOS interrupts to print? (I don't know)
Somebody wrote an OS in FreeBasic, have a look into what they did.
Quite a lot of the minimum code that needs to be linked is related to initialising the console, actually, so that PRINT can work.
In your case, running without an OS, I guess the DOS console backend code might work, if it accessed video memory or BIOS directly instead of using DOS interrupts to print? (I don't know)
Somebody wrote an OS in FreeBasic, have a look into what they did.
-
- Posts: 215
- Joined: Dec 14, 2013 0:43
Re: Pure FB Runtime Library (in progress)
malloc, realloc, memcpy, etc should be easy to implement in FreeBASIC as the C versions the functions are really not all that complicated. What I need to know is the names of the files that contain various functions such as __fb_ct, fb_hListInit, fb_hListAllocElem, fb_StrDelete, etc.
Code: Select all
function memcpy(dest as byte ptr, src as byte ptr, n as long)
'' Typecast src and dest addresses to (char *)
dim as byte ptr csrc = (byte ptr)src
dim as byte ptr cdest = (byte ptr)dest
'' Copy contents of src[] to dest[]
dim as integer i
for i = 0 to n
cdest[i] = csrc[i]
next i
end function
Re: Pure FB Runtime Library (in progress)
There are several mistakes in your memcpy.
Other functions like fb_hListInit don't exist (grep fb_hListInit *.bas). That's because fbrtLib is mostly incomplete. You still need to use (at least parts of) FB's official rtlib.
Code: Select all
> grep "dim.*__fb_ctx" *.bas
init.bas:dim __fb_ctx as FB_RTLIB_CTX
str_format.bas: dim as FBSTRING ptr dst = @__fb_ctx.null_desc