DIFF attached for comment and review. Provides the following features / difference:

1) Switched operation of cpuinfo.pas - there is still a SET containing the ct_ constants, but that now indexes an array of structures rather than a collection of arrays. The array contains the info from the old arrays, PLUS FLASH, SRAM and EPROM memory definitions i.e. BASE and SIZE for each. NOTE: Switched for both ARM and AVR. AVR changes will compile the cross compiler, but choke while building the RTL (complaining about a function being too complex). However, the SVN and daily build exhibit the same behaviour - so I do not believe I have broken the AVR any further than it was broken.

2) Added LM3FURY controller unit file - this will be built up into a base unit file for all the Fury class Stellaris controllers.

3) I intend to leave the "Stellaris" controller class with the intention that those that don't want a full set of system defines can use this class and will receive nothing more than the bare minimum to boot a chip into PASCALMAIN. The Flash and SRAM sizes will be set very large - so caveat emptor to the user if, as they will need to ensure the programs do not require more resources than their chip require.

4) t_embed.pas was changed. The case() statement is still in there, but all the cases fall down to the same code - which uses the cpuinfo.pas memory definitions to create the linker file.

5) put a test in t_embed.pas - if we are only compiling to assembly, then we skip the Internal Error on not having a link definition.

6) option.pas, globals.pas, ncgutil.pas and pmodules.pas were modified to accommodate the addition of the structure.

7) IF controllerunitstr is empty - then no added file is included in the build (again, to support a "base" controller type - with no defines what so ever - power user option)

NOTE: The Makefile changes were picked up by svn diff - not sure why they changed so much, my incantation of fpcmake must be different than the original sources code

NOTE: The AVR link script generation has not been changed to accommodate the additional information - the original link script did not set memory sizes to match the processor.

John

It actually renders it unusable if the ram size is bigger than that in the device you are using as the stack top will be set outside the available ram. It has only ever worked before with the correct ram/flash sizes as I pointed out to you. It should be for specific known combinations, the ct_stellaris was incorrect before you diff'ed it, and now you have introduced another error (stack_top=0x20fffc?).

Personally, as somebody using this compiler on real projects, I think there are too many changes proposed here in one hit, completely untested.

festina lente

Actually, I removed the hard coded stack_top, and put in a line to place stack_top at the very top of RAM - dependent up on the settings in the controller structure.

+              Add('_stack_top = 0x' + IntToHex(sramsize+srambase-4,8) + ';');

This sets stack_top to the very top of the SRAM space minus 4 bytes. So long as the srambase and sramsize are correct, the stack pointer will get set to the top of SRAM.

Not sure how you are making your conclusion. Any line with "stack_top=0x20fffc" is being deleted with this patch.

However, if I might ask - which controller are you using this on ?

Thanks,

John

________________________________

ok, it should have been 0x2000fffc to start with if it is for a 64k device. Somebody also posted that stack_top could be ram_size+ram_base, I suppose because the sp is decremented before writing. But I am no expert on this. I have had obscure warnings from Keil MDK when linking (from C, yes it works) to units compiled with FPC, and I have wondered whether it is stack alignment, but not got much further with it.

However, if I might ask - which controller are you using this on ?

LM3S9B92 is what I used to test the existing stellaris startup on. I am now using LM3S9B95 and LM3S5D51, the latter being 512k flash/96k ram. These are 'tempest' class devices I think; I would suggest not bothering about the earlier classes of device. And that is another reason I don't think detailed device info should go in the compiler. As there is no OS I think the minimal RTL and info essential to the compiler/as/ld ie. flash, ram size, should be there as compiler user options, but nothing device specific.

Geoffrey

tcontrollerdatatype should be declared only once.

2) Added LM3FURY controller unit file - this will be built up into a base unit file for all the Fury class Stellaris controllers.

The file is missing.

7) IF controllerunitstr is empty - then no added file is included in the build (again, to support a "base" controller type - with no defines what so ever - power user option)

This should be boundy to some controller type like dummy else beginners will stumble on it.

Besides this, the patch can be applied imo.