const m_pi=3.14159265358979323846
type sine_wave_generator
declare sub set_cycle(cycle as single)
declare sub add_modulation(x as long)
declare function get_next() as longint
declare function get_next(modulation as long) as longint
position as unsigned long
_step as unsigned long
end type
enum ADSR
ATTACK
ATTACK_RELEASE
DECAY
DECAY_RELEASE
SUSTAIN
RELEASE
SOUNDOFF
FINISHED
end enum
type envelope_generator
declare sub set_rate(rate as single)
declare sub set_hold(value as single)
declare sub set_freeze(value as single)
declare sub key_off()
declare sub sound_off()
declare function get_next() as longint
state as ADSR
AR as longint
DR as longint
SR as longint
RR as longint
TL as longint
fAR as unsigned long
fDR as unsigned long
fSR as unsigned long
fRR as unsigned long
fSL as unsigned long
fTL as unsigned long
_fOR as unsigned long
fSS as unsigned long
fDRR as unsigned long
fDSS as unsigned long
current as unsigned long
rate as single
hold as single
freeze as single
declare sub update_parameters()
end type
type fm_operator
declare sub set_freq_rate(freq as single, rate as single)
declare function get_next() as longint
declare function get_next(modulate as longint) as longint
declare function get_next(lfo as longint, modulate as longint) as longint
swg as sine_wave_generator
eg as envelope_generator
ML as single
DT as single
ams_factor as long
ams_bias as long
end type
function fm_operator.get_next(ams as longint, modulate as longint) as longint
return (cast(long,swg.get_next(modulate)) * eg.get_next() shr 15) * (ams * ams_factor + ams_bias) shr 15
end function
Please confirm or deny this. Is there really a bug?
I get:
Aborting due to runtime error 12 ("segmentation violation" signal)
Yes, compiler aborting, but just with 'gas'.
Can you test with 'gcc' ?
Are you sure you are using the correct operator precedence ('shr' vs '*') ?
Each 'shr 15' applies on each full expression at their left !
(close to 'shr 30' in total !)
in type sine_wave_generator declare function get_next(modulation as long) as longint, modulation is LONG
but in
function fm_operator.get_next(ams as longint, modulate as longint) as longint
return (cast(long,swg.get_next(modulate)) * eg.get_next() shr 15) *
parameter is LONGINT and swg is dimmed as sine_wave_generator
I hardly understand the code maybe it doesn't mater.
In 64bit
D:\fbdebugger\fbdebugger-New\test5.o:fake:(.text+0x2e): undefined reference to `SINE_WAVE_GENERATOR::GET_NEXT(int)'
D:\fbdebugger\fbdebugger-New\test5.o:fake:(.text+0x48): undefined reference to `ENVELOPE_GENERATOR::GET_NEXT()'
Are you sure you are using the correct operator precedence ('shr' vs '*') ?
Each 'shr 15' applies on each full expression at their left !
This is not my code, but the code angros47, so I can't say. I tried different options with the Longint type and got this error.
SARG! It does not matter whether the code is competently or incorrectly , the main thing is that the compiler is confused and reports a segmentation error. It shouldn't be, shouldn't it be? Or am I wrong? And yes originally in the code angros47 everywhere there was a type of integer!
@fxm
I randomly tried to get a workable version. As a result, I found an error not in the angros47 program, but in the compiler
Just when I do not know where the error is, I begin to frantically change everything in a row and sometimes by a random method it turns out, as in the case of: viewtopic.php?p=295288#p295288
I never said there is no compiler bug (at least for 'gas').
To me there is both a compiler bug and a code line with the 2 'shr 15' which looks quite dodgy.
fxm wrote: ↑Oct 19, 2022 14:12
I never said there is no compiler bug (at least for 'gas').
To me there is both a compiler bug and a code line with the 2 'shr 15' which looks quite dodgy.
fxm , as I wrote, it's not my code and I haven't even thought about the code and don't know if it's right or wrong. Maybe you're right.
type tt1
declare function gn() as longint
ar as longint
end type
type tt2
declare sub gn()
eg as tt1
v1 as long '<<-- if longint : no crash, only here or only below
end type
sub tt2.gn()
dim as long vlg '<<-- if longint : no crash
dim as longint vlgt
vlgt= (eg.gn() shr 1) * (vlgt * vlg + v1) '<<-- switching the 2 parts of multiplication : no crash
end sub
I pushed changes to fbc/master that should fix this.
Under the hood, regFindFarest() is called when all the registers are allocated to virtual registers in the current statement/expression and registers need to spill to allow the next emit operation. On gas x86, there's only 6 registers to work with so I'm surprised this bug was never found before now - it's an old one.
coderJeff wrote: ↑Oct 22, 2022 19:39
I pushed changes to fbc/master that should fix this.
Under the hood, regFindFarest() is called when all the registers are allocated to virtual registers in the current statement/expression and registers need to spill to allow the next emit operation. On gas x86, there's only 6 registers to work with so I'm surprised this bug was never found before now - it's an old one.