Re: [fpc-devel] Cortex-M0 (SAMD21G18A) and gcc-arm-none-eabi-8-2018-q4-major-win32

[Michael Ring]

Quite a number is already in on trunk, but as the support for devices is 
getting bigger and bigger (at least on my harddisc) there is a need for 
an inteligent mechanism to handle the huge amount of devices as the 
header files eat up a lot of space in svn and only a very few will 
actually get used.


Jeppe once had provided a nice mechanism to me but it never made it to 
trunk. From the last comment of Florian on the topic the door id open 
for implementing something that makes handling easier, but honestly I 
did not spend much time on this.


Do you use a board like the Arduino Zero or do you work with plain, not 
pre-programmed chips?


I am asking because in case you use Arduino Zero there will be some 
obstacles for you to get rid of the preinstalled bootloader that you 
will most likely have to face.


Contact me in that case, I have already been down that road and have a 
working solution. (see 
https://learn.adafruit.com/proper-step-debugging-atsamd21-arduino-zero-m0/restoring-bootloader)


Michael

Am 27.05.19 um 12:53 schrieb Dimitrios Chr. Ioannidis via fpc-devel:

Hi Michael,

On 2019-05-26 14:14, Michael Ring wrote:

Just one note of caution:

When you encounter strange behaviour of your Code on Cortex-M0 in
respect to DIV commmand then check the mailinglist, Jeppe has provided
a fix but I am not quite sure if the fix has made it into official
trunk.


thx for the hint.

By the way, any chance for inclusion your MCU definitions if official 
FPC ?


regards,


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Cortex-M0 (SAMD21G18A) and gcc-arm-none-eabi-8-2018-q4-major-win32

[Dimitrios Chr. Ioannidis via fpc-devel]

Hi Michael,

On 2019-05-26 14:14, Michael Ring wrote:

Just one note of caution:

When you encounter strange behaviour of your Code on Cortex-M0 in
respect to DIV commmand then check the mailinglist, Jeppe has provided
a fix but I am not quite sure if the fix has made it into official
trunk.


thx for the hint.

By the way, any chance for inclusion your MCU definitions if official 
FPC ?


regards,

--
Dimitrios Chr. Ioannidis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Core] Haiku merges: Revision 42117

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 27 May 2019, Pierre Muller wrote:

>   The merge of the two commits generate 3 conflicts, but those are easily 
> solved.
> See attached patch.
>
>   Olivier, did you test the fixes_3_2 branch?
> Do you think it is reasonable to enable x86_64-haiku target in that branch?

I think if all the changes are merged, it's safe to enable at least, but
it needs to be tested of course. I only tested trunk.

>   charlie, you wrote those patches, thus
> it is probably best if you or Olivier decide:
> Should I merge them?

I think they should be merged, but Olivier is the maintainer. But as the
RTL changes are merged already (Marco did it after asking me), I think the
associated compiler changes should be merged too.

I'm unaware of any Haiku regressions compared to before my changes, OTOH
after my changes the entire thing is much cleaner and of course supports
x86_64 as well. If anyone is aware of any regression, I'm gladly fixing
them ASAP both in trunk and then it can be merged to 3.2 as well.

Charlie
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Core] Haiku merges: Revision 42117

[Pierre Muller]

  The merge of the two commits generate 3 conflicts, but those are easily 
solved.
See attached patch.

  Olivier, did you test the fixes_3_2 branch?
Do you think it is reasonable to enable x86_64-haiku target in that branch?

  charlie, you wrote those patches, thus
it is probably best if you or Olivier decide:
Should I merge them?

Pierre


Le 26/05/2019 à 15:17, Pierre Muller a écrit :
>   Hi al,
> 
> almost every haiku RTL changes have been merged,
> but there are also two compiler changes:
> 
> [muller@gcc121 pas]$ svn log -v -c 40753 trunk/fpcsrc/
> 
> r40753 | karoly | 2019-01-04 02:16:24 + (Fri, 04 Jan 2019) | 1 line
> Changed paths:
>M /trunk/compiler/options.pas
>M /trunk/compiler/systems/i_haiku.pas
>M /trunk/compiler/systems/t_haiku.pas
>M /trunk/compiler/systems.inc
>M /trunk/compiler/utils/ppuutils/ppudump.pp
>M /trunk/compiler/x86/agx86att.pas
>M /trunk/compiler/x86_64/cpuelf.pas
>M /trunk/compiler/x86_64/cputarg.pas
>M /trunk/packages/fpmkunit/src/fpmkunit.pp
>M /trunk/utils/fpcm/fpcmmain.pp
> 
> haiku-x86_64: add target to the compiler and ppudump, enable it in fpmake and 
> fpcmake
> 
> [muller@gcc121 pas]$ svn log -v -c 40756 trunk/fpcsrc/
> 
> r40756 | karoly | 2019-01-04 03:00:03 + (Fri, 04 Jan 2019) | 1 line
> Changed paths:
>M /trunk/compiler/systems/t_haiku.pas
>M /trunk/compiler/systems.pas
> 
> haiku: linker support code for internal sysinit and make the x86_64 port use 
> it
> 
> 
> 
> Shoudln't these two be also merged to fixes?
> 
> 
> Pierre
> 
> 
> 
> 
> 
> ___
> core site list
> c...@freepascal.org
> https://idefix.freepascal.org/cgi-bin/mailman/listinfo/core
> 
Index: .
===
--- .   (revision 42129)
+++ .   (working copy)

