The opendarkbasic's discuss from opendarkbasic

It seems like x = arr() is syntax for returning the base memory address of the array. It also looks like it's possible to assign new memory to arrays:

type Thingy
  Array as dword
endtype
 
type ThingyWithinAThingy
  a as integer
  b as float
  c as byte
endtype
 
ThingA as Thingy
ThingA.Array=make memory(SizeOf("ThingyWithinAThingy")*10)      `dim ThingA.Array(9) as ThingyWithinAThingy
fill memory ThingA.Array,0x00,SizeOf("ThingyWithinAThingy")*10  `I'm sure the memory is filled with garbage, so we'd better clear it.
 
end
 
function SizeOf(type$)
  type$=get type pattern$(type$,0)
  Size=0
  for a=1 to len(type$)
    char$=mid$(type$,a)
    if char$="L" or char$="F" or char$="S" or char$="D" then inc Size,4 `This is assuming that "strings" are just pointers.  I don't actually know, but it would make the most sense.
    if char$="W" then inc Size,2
    if char$="Y" then inc Size,1
    if char$="O" or char$="R" then inc Size,8
  next a
endfunction Size

Here's another example I found:

type Thingy
  Array as dword
endtype
 
ThingA as Thingy
ThingA.Array=make memory(4*10)      `dim ThingA.Array(9) as integer
fill memory ThingA.Array,0x00,4*10  `I'm sure the memory is filled with garbage, so we'd better clear it.
 
SetIntegerElement(ThingA.Array,0,1234)
SetIntegerElement(ThingA.Array,1,5678)
print GetIntegerElement(ThingA.Array,0)
print GetIntegerElement(ThingA.Array,1)
 
suspend for key
end
 
`Getter/Setter Functions
function GetIntegerElement(Address as dword,Index)
  inc Address,4*Index
  Element=*Address
endfunction Element
 
function SetIntegerElement(Address as dword,Index,Element)
  inc Address,4*Index
  *Address=Element
endfunction

Generate an ELF or MachO executable using LLD

Once #70 is merged, this can be done

CommandIndex: addCommand() and findConflicts() should be combined

Convert "1" and "0" literals to ByteLiteral instead of BooleanLiteral

Build bison internally using CMake

Add ast::Node::toString()

This should non-recursively return a string representation of the node. For example:

Block::toString() -> "Block(5)"
ScopedAnnotatedSymbol::toString() -> "ScopedAnnotatedSymbol(GLOBAL, FLOAT, \"var\")"

Add support for hints / multiple colors for warning and error messages

It would be nice to have a class that lets you combine multiple SourceLocation instances together with hints attached to locations, which can then be used to format a message along the lines of:

[db parser] test:1:26: syntax error: unexpected byte, expected string
1 | global dim arr$(2, 3) as byte
  |               ^          ^~~~
  |               |
  |               Annotation `$' implies string

SourceLocation should also support setting the color so when multiple SourceLocations are involved, it's easy to distinguish them.

Some cases should also be formatted a little differently, such as with binary operators:

[db parser] test:1:9: syntax error: Invalid operands
1 | result = 3.4 && 0xFF
  |          ~~~ ^^ ~~~~

Implement codegen for global variables and constants

odbc fails to compile code with windows line endings -> revert 7922682 and add a rule for "\r"

Add enum to BinaryOp and UnaryOp, and remove derived types

Commands which are a superset of other commands are not parsed correctly

move camera 1, 0.5
move camera up 1, 0.5

This gets parsed as two move camera commands, with the 2nd one having a first argument up.

[db parser] dba-sources/test.dba:2:19: syntax error: unexpected integer literal, expected end of file
2 |    move camera up 1, 0.5

Add support for UDT declarations and "as udttype" for variables

Add select/case statements back

Enable some LLVM optimisations

Currently the LLVM module is turned straight into object code. We should run some optimizations on it such as dead code elimination, const propagation, loop unrolling, function inlining, etc.

"break" keyword in DBP does not break from for loops. "exit" does.

Add support for initializers for arrays

Disable colors if stderr is being piped

Split AST node classes up into their own files

Autodetect SDK type based on SDK root

If the SDK root contains DBPro DLL's, then we can assume the sdk-type is dbpro, otherwise odb

Find out precedence of unary operators in original DBP

Not entirely sure how to test this, but currently the logical not operator and the unary - operator may not have the correct precedence (relative to other binary operators).

It is also unclear what the precedence rules are among unary operators themselves. I would assume - is higher than not such that not -a is parsed as not (-a).

Calls to setParent() should occur after assignment, otherwise old value is in an inconsistent state during destruction

Remove the dependency on the platform libraries in the generated object file.

Currently, the object file generated by odbc depends on a number of platform services such as:

LoadLibraryA
GetProcAddress
puts
etc

This is to implement features such as initialising the DBP engine, loading plugins at runtime, getting function pointers for commands.

This approach means that to create a fully linked executable, we need to link against kernel32.lib and possibly other libraries, which means that we need access to an MSVC installation. We'd also need libstdc++ / libc++ dev libraries installed on Linux/macOS.

An alternative approach would be to ship a shared library as part of OpenDarkBASIC. I'll call this odb-dbp.dll (for the DBP DLLs) or odb.dll/odb.so for the ODB SDK. This library would provide a number of functions that the DBP executable would require, such as:

loadPlugin - a shim for dlopen / LoadLibraryA. Could do something clever with paths as well.
getFunctionPtr - a shim for dlsym / GetProcAddress. Could implement caching as part of this.
initialiseEngine - code that initialses the DBP engine (probably not applicable for the odb SDK). Currently this is hard coded in the code generator, but it would be far easier to maintain in C++.
print functions - these would be useful to emit debug output in the executable.

The idea is that a binary OpenDarkBASIC distribution would ship a copy of odb-dbp.dll and odb.dll (on Windows), and odbc would link the generated game executable with that DLL / shared object file ONLY. This can be done without any dependency on any other compiler or toolchain on the system, and would enable cross compilation, assuming the required odb.dll/.so file is available to link against.

odbc can't find DLLs on Windows - Restructure output directories

Suggest the following structure for both build and install trees:

build/bin/
├── dbp-sdk/
│   ├── plugins/
│   └── thirdparty-plugins/
├── odb-sdk/
│   ├── plugins/
│   |   └── test-plugin.dll
|   └── thirdparty-plugins/
├── include/
│   ├── odb-compiler
│   └── odb-sdk
├── lib/
│   ├── odb-compiler.lib
│   └── odb-sdk.lib
├── odbc
├── odbc_tests
├── odbi
├── odb-sdk.dll
└── odb-compiler.dll

Trailing comments cause parser issues

This code:

print "Hello" `comment
print "World"

gives this error:

[db parser] dba-sources/test.dba:2:1: syntax error: unexpected command, expected end of file
2 | print "World"
  | ^~~~~

Remove GotoSymbol, Command*Symbol, etc. and let IR do symbol resolution

Add a toString() method on all AST nodes so it is easier to

Implement codegen for arrays

The command index should not allow keywords to be added.

It was possible for DBP plugins to have built-in keywords (such as "do" and "loop") as commands in the string table. As a result, the parser will emit a warning if it encounters a keyword that is also registered as a command.

I recently made a change which ensures that such commands are never added to the command index. The command index should have a check that causes a fatal error if a plugin contains a built in keyword as a command.

Fix location info when doing more than 1 lookahead

Add support for restore/read/data statements in parser

Add support for pointer types in parser

Support matching all builtin names to construct keywords

Add support for semi-colon in parser

SourceLocation last_column is off by 1

The parser generates a broken error message after encountering an invalid command

If I try to parse the following DBP code:

invalid command 1, 2
print "real command"

it generates the following error message:

[db Parser] dba-sources/game.dba:2:7: syntax error, unexpected not, expected end of file
  | print "real command"
  |       ^~~~~~~~~~~~~~

I'd expect the error message to be something like: syntax error: unknown command "invalid command ".

CLI arguments should be grouped into phases and executed in a predefined order

Adding Global before a variable declaration causes parse issues later.

I was hitting an issue with the current parser. It seems that this parses fine:

OPlayer as Integer = 1
Make Object Sphere OPlayer , 1

but adding Global breaks it:

