some missing functions in OSDK

Since we do not have native C compilers on the Oric, this forum will be mostly be used by people using CC65 or the OSDK. But any general C related post will be welcome !
Post Reply
User avatar
waskol
Flight Lieutenant
Posts: 392
Joined: Wed Jun 13, 2007 8:20 pm
Location: FRANCE, Paris

some missing functions in OSDK

Post by waskol » Tue Aug 28, 2018 7:22 pm

I found them on the oric.org forum, they needed to be addapted in order to compile with osdk, but it was not too difficult :
ATOF.S (ALPHA TO FLOAT)
ATOI.S (ALPHA TO INTEGER)
FTOA.S (FLOAT TO ALPHA)
RND.S (RND de l'ORIC)
SCRN.S (SCRN de l'ORIC)
PLOA.S (PLOT ATTRIBUT de l'ORIC)
PLOC.S (PLOT CHAR de l'ORIC)
PLOTS.S (PLOT STRING de l'ORIC)
POP.S (POP de l'ORIC)
WAIT.S (WAIT de l'ORIC)

and append the library.ndk file with those lines :

Code: Select all

-atoi.s
        _atoi
-ftoa.s
        _ftoa
-atof.s
        _atof
-plota.s
        _plota
-plotc.s
        _plotc
-plots.s
        _plots
-wait.s
        _wait
-rnd.s
        _rnd
-scrn.s
        _scrn
-pop.s
        _pop
-plot.s
        _plot
Attachments
lib.zip
(3.47 KiB) Downloaded 56 times

User avatar
waskol
Flight Lieutenant
Posts: 392
Joined: Wed Jun 13, 2007 8:20 pm
Location: FRANCE, Paris

Re: some missing functions in OSDK

Post by waskol » Wed Aug 29, 2018 9:36 pm

Forget it, debug explained me why it was sooooo stupid.
and i understood how it was possible to sort all of that out without those extra dumb things ! :oops:

User avatar
ibisum
Wing Commander
Posts: 1089
Joined: Fri Apr 03, 2009 8:56 am

Re: some missing functions in OSDK

Post by ibisum » Thu Aug 30, 2018 10:19 am

So tell us then!? :)

User avatar
waskol
Flight Lieutenant
Posts: 392
Joined: Wed Jun 13, 2007 8:20 pm
Location: FRANCE, Paris

Re: some missing functions in OSDK

Post by waskol » Thu Aug 30, 2018 11:29 am

ok, here are the explanations (in french, from Debug) :
- Ce ne sont pas des routines assembleur, en gros c'est le code du compilateur C après compilation, donc ca rame, et ca prend de la place.
- Elles sont redondantes, pas besoin d'avoir quatre versions de PLOT dont le code est a 90% identique (calcul de l'endroit ou on affiche)
- SCRN devrait aussi partager 90% du code de PLOT vu que ca fait la meme chose mais dans l'autre sens.
- La fonction POP est une hérésie sans non, celle la ne sera jamais dans le OSDK.
- Il y a deja une fonction random
- WAIT ne marchera que sur Oric ATMOS (appel de la ROM)
- scanf contient déja le code pour convertir des chaines de caractères vers format float ou entier, donc ATOF et ATOI devraient utiliser ca.
- printf contient déja le code pour convertir un float vers format ASCII, donc pareil.

Le but du OSDK n'est pas d'etre exhaustif et de permettre de faire tourner n'importe quel programme C standard sur l'Oric. Si c'est ce que les gens veulent faire, il y a CC65 qui fait ca très bien.

Le but du OSDK est de fournir une solution relativement optimale pour faire des programmes Oric aussi bons que possible, ce qui implique pas mal de contraintes, dont le fait de ne pas rajouter de code non optimisé.
So, how can be possible to sort all of that out without those functions.
- pop :
Totally useless in c (and in Basic too !)
- plot and scrn :
thank you debug :

Code: Select all

#define plot(X,Y,C) poke(0xBB80+(X)+(Y)*40,C)
#define scrn(X,Y) peek(0xBB80+(X)+(Y)*40)
- plot a string :
- either you are rewriting a function for yourself :

Code: Select all

void plots(char x_pos,char y_pos, const char *ptr_message)
{
	int unsigned start_adr=0xBB80+x_pos+y_pos*40;
	int unsigned len=strlen(ptr_message);
	int unsigned i;
	for (i=0;i<len;i++) poke(start_adr+i,ptr_message[i]);	
}

or you can use the AdvancePrint function (in the Hello world advanced sample), if you want something really fast.
- wait :

Code: Select all

#include <time.h>
  void wait(unsigned int wait_cs)
 {
	clock_t TIME0;
  
	TIME0 = clock();
	do;
	while ( (clock()-TIME0)<wait_cs );
 }
wiich should work but it does not...
or if you rely on an atmos :

Code: Select all

void wait(unsigned int wait_cs)
 {
 	//we use TIMER3 at adress #276-#277
	doke(0x0276,wait_cs);
	while ( deek(0x0276)>0){};
}

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 270
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: some missing functions in OSDK

Post by NekoNoNiaow » Tue Mar 26, 2019 12:58 am

DBug is right that there is no point in re-implementing all these functions from scratch but nevertheless it would be useful to code a few of them which are part of the C standard lib and are often used by many programs.

For example, I am currently converting/compiling a few benchmark programs with the OSDK in order to validate/measure performance of the compiler and they make use of quite a few functions of libc/posix which are currently missing.
(Among others: time, atoi.)

For now, I am essentially replacing/rewriting these functions to make the damn thing compile but if we had even a very basic (possibly optionally linked) libc available with the OSDK that would be useful in some cases.

This said, I checked cc65's libc (tinylibc) and it also does not include the "time" function either. ;)
I have been searching for a 8-bit libc recently but have not found one that was compact and capable of adapting to the limitations of the compiler (no 64 bit variables for example) yet.

User avatar
Dbug
Site Admin
Posts: 2909
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: some missing functions in OSDK

Post by Dbug » Tue Mar 26, 2019 8:26 am

I'm not against fixing or extending the library, specially if it improves the compatibility with the standard.

What I don't want is:
- Functions that are just literal translations of BASIC commands, that already have standard equivalent implemented. If the point is to convert old BASIC programs to C, there are better ways that adding PLOT or SCR to the libraries, and at worse these could be part of some separate "compatibility layer" if you want.

- Things that you pay the cost for even if you don't use them: If the new functions are in the library.ndx and in their own independent source files, no problem, but if they require some scaffolding in the generic functions for them to work, I'm not that ok anymore.

- Things that are implemented as actual code when it could just be a macro.

Regarding time functions, I can see the point of having the necessary elements to doing timings, but since there are no real time clock on the machine, having the full time_t support with all the functions to convert to and from ascii, handle all the rules for the number of days in a year, 29th of februar, etc... would kind of be super overkill. I think.

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 270
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: some missing functions in OSDK

Post by NekoNoNiaow » Thu Mar 28, 2019 2:59 am

Dbug wrote:
Tue Mar 26, 2019 8:26 am
What I don't want is:
- Functions that are just literal translations of BASIC commands, that already have standard equivalent implemented. If the point is to convert old BASIC programs to C, there are better ways that adding PLOT or SCR to the libraries, and at worse these could be part of some separate "compatibility layer" if you want.

- Things that you pay the cost for even if you don't use them: If the new functions are in the library.ndx and in their own independent source files, no problem, but if they require some scaffolding in the generic functions for them to work, I'm not that ok anymore.

- Things that are implemented as actual code when it could just be a macro.

Regarding time functions, I can see the point of having the necessary elements to doing timings, but since there are no real time clock on the machine, having the full time_t support with all the functions to convert to and from ascii, handle all the rules for the number of days in a year, 29th of februar, etc... would kind of be super overkill. I think.
Yup, I agree with all your points.

What I have done so far is:
- re-implemented atoi() in terms of sscanf as you suggested to waskol
- added a function time() which simply calls clock() for now. I made it a macro because I will eventually have to convert clock's result into a time() compatible result.

Once I have validated that both work (the program does not link yet -> it crashes compiler.exe :D (cf my other post)), I will make them available for addition to the existing libc.

Post Reply