Property changes on: .
___
Modified: svn:mergeinfo
   Merged /trunk:r40753,40756
Index: compiler/options.pas
===
--- compiler/options.pas(revision 42129)
+++ compiler/options.pas(working copy)
@@ -138,7 +138,7 @@
 + [system_i386_wdosx];
 
   suppported_targets_x_smallr = systems_linux + systems_solaris + 
systems_android
- + [system_i386_haiku]
+ + [system_i386_haiku,system_x86_64_haiku]
  + [system_i386_beos]
  + [system_m68k_amiga];
 
Index: compiler/systems/i_haiku.pas
===
--- compiler/systems/i_haiku.pas(revision 42129)
+++ compiler/systems/i_haiku.pas(working copy)
@@ -105,6 +105,76 @@
 llvmdatalayout : 
'e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32';
   );
 
+const
+   system_x86_64_haiku_info : tsysteminfo =
+  (
+system   : system_x86_64_Haiku;
+name : 'Haiku for x86_64';
+shortname: 'Haiku';
+flags: 
[tf_under_development,tf_needs_symbol_size,tf_files_case_sensitive,
+
tf_pic_default,tf_library_needs_pic,tf_smartlink_sections,
+tf_has_winlike_resources];
+cpu  : cpu_x86_64;
+unit_env : 'HAIKUUNITS';
+extradefines : 'BEOS;UNIX;HASUNIX';
+exeext   : '';
+defext   : '.def';
+scriptext: '.sh';
+smartext : '.sl';
+unitext  : '.ppu';
+unitlibext   : '.ppl';
+asmext   : '.s';
+objext   : '.o';
+resext   : '.res';
+resobjext: '.or';
+sharedlibext : '.so';
+staticlibext : '.a';
+staticlibprefix : 'libp';
+sharedlibprefix : 'lib';
+sharedClibext : '.so';
+staticClibext : '.a';
+staticClibprefix : 'lib';
+sharedClibprefix : 'lib';
+importlibprefix : 'libimp';
+importlibext : '.a';
+Cprefix  : '';
+newline  : #10;
+dirsep   : '/';
+assem: as_x86_64_elf64;
+assemextern  : as_gas;
+link : ld_none;
+linkextern   : ld_haiku;
+ar   : ar_gnu_ar;
+res  : res_elf;
+dbg  : 

Re: [fpc-devel] Compiler picks wrong overload

[Martok]

> More broadly I think the bigger problem is FPC's internal over-eagerness to
> implicitly cast things to other things... for example, if you have a type with
> an ":=" operator overload (or as Delphi calls it, an "Implicit" operator
> overload) from both "Pointer" and "TObject", FPC will always pick the 
> "Pointer"
> one even if given an explicit TObject variable. They (currently) cannot
> co-exist. But certainly, they should be able to, if you ask me.

I still find "nil->Pointer->dynarray->UCS4String" the most hilarious "weight 1"
autoconversion (see 0031215, which is also an overload bug).


-- 
Regards,
Martok


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [PATCH] Add support for Hygon Dhyana processor

[Jinke Fan]

On 2019/5/25 3:53, Ralf Quint wrote:

On 5/23/2019 2:10 AM, Jinke Fan wrote:

Hi,
   This patch adds vendor id detection for Hygon Dhyana CPUs.
   Could anyone help me with submit it?
More details can be found on:
http://lkml.kernel.org/r/5ce86123a7b9dad925ac583d88d2f921040e859b.1538583282.git.pu...@hygon.cn


Why would this be needed? I just had to look up what this actually is 
and it doesn't seem to be necessary to distinguish between that 
particular CPU (quote from Wikipedia):


The initial microprocessor created in 2018 is the Hygon Dhyana 
 system on a 
chip .^[1] 
 
^[2] 
 
It is noted to be a variant of the AMD EPYC 
 and is so similar that "there is 
little to no differentiation between the chips".^[1] 
 
It has been noted that there is "less than 200 lines of new kernel 
code" for Linux  kernel support, 
and that the Dhyana is "mostly a re-branded Zen CPU for the Chinese 
server market".^[2] 
 


^Are you aware of any specifics of that processor that it would require 
a distinction and direct support for that CPU version, beside the geek 
factor?

Dhyana process was the first generation of Hygon. And,
"there is little to no differentiation between the chips".

The spec refer to:
https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
At the software level, code typically reuses AMD's code path as so far.

Best regards.
Jinke Fan


^Ralf


 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel