GNU AS?
GAS doesn't follow the common ".org" directive used by Motorola' AS (Sierra and similar), but rather it delegates to the linker's script, where you have to describe sections.

This is using vasm not GNU AS but it is similar. The linker script I tried is one in a previous post. If ELF is selected as the output format from vasm then a ‘missing PHDRs’ error occurs during linking. If bin is selected then the linker says it is not a supported format. So, I am trying to use just .bin output directly from the assembler, bypassing the link stage.

This project is kind of stuck if a larger program cannot be built for testing.

There is no OS; code needs to be in ROM. There isn't a file system or a program loader available. One thought I had was to try writing a simple loader for something like S37 format. But a text file occupies too much room in ROM. Even if a loader is written how does it get to a ROM image?

OK. Thanks!

I've just had a quick play with this, and the PHDR problem you're having appears to be related to the AT attribute in the link script - removing that causes my test program to build just fine. For my experiments in the past I avoided this problem by simply disallowing mutable non-zero data in the ROM - anything predefined was read-only, anything mutable was BSS. I created a very small TRAP memory region, and directed .data sections there to make the linker throw an error if I had mutable data in the ROM. There might well be a better solution, but right now I don't know what it is.

(The linker output switch you want is "-brawbin1" by the way - vasm calls it bin, vlink calls it rawbin1, just to keep things simple and consistent!)

If you need to bootstrap from ROM into RAM then the best bet is probably to compress your binary image with LZ4 or suchlike, and include some decompression code. I did something similar for MIPS once when I had plentiful RAM but needed to get an SD-card-reading bootloader into just 4K of ROM.

(LZ4 is *really* simple - here's the 68K decompression code I used as reference: https://github.com/arnaud-carre/lz4-68k ... allest.asm - Note: the LZ4 compressor creates a small header which will need to skipped over or stripped off.)

That is pretty drastic. I do not think that pre-initialized mutable data can be omitted from the system I am building. I spent some more time experimenting and managed to come up with something that appears to work. I had to change the system's memory map.

The following linker script is now in use. I think the PHDRS are redundant, but it works.


The assembler keeps insisting on putting the .data section before .code. So, I altered the system to place the bios data area just before the code.
Finally, the rom is being built in a manner that can be set in bram.

Latest Fixes:
<hardware>A signal to update the link register was not propagated in the pipeline from the register fetch stage. This caused the link register to never be updated resulting in a crash on return from subroutine.

Milestone:
It looks like the core managed to execute the rand() routine from stdlib successfully. The next step will be to build up the test system in the FPGA. The text controller may need to be modified. The first demo will be just to place random characters on-screen.
Here is the current system memory map.

I changed the reset address to $FFFD0000.

If you have trouble with the order of sections (I think they're emitted in numerical address order?) - or if you want sections with large address gaps between them, one option is to use the -brawbin2 option with vlink - then you get a separate binary file for each section. You're then free to embed those within your ROM however you see fit, and copy the mutable data section to its final location at boot should you so wish.

Glad to see you've found a solution, anyway - have fun!

There is code in the assembler to select numerical order, but it is irrelevant since each section is org’d at zero automatically. (I put debugging code in to see what was going on.)

The -rawbin2 options sounds like it would work.

Since the sections all have the same address, the assembler/linker just picks one (the data section) to place first. When binary output is selected this causes a ‘sections can not overlap’ error. Unfortunately putting in an .org statement in each section does not help because .org works in a strange fashion, moving relative to the start of the current section. As far as I can tell there is no way to .org sections continuously in memory. This seems strange to me because for binary output it is needed to build images that fit into specific areas of memory.

My own assembler works differently. A new section can be started continuously from a previous section, and it places the sections in order of first appearance. It makes it easy to generate a predictable ROM image using just the assembler. Alas my assembler does not handle PowerPC code, and I desire to use a linker as well.

Unless I'm missing something, won't it emit the sections in ascending address order, as defined by the MEMORY directives? So it was picking data first because that has the lowest address?



If I'm understanding correctly, your problem here is that you want them continuous in the emitted binary file and thus the ROM, but for the references to be correct after the data section has been copied from the ROM image to its final location.



Well, like I say, the rawbin2 format helps, but I think the linkscript syntax you're looking for might be this:

Latest Fixes:
<hardware> Propagation of the compare decode signal got missed. This led to condition register updates being missed. Ultimately causing branches to fail. Divide was returning the fractional portion of the divide instead of the whole quotient portion.

All is good at the moment, there is code that can be executed from BRAM. It should work good enough to allow a loader to be written. The goal is to load software via the PTI (parallel transfer interface). Anyone know of a small OS (<512kB) that can be run on the PowerPC?

In my compiler, the stride of the enum can be passed as an parameter like so:

Which tells the compiler to assign enum values, decrementing by one for each value. It is a pita to convert to a compiler that does not support the feature.

Stuck on this error now: internal error in compiler:

Needless to say without seeing the actual code it's choking on no-one can help there - but I see you're using vbcc 0.9f. It's worth trying 0.9g from http://sun.hasenbraten.de/vbcc/ or the development snaphot of 0.9h pre at http://www.compilers.de/vbcc.html

If both of those fail, have a look at the vbcc/machines/ppc/machine.c file to see what's going on at the line of the internal error - it might give you a clue as to what it is about the code it doesn't like. If the code is valid standard C and still won't compile with 0.9h then report the bug!

Yeah, I had a look at machine.c. It appears to be croaking trying to load an address value into a register.
This is the line it croaks on according to the error message:

It looks like o->flags&VAR is not a VAR.
Unfortunately it is just a guess as to what line of source code is failing. I note the line number given for the source code is the same line number as in machine.c. This would be one heck of a co-incidence, or the line number is not reported correctly.
This is the routine that begins at line 323 of source code. It is pretty standard C code. I do not see where an address value is being taken which makes me think the issue is elsewhere in the source code.

Some printfs in load_address() might give you a clue what's going on.

something along the lines of
printf("Flags: %d, Var %s",o->flags,o->Var->identifier);
will, if you're lucky, give you the name of the variable it's choking on. If you're not lucky you might need to guard against o->var->identifier being NULL.

You can also put something like:
if (p->file)
printf("File %s, line %d\n",p->file, p->line);

in the gen_code function's inner loop, (just after the " for(;p;pr(f,p),p=p->next){" at line 2775) to get a running commentary of which source line is being processed before it crashes.

(Also have a look at the supp.h header file and the backend interface documentation http://www.ibaug.de/vbcc/doc/vbcc_13.html if you need to get more details of the obj and var structures.)

I got the var it is choking on: "key". This is simply an int parameter nothing strange.



I fixed up a couple of the warnings and now it does not choke on that line, but it also does not complete successfully.
PS. The line 323 *was* just a co-incidence. Adding more code changed the line number.
It just quits now with no explanation.

More digging required.
I will try and find a newer version of the compiler.

Came up with a scalar in-order version of the core. Without caches or memory management and no floating-point. The core is pipelined with each stage taking multiple clock cycles. The core is only about 1000 LUTs.
Got the nPower SoC built and running in an FPGA. The LEDs light up with the correct pattern! And the four A’s appear onscreen. I made a simple demo of randomly updated characters onscreen, but I forgot to seed the random number generator. This resulted in the same screen position being updated with the same data constantly. So, there was no visible screen update. I thought the processor was hung, but it turned out to be software. Well, the simple demo is not working quite yet.
The demo is programmed in ‘C’ and compiled with the vbcc C compiler.