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

[John Clymer]

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




________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110821/69d3b7ba/attachment.html>