Internal Linker Error "Non-exhaustive patterns in function dumpRawProgram" [3.6.2]

[ProxyPlayerHD]

as requested in this 6502 forum thread i'm opening an issue here to hopefully at some point have something working. refer to the linked thread for more detail

but basically this error comes up: internal error: Translator\Linker\Output\Raw.hs:14:1-60: Non-exhaustive patterns in function dumpRawProgram

when trying to compile this bare bones project: 65C816.zip

to use the 0_C.bat files, just drag&drop the .c or .s file you want to compile/assemble onto them, or run them from the commandline. if you're on linux, just copy the commands from the .bat files and run them manually. note that the linker command is currently set for pgz so obviously that needs to be changed to raw for the error to occour.

[hth313]

The problem here is that you are mixing sections that generates program bits with nobits (bss). The linker does not detect the problem due to a too simplistic sanity check. This is also what cause the internal error. I have fixed the internal error to provide a more sensible error and also fixed the sanity checking about mixing sections of different types. Now, it is still possible to accomplish what you try to do, it just have to be done slightly different and the latest version should be able to do it in a simple fashion. The .scm file needs to be changed:

(define memories'(
    (memory DirectPage  (address (#x000100 . #x0001FF))
        (section (registers ztiny)))
    (memory LoRAM   (address (#x000200 . #x00EFFF))
        (section stack heap))
    (memory IO      (address (#x00F000 . #x00F0FF)))
    (memory VRAM    (address (#x010000 . #x01FFFF)))
    (memory HiRAM   (address (#x020000 . #x08FFFF)) (type any))
    (block stack    (size #x004000))
    (block heap     (size #x004000))
    (base-address _DirectPageStart DirectPage 0)
    (base-address _NearBaseAddress LoRAM 0)
))

I removed the cstack block, it does not exist for the 65816, that is something for the 6502 only. I also removed all sections in HiRAM and tell the linker it can put anything it wants there. The linker will put all suitable sections there in different placement groups, basically different memories inside the memory. This provides the separation of segments (memory areas) which is needed for the ELF format. It still puts them all next to each other, it just groups them properly and provide a correct output.

If you still get problems after changing the .scm as described, let me know. It may be that I need to provide an update of the linker as there has been some corrections recently related to the automatic placement.

[ProxyPlayerHD]

that seems to have worked! at first i was getting a lisp error but i just forgot a closing bracket in the .scm file, oops. i didn't know cstack was 65c02 exclusive, it makes sense in retrospect but i just though the compiler used both somehow...

anyways, just as a little sanity check, in the pgz format, the last 6 bytes tell the loader where to jump to to start the loaded program, correct? so in this case the last 6 bytes are: 36 02 02 00 00 00 so it jumps to address 0x020236, which i assume points to __program_start in the cstartup code. but the .lst file says that farcode starts at address 0x02008E, so it's actually jumping 424 Bytes into the farcode section... but where does that point to?

honestly i wish the linker's .lst file would be a bit more detailed, and like cc65's .map file and show you all symbols/labels and their values.

[hth313]

You can get more information by adding --cross-reference to the linker. This shows every section included, references back and forth to tell you why it is included and where it is placed.

I get d1 0002 0000 00 at the end, so 200d1 is the start address and 000000 indicates size is 0, so that means 200d1 is the entry point.

Looking in the list file (with cross reference):

__program_start in section 'farcode'
 placed at address 0200d1-0200e9 of size 000019
(Config/cstartup.o unit 0 section index 2)
    Defines:
        __program_start = 0200d1
        __program_root_section = 0200d1
    References:
        _DirectPageStart
        _NearBaseAddress
        .sectionEnd(stack)
        _Vfp in (pseudoRegisters.o (from clib-lc-ld-double64.a) unit 4 section index 2)
        __low_level_init in (Config/cstartup.o unit 0 section index 7)

[ProxyPlayerHD]

ah, i see. very nice! that will become useful for debugging things. and yes for me __program_start is actually located at 0x020236

[ProxyPlayerHD]

well since this is solved i can just close the issue. but while i'm at it, i gotta ask something i don't think i saw being asked yet: why are the tools closed source?

we pretty much only have a single true 65816 C Compiler, WDC's. and that one is pretty much abandonware and overall just shows it's age. so why add another closed source one to that already tiny list? wouldn't it just meet the same fate when you decide to stop working on it, or something were to happen to you before you could publish the source code? obviously it's your decision, but i'm just cursious for the reasoning behind that decision.

[hth313]

The WDC 65816 compiler source code is around. There are one or two in the Foenix community that signed NDA and have access to the source repository. What and if they are actually doing something with it I do not know. There was a desire to make a Linux version, but I know nothing more than that.

I am not planning to stop working on my code base, I have spent 6 years on it so far and it is not going away. I do keep off-site backups of it and I am aware that I should safe guard the code base at some point, it is for sure in my mind.

The reasoning why it is closed source is long, but the main reason is that I want to keep control over the code base, to ensure a certain level of standard of work being done with the products. This both includes people that know what they are doing and that follows certain release procedures, like doing proper testing. It is all about reaching a certain level of quality and having a solid product.

There are plenty of open source alternatives around, admittedly not for the 65816, but I did not have any 65816 compiler until I decided to make one and put in the work needed. Most of the work is not in the 65816 itself, but in the surrounding target independent framework, and there are several such around .

[ProxyPlayerHD]

oops, sorry for the very late reply! i honestly forgot about this and today i came back for some other issue (that i'll open shortly after this) and remembered that i didn't reply yet.

The WDC 65816 compiler source code is around. There are one or two in the Foenix community that signed NDA and have access to the source repository I'm honstly surprised WDC wants to keep the source so closed up that they make people sign NDAs to be able to see it, it's so ancient it doesn't even support binary notation....

anyways i'm a bit confused why you would think that open sourcing it would reduce the quality of the utility, that's not really how open source works. yes people could make copies of the code and modify those however they want (well it depends on the licence, plus you can disable forks), but they couldn't touch the actual master branch without your approval (and make them run various tests on any changes, so that it's up to your standards). plus it would make installing simpler on Linux as you could just use the git command to get the newest version and then build it via make, instead of having to use gdebi which requires you knowing exactly what version you want.

but of course it's also a lot more work maintaing a repo (especially if you're the sole owner) depending on how many push requests and issues you have to deal with.

so i guess i can understand both options, having it either open source to put some of the workload on the community (or have the community help you), or having it closed source to keep ultimate control over it without having to deal with other people's code that might not be up to your standards.

Most of the work is not in the 65816 itself, but in the surrounding target independent framework, and there are several such around. yes that is true i guess... a 65816 Compiler Utility doesn't need to do the whole Compile-Assemble-Link chain, it only needs to compile to ca65 compatible assembly code and the rest can be done by the cc65 utilities. hmm, i shouldn't be thinking about that too much because otherwise i'll start a new project of making a compiler myself and i'm definitely not qualified for that! lol

[hth313]

Even if it was open source you would have a chore to build it, it is not just git clone and make. Well, once you have the work environment set up it can be built with a single command, but getting there requires a deep dive into versions and not always stable products. I have had a pre-runner of this project as open source, not a single soul tried to build it. I have numerous open source projects and very little interest in them. The board support for the C256/A2560 Foenix machines have been a minor exception. I have a remote debugger agent which does not run on some specific hardware. It is possible to take a small step and make it work on other hardware, but there is no one doing it. Even when I offered to give advice in the process (mentioned it, I would anyway), but so far nothing. That project can be handled with a git clone and make and it is to a good degree part of the overall project. The master project is in a completely different dimension. If I cannot get anyone interested in working on support projects, which definitely is a good starting point for working on the code base, then the chance of having people working on the master project is miniscule. There are also board support projects that could be worked on, for the Commodore 64, the Mega 65 and Apple IIgs (and beyond). I have been in touch with individuals in those communities, but so far nothing seem to happen. At some point I may open source it, but it will be some years down the road. No worries that it is going away, I have backups both on and off site. I worked for years on the project and enjoy it a lot, so I will not lose interest in this. The idea that I had from the start is to provide tools that allows you to focus on your own code, not mess with or work on the tools. I hope that interest takes up, but it has to come from within, people working on support projects (which are open), rather than me exposing it and getting miserable that nothing real comes out of it. The code base requires a lot of understanding and it is large.