English Amiga Board


Go Back   English Amiga Board > Off Topic > OT - Technical

 
 
Thread Tools
Old 12 January 2021, 15:05   #21
Dbug
Registered User

 
Join Date: Jan 2021
Location: Oslo
Posts: 0
Quote:
Originally Posted by vbc View Post
I added some changes to the vbcc backend to improve use of the x register and the comparison. (...) Down to 12 bytes.
Very nice!

What does VBCC require to work properly (zero page locations, stack, etc...) and how is that configured so it does not conflict with the system?

Is it possible to call VBCC compiled code from an IRQ handler?
Dbug is offline  
Old 12 January 2021, 18:25   #22
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 856
Quote:
Originally Posted by vbc View Post
Down to 12 bytes.
Impressive. The 6502 is a very unfriendly target for a C compiler.
Thomas Richter is offline  
Old 12 January 2021, 19:08   #23
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,769
Quote:
Originally Posted by Dbug View Post
Does VASM supports hexadecimal values expressed in 0x notation in addition to the usual $ for hex, and % for binary?
Depends on the syntax-module in use. oldstyle: yes.

Quote:
Is it like devpac, with labels starting by . being local, anything else being global?
Yes. Depends on the syntax-module again, but for "mot" and "oldstyle" local symbols may be preceded by '.' or terminated by a '$'.

Thanks. Already implemented in vasm. Here is the output of your small example program, which starts at $0000 as no ORG or *= was provided:

Code:
frank@nerthus cat mytest.s
        lda     #23
        rts
frank@nerthus ../../vasm6502_oldstyle -quiet -Fbin -oric-mc -o mytest mytest.s
frank@nerthus hexdump -C mytest
00000000  16 16 16 16 00 00 80 c7  00 02 00 00 00 6d 79 74  |.............myt|
00000010  65 73 74 00 a9 17 60                              |est...`|
Is this a valid Oric machine code file? Reserved bytes are zero?

Quote:
Does it output to some listing file?
Yes. -L option.

Quote:
Generally we do this type of thing when we want to generate code that will be recopied, like typically force the * to something in zero page to make sure the code is generated with the proper 8 bit addresses, but with a valid label before and after that is not in zero page, so we can copy the block of data.
Ah, yes. I understand. That's also allowed in vasm, when you do it in a section. This code would be placed within the section, but relocated by the assembler for the given address.

At least this is how it works in mot-syntax. In oldstyle we have the "rorg <addr>" and "rend" directives, which define such a relocated-org block. The advantage is that it works not only in a section but also within absolute code, started by ORG or *=.

Quote:
Can't I define the address of data, bss, etc... inside the assembler itself?
See above. In mot-syntax you can (I might add that for oldstyle). Otherwise you would just write multiple ORG-directives, or:
Code:
        *=$500
(..code..)
        *=$2000
(..data..)
Quote:
When I code on the Atari ST, I largely prefer to .include my .s files than have to deal with a linker.

I'm 150% certain that the popularity of devpac back in the days, was that it could support object files, but that by default it could just output a .PRG file directly for a .S file.
Correct. vasm does the same. It's perfectly legal to include everything into one giant source, but I thought you wanted to be able to link with C objects or even linker libraries?

Quote:
The Oric header is trivial, so yeah should not take long
Indeed. The o65 format is more complex, of course.

BTW, I think we are getting so deep into details that it makes our discussion no longer interesting for a forum. You are always welcome to contact us by email (look into the documentation of vasm and vbcc) for further questions or feedback.
phx is offline  
Old 13 January 2021, 10:25   #24
kamelito
Zone Friend
kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,285
Nice to see this moving forward for the Oric, thanks you all for your work!
kamelito is offline  
Old 13 January 2021, 14:23   #25
Dbug
Registered User

 
Join Date: Jan 2021
Location: Oslo
Posts: 0
Quote:
Originally Posted by phx View Post
00000000 16 16 16 16 00 00 80 c7 00 02 00 00 00 6d 79 74 |.............myt|
00000010 65 73 74 00 a9 17 60 |est...`|
[/code]Is this a valid Oric machine code file? Reserved bytes are zero?
Almost.

16 16 16 16 should be 16 16 16 24.
You can actually have many more 16 (it's the synchronisation sequence) but it needs to end by a 24.

The 80 C7 is correct, but it's nice to be able to specify that you don't want the file to auto start (when debugging, etc...) in which case 80 00 is what you want.

The 00 02 / 00 00 is correct if you want to load at address zero, but page 2 is used by the system, page 3 is where I/O are, page 4 is used by the DOS, so we consider that the safest "default" address to load anything would be $500 so in this case that would be 05 00

In summary, instead of
16 16 16 16 00 00 80 c7 00 02 00 00 00 6d 79 74 65 73 74 00 a9 17 60

what you should have is:
16 16 16 24 00 00 80 c7 05 02 05 00 00 6d 79 74 65 73 74 00 a9 17 60

Quote:
Originally Posted by phx View Post
BTW, I think we are getting so deep into details that it makes our discussion no longer interesting for a forum. You are always welcome to contact us by email (look into the documentation of vasm and vbcc) for further questions or feedback.
Yeah, I'll have to discuss with the Oric guys about how to proceed, and check with the maintainer of LCC65 if that's ok. Because he basically spent a lot of time fixing some stuff recently, that feels kind of crappy to drop the whole thing like that :-/
Dbug is offline  
Old 13 January 2021, 17:27   #26
vbc
Registered User
 
Join Date: Jan 2021
Location: Germany
Posts: 0
Quote:
Originally Posted by Dbug View Post
What does VBCC require to work properly (zero page locations, stack, etc...) and how is that configured so it does not conflict with the system?
In zero page, vbcc uses 2 bytes as a user stack pointer (sp) and up to 32 bytes as pseudo registers (r0..r31). If data types >=32 bits (long/float) are used, up to 16 additional bytes may be needed (btmp0..btmp3).

If the SANE IEEE libraries are used, they need additional space in zero page. The wozfp library does not need additional zero page space.

The 6502 stack is used for return addresses and register saves. A software stack is used if local variables are needed that are not assigned to pseudo registers. Also, depending on the compile options, register saves can be done to the software stack. The stack sizes mainly depend on the code that is compiled.

The zero page registers are addressed via name and they have to be provided by the runtime system. On a normal port they come with the startup code or the library and are placed by the linker script. The stack pointers have to be set up to point to suitable space before calling vbcc code.

Quote:
Is it possible to call VBCC compiled code from an IRQ handler?
Yes, vbcc6502 offers the __interrupt attribute. This will instruct the compiler to restore all registers and return with rti.
vbc is offline  
Old 13 January 2021, 18:15   #27
Dbug
Registered User

 
Join Date: Jan 2021
Location: Oslo
Posts: 0
Quote:
Originally Posted by vbc View Post
In zero page, vbcc uses 2 bytes as a user stack pointer (sp) and up to 32 bytes as pseudo registers (r0..r31).(...)
Ok, so slightly less than the current OSDK compiler, but basically works the same

Quote:
Yes, vbcc6502 offers the __interrupt attribute. This will instruct the compiler to restore all registers and return with rti.
By registers, do you mean AXY, or does that also includes the pseudo registers in zeropage?

Is there a way to just have the pseudo register saving without the RTI?

Basically I'm talking of implementing callbacks in C, but that integrate in some existing IRQ handler managed by the Oric system (which already did all the saving of XYA, status flags and RTI), but that should make sure to not trash the pseudo registers in zero page.
Dbug is offline  
Old 13 January 2021, 19:39   #28
vbc
Registered User
 
Join Date: Jan 2021
Location: Germany
Posts: 0
Quote:
Originally Posted by Dbug View Post
By registers, do you mean AXY, or does that also includes the pseudo registers in zeropage?
It will save AXY and all the pseudo registers used in the function. If it contains a non-inlined function call, all caller-save pseudo registers will be saved.

If the software stack is needed, it will also switch to a separate interrupt stack. This is necessary, because changes to the software stack are not atomic (16bit pointer).
Quote:
Is there a way to just have the pseudo register saving without the RTI?
Not in the current version, but adding this as an option can be easily added.
Quote:
Basically I'm talking of implementing callbacks in C, but that integrate in some existing IRQ handler managed by the Oric system (which already did all the saving of XYA, status flags and RTI), but that should make sure to not trash the pseudo registers in zero page.
I see. Makes sense.
vbc is offline  
Old 13 January 2021, 21:25   #29
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,769
Quote:
Originally Posted by Dbug View Post
You can actually have many more 16 (it's the synchronisation sequence) but it needs to end by a 24.
Yes, I missed that. Thanks.

Quote:
The 80 C7 is correct, but it's nice to be able to specify that you don't want the file to auto start (when debugging, etc...) in which case 80 00 is what you want.
Ok. So I added an additional option.
-Fbin -oric-mcx
now writes an Oric header with auto-exec flag (80 c7), while
-Fbin -oric-mc
writes one without (80 00).

Quote:
The 00 02 / 00 00 is correct if you want to load at address zero, but page 2 is used by the system, page 3 is where I/O are, page 4 is used by the DOS, so we consider that the safest "default" address to load anything would be $500 so in this case that would be 05 00
Right, but when you have a source without setting a start address, or just with a .text section, you would expect the output to be assembled for $0000, won't you?

If you really need that, I could make it default to $500 only when an Oric header is generated and the start address is zero.

Quote:
Yeah, I'll have to discuss with the Oric guys about how to proceed, and check with the maintainer of LCC65 if that's ok. Because he basically spent a lot of time fixing some stuff recently, that feels kind of crappy to drop the whole thing like that :-/
Absolutely.

I would try to keep both compiler options working in parallel as long as possible, until you and other OSDK users are sure about it. It's a long way to go and probably quite some work for you. What I can definitely promise is that I'm working on implementing the o65 object file format, for XA-compatibility, and we can also build a standard clib for Oric, as soon as we find out how character input/output works with its OS.
phx is offline  
Old Yesterday, 12:14   #30
Dbug
Registered User

 
Join Date: Jan 2021
Location: Oslo
Posts: 0
Quote:
Originally Posted by phx View Post
Right, but when you have a source without setting a start address, or just with a .text section, you would expect the output to be assembled for $0000, won't you?

If you really need that, I could make it default to $500 only when an Oric header is generated and the start address is zero.
I'd say that in the absolute, you are right, but in practice there's pretty much 0% chance you can load an Oric program using this format (tape header) at address zero, since that will overwrite system variables required by the program to run at all.

In the spirit of "just call the assembler and get something that runs", it makes sense to have $500 used if no value is specified, because that would work on Oric 1, Atmos, Telestrat and Pravetz, with or without a floppy drive attached.


Quote:
Originally Posted by phx View Post
I would try to keep both compiler options working in parallel as long as possible, until you and other OSDK users are sure about it. It's a long way to go and probably quite some work for you. What I can definitely promise is that I'm working on implementing the o65 object file format, for XA-compatibility, and we can also build a standard clib for Oric, as soon as we find out how character input/output works with its OS.
You can read the keyboard with the handle in $23B and output characters with the one in $238 (at least on ROM 1.1 and later, but that's another painful topic ).

Here is the implementation of the "getchar" from the OSDK:
Code:
_getchar
	jsr $023B
	bpl _getchar	; loop until char available
	tax
	jsr $0238	; echo char
	lda #0
	rts
Dbug is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Virus Alert in beta versions. ma693541 support.WinUAE 12 02 June 2016 09:33
Converting 6502 to 680x0 (calling all 6502/680x0 experts) oRBIT Coders. General 12 14 January 2015 20:18
Differences between beta versions and non-versioned winuae.zip? amadama support.WinUAE 2 22 August 2014 13:37
homebrew 6809 computer s2325 Nostalgia & memories 0 09 November 2010 02:09
6502 Asm pmc Coders. General 21 06 November 2008 10:37

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 18:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.09057 seconds with 14 queries