Global OPlayer as Integer = 1
Make Object Sphere OPlayer , 1

C:\Users\dga\Work\DBP\Snippets\Inertia\_Temp.dbsource:3:6: syntax error, unexpected SYMBOL, expecting AS
  Make Object Sphere OPlayer , 1

This case also doesn't seem to work:

Global OPlayer As Integer
OPlayer = 1
Make Object Sphere OPlayer , 1

C:\Users\dga\Work\DBP\Snippets\Inertia\_Temp.dbsource:3:6: syntax error, unexpected SYMBOL, expecting AS
  Make Object Sphere OPlayer , 1

When a plugin tries to add a command which already exists, it should be replaced.

The Matrix1Util_07 defines a number of functions that already exist in DBP, such as CLAMP, ABS, etc. The description of that plugin is:

"This plug-in provides faster alternatives to some of the standard DBPro functions, and fills in a few missing ones"

This implies that a conflicting command should replace the original command. The current behaviour is to generate an error.

Examples of conflicts which I believe should be replacements:

[sdk] Command `clamp F(FFF)` redefined in library `C:\Users\dga\Work\DBPro\Compiler\plugins-user\Matrix1Util_07.dll`
[sdk] Command was first declared in library `C:\Users\dga\Work\DBPro\Compiler\plugins\DBProCore.dll`
[sdk] Command `max F(FF)` redefined in library `C:\Users\dga\Work\DBPro\Compiler\plugins-user\Matrix1Util_07.dll`
[sdk] Command was first declared in library `C:\Users\dga\Work\DBPro\Compiler\plugins\DBProCore.dll`
[sdk] Command `min F(FF)` redefined in library `C:\Users\dga\Work\DBPro\Compiler\plugins-user\Matrix1Util_07.dll`
[sdk] Command was first declared in library `C:\Users\dga\Work\DBPro\Compiler\plugins\DBProCore.dll`
[sdk] Command `object scale x F(L)` redefined in library `C:\Users\dga\Work\DBPro\Compiler\plugins-user\Matrix1Util_18.dll`
[sdk] Command was first declared in library `C:\Users\dga\Work\DBPro\Compiler\plugins\DBProBasic3DDebug.dll`
[sdk] Command `object scale y F(L)` redefined in library `C:\Users\dga\Work\DBPro\Compiler\plugins-user\Matrix1Util_18.dll`
[sdk] Command was first declared in library `C:\Users\dga\Work\DBPro\Compiler\plugins\DBProBasic3DDebug.dll`
[sdk] Command `object scale z F(L)` redefined in library `C:\Users\dga\Work\DBPro\Compiler\plugins-user\Matrix1Util_18.dll`
[sdk] Command was first declared in library `C:\Users\dga\Work\DBPro\Compiler\plugins\DBProBasic3DDebug.dll`

Commands are parsed incorrectly if a command contains another valid command in its name.

If we have the following code (where text, set text font and center text are valid commands):

set text font "Arial"
text 20, 20, "Hello"
center text 200, 200, "Centered"
wait key

This fails to parse with the following error:

[db Parser] dba-sources/simple.dba:2:14: syntax error, unexpected symbol, expected `=`
2 | text 20, 20, "Hello"
  |              ^~~~~~~

Another failing example. In this case ink and ink foreground are valid commands in the command index:

ink foreground rgb(255, 255, 0)
print "yellow"
wait key

[db Parser] dba-sources/simple.dba:3:1: syntax error, unexpected command, expected end of file
3 | wait key
  | ^~~~

I'm not sure what exactly is happening here, but it seems that the parser is entering some strange state when it thinks it's matched a smaller command (such as text or ink), but really it should be matching a longer command (such as ink foreground). Unfortunately, this is blocking me from parsing any reasonably complex project.

install gperf
install and run valgrind
only run CI on PRs

/home/dga/Work/opendarkbasic/cmake-build-debug/bin/odbc --dump-commands -i dba-sources/odb.dba -o test/test
Error: Unrecognized command line option `test/test`

opendarkbasic / opendarkbasic Goto Github PK

opendarkbasic's Issues

Recommend Projects

Recommend Topics

Recommend Org