Closed ProxyPlayerHD closed 1 month ago
The problem is a missing rule for conversion between compact function pointer and integer. I have fixed it for the next release which is going to happen during May.
If urgent, you can work around it by assigning to a union of a function pointer and then read it back as an int
without doing a cast.
If that does not work out, let me know and I can provide a quick release for you. In that case I need to know the host platform you use.
the union idea seems to have worked, thank you! it's not urgent enough to require a quick pre-release so don't worry.
on another note, the manual mentioned that when using --enable-huge-attribute you need to rebuild the whole library as it has it disabled by default. question is do you have a makefile or instructions lying around for building the library from the included source code? since some files seem to check for specific config defines.
or can all of that just be ignored and it's as simple as just compiling every file in the src/lib/* directories and then combining them to a single library file with NLIB?
I do not have anything suitable laying around, but I will take a look at if it can be generated.
Libraries are built using an internal tool with internal knowledge on how to deal with variant builds. It is not a script, actually a binary and it cannot be used on an installation as the setup is different. Also, it does not allow for arbitrary custom settings without a recompile of it, which work for me, but it is not well suited for end users.
I have generated an initial attempt to build scripts of libraries which I can share with you for early feedback. They are more tailored for Linux/macOS than Windows (for now), and they may require some minor changes. Are you using 65816, roughly what library settings (code and data models) do you use?
for now i've been porting my 65816 workflow to use the compact code/medium data model
(with size_t
being 32-bit, and -O2 --space
to reduce the memory foorptint).
on a similar note, i just quickly want to check if i understood the optimization flags correctly, since they work a bit differently from GCC.
here is how i would map the GCC flags to the Calypsi ones, is this roughly correct?
GCC CalypsiC meaning
-O0 -O0 disable optimizations
-O1 -O1 --speed optimize for speed
-O2 -O2 --speed optimize even more for speed
-O3 x aggressively optimize for speed
-Os -O1 --space optimize for size
-Oz -O2 --space optimize even more for size
You can download the build script here: https://drive.google.com/file/d/1xdie9dK785-l7m4HGaqPX68pa5YDyTU9/view?usp=sharing (I could not attach it here due to unknown file extension.) You may need to remove a line due to a missing file (it will be present in the next release) and you can edit the flags (and path if needed) at the top.
you can just rename the file extension to something github supports and then say what extension (if any) it should had. so you can upload it directly instead of using an external file hosting site.
i had to comment out the commands and remove references to the files s_propagateNaNF64UI.o
and f64_to_ui64.o
, change ROOT=/usr/local/lib/calypsi-65816
to ROOT=.
(since i ran it within the calypsi folder), and add the --enable-huge-attribute
flag (since that was the whole point)
but it seems to have worked... somewhat.
when linking with the generated library, the linker conplains that it cannot place the zdata
section. according to the guide that section should only exist with the small data model, but that makes no sense considering the whole library was built with the --data-model medium
option....
i did find the file that has the zdata
section in it, it's atexit.o
. looking into the script it is build as any other file with the --data-model medium
option. so could be happening here?
.
on another note i did try to use your script to create a more "normal" makefile. but similar to your script, while it runs (especially fast with -j24), the generated libary refuses to link. this time with undefined reference errors to _Vfp
, _Mod32
, _Shr64
, _Mul64
_MoveLongFar
, and a looooooot of _Dp
.
so clearly i did something very wrong!
you can take a look yourself if you want:
makefile.txt
(just remove the .txt extension and place the makefile inside the calypsi/src
directory next to the lib
and softfloat
directories, also you need to export the calypsi/bin
directory to PATH
before running make
)
It is expected that there are a couple of floating point modules missing at this point, they will be part of the next release. For now the script is not all that polished, the main reason is to have something that helps in rebuilding the library, for the few situations it may be needed.
I compiled aexit.c
with cc65816 --enable-huge-attribute atexit.c -l --data-model=medium
and it has znear
in the list file, no zdata
.
The _Vfp
and the other undefined symbols are defined in assembly modules.
just as you commented i found an error in the makefile that causes none of the lowlevel assembly files to be listed in the required object files for the library, so they were never assembled and put into the library...
in the makefile, on this line:
# Extra Object files (S)
EXOBJA := $(patsubst %.s, $(LIBOBJDIR)/%.o, $(notdir $(EXSCRA)))
EXSCRA
had to be changed to EXSRCA
(swapping the C and R)
# Extra Object files (S)
EXOBJA := $(patsubst %.s, $(LIBOBJDIR)/%.o, $(notdir $(EXSRCA)))
I also had to remove --weak-symbols
from AFLAGS
since only 1 file was actually using that while assembling.
and now everything compiles fine and i can actually link with the library! you can fix the makefile i posted in case you want to polish it up and include it in the next release so people can more easily build the library themselves (with some extra parameters to allow users to compile with different code and data models, 32/64-bit floats, huge enabled/disabled, etc).
.
as for atexit, the command in the script you sent is:
cc65816 -o objs/clib-cc-md/atexit.o ${ROOT}/src/lib/stdlib/atexit.c -Wno-unused-value --weak-symbols ${CFLAGS} -I${ROOT}/src/lib -I${ROOT}/src/softfloat
where CFLAGS
contains --data-model medium
. which is why i'm so confused by that. i did some more testing by using set -x
to have the script evaluate every variable and then print the command it runs and this is what it does for all files:
++ cc65816 -o objs/clib-cc-md/atexit.o ./src/lib/stdlib/atexit.c -Wno-unused-value --weak-symbols -O2 -I./src/lib -I./src/softfloat
CFLAGS
only evaluates to -O2
, all the extra parameters after it seem to be completely ignored.
i changed the lines for CFLAGS
and AFLAGS
, replacing the parenthathese with single quotes like this:
CFLAGS='-O2 --space --code-model=compact --data-model=medium --32bit-doubles --core=65816 --enable-huge-attribute'
AFLAGS='--core=65816 --code-model=compact --data-model=medium'
and that seems to have fixed the issue (also now the library file generated from the script is the same exact size as with my makefile, confirming that it works as intended).
.
btw, is there a way to tell the linker which clib file you want to compile with, instead of it choosing one on it's own? because i'd like to keep the original clib-cc-md.a
, so i named the newly generated one clib-cc-md-huge.a
but the linker always grabs the original, even when i specify clib-cc-md-huge.a
in the command.
being able to overwrite the linker's automatic clib choice would be a nice to have feature, specifically for stuff like this.
I had some troubles with the quoting of flags which for some reason did not work using either single or double, so I found this parentheses way, which apparently does not work. Now I retried single quotes as you point out and it works. I have no idea how I messed that up before.
The reason I do not do a make file is for simplicity. I do not expect many people will need to rebuild the library, and I have seen some using build scripts, so I decided to provide a starting point that is as basic as possible.
It was intended to work replacing the C library on the command line, but I can see that my logic for doing that was not right. I have reworked it for the release which I plan to make during the coming week.
Closing this for now. There is a starting point for end users to build their own libraries. Also the missing files prior has been added, so I regard this is done.
i've been somewhat trying to see if i could get FreeRTOS running on a 65816. but sadly ran into some issues when compiling the
port.c
file.i started commenting out functions and later indivitual lines to see which one was causing the problem (is it be possible to have internal errors report the last line number it was working on to make this step easier in the future?)
and i found that it gave me that error in a function that sets up the stack for a newly created task (ie write status register, entry point for execution, etc), more specifically on the line that writes the address of the task's function to the stack/memory. i isolated the function and all it required into a seperate C file, so you should be able to replicate it:
with the command:
also in case you're curious, the basic FreeRTOS kernel (list.c, queue.c, and tasks.c) compiles to a combined ~16kB of code. which is honestly quite impressive for what is almost a complete regular OS.