[fpc-devel] ARM patch to switch to controller records rather than arrays

[Geoffrey Barton]

On 21 Aug 2011, at 13:47, John Clymer wrote:

> 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.

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
> 
> Thanks,
> 
> John
> 
> From: Geoffrey Barton <mrb at periphon.net>
> To: FPC developers' list <fpc-devel at lists.freepascal.org>
> Sent: Sun, August 21, 2011 2:46:55 PM
> Subject: Re: [fpc-devel] ARM patch to switch to controller records rather than arrays
> 
> 
> On 21 Aug 2011, at 00:35, John Clymer wrote:
> 
>> 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.
> 
> 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
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110821/10bcc3a5/attachment.